[PATCH] xhci: fix null-pointer dereference when destroying half-built segment rings
xhci_alloc_segments_for_ring() builds a list of xhci_segments and links
the tail to head at the end (forming a ring). When it bails out for OOM
reasons half-way through, it tries to destroy its half-built list with
xhci_free_segments_for_ring(), even though it is not a ring yet. This
causes a null-pointer dereference upon hitting the last element.
Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes
the output parameters to be valid upon this kind of OOM failure, and
calls xhci_ring_free() on them. Since the (incomplete) list/ring should
already be destroyed in that case, this would lead to a use after free.
This patch fixes those issues by having xhci_alloc_segments_for_ring()
destroy its half-built, non-circular list manually and destroying the
invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-mem.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 487bc08..420ba37 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -205,7 +205,11 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd
*xhci,
next = xhci_segment_alloc(xhci, cycle_state, flags);
if (!next) {
- xhci_free_segments_for_ring(xhci, *first);
+ prev = *first;
+ do {
+ next = prev->next;
+ xhci_segment_free(xhci, prev);
+ } while ((prev = next));
return -ENOMEM;
}
xhci_link_segments(xhci, prev, next, type);
@@ -258,7 +262,7 @@ static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd
*xhci,
return ring;
fail:
- xhci_ring_free(xhci, ring);
+ kfree(ring);
return NULL;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acpi/cpuidle: reinitialize power_usage values when adding/removing C-states
> Could we just say this is always true because state[i+1] consumes less > than state[i] ? > > And then just remove the 'set_power_state' function, and the field > 'driver->power_specified' ? > > That will cleanup the code and fix this problem, no ? I totally agree with your analysis. Even if a driver were to set proper usage values (and the power_specified bit), none of the existing governors would care about those actual numbers (and since the vast majority of drivers uses fake values anyway, this is not likely to change in the future). This seems to be a classic example of unnecessary over-engineering. I am mostly interested in getting that bug fixed right now, but removing unnecessary code is always a good thing. If you think it would have a good chance of getting merged, I would be happy to draft up a larger patch that refactors power_usage away completely. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] acpi/cpuidle: reinitialize power_usage values when adding/removing C-states
When cpuidle drivers do not supply explicit power_usage values,
cpuidle/driver.c inserts dummy values instead. When a running processor
dynamically gains new C-states (e.g. after ACPI events), the power_usage
values of those states will stay uninitialized, and cpuidle governors
will never choose to enter them.
This patch ensures that the ACPI cpuidle driver sets those dummy power
values itself whenever it (re-)initializes its idle states.
Tested and verified on an Acer AC700 Chromebook, which supports the C3
state only when it switches from AC to battery power.
Signed-off-by: Julius Werner
---
drivers/acpi/processor_idle.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index e8086c7..078e22f 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1090,6 +1090,9 @@ static int acpi_processor_setup_cpuidle_states(struct
acpi_processor *pr)
state->exit_latency = cx->latency;
state->target_residency = cx->latency * latency_factor;
+ /* reinitialize this in case new states are added after boot */
+ state->power_usage = -1 - count;
+
state->flags = 0;
switch (cx->type) {
case ACPI_STATE_C1:
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpuidle: reinitialize power_usage values when adding/removing C-states
> This is specific to the acpi and should be handled in the > processor_idle.c file instead of the cpuidle core code. > > Could be the function 'acpi_processor_cst_has_changed' the right place > to set a dummy power value for the power in the new C-state ? Thanks for your feedback. I think it wouldn't be wise to split the dummy power value logic over two places, but I could submit a patch that makes set_power_states globally accessible and calls it from acpi_processor_cst_has_changed instead. However, I do not think this should really be ACPI specific. It applies to any cpuidle driver that wants to change its idle states at runtime. Currently only the ACPI one does, but the future might bring others that would run into the same problem. I also think that set_power_states fits much better into cpuidle_enable_device conceptually anyway (right next to poll_idle_init which also does state initialization). Let me know what you think. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpuidle: reinitialize power_usage values when adding/removing C-states
When cpuidle drivers do not supply explicit power_usage values,
cpuidle/driver.c inserts dummy values instead. When a running processor
dynamically gains new C-states (e.g. after ACPI events), the power_usage
values of those states will stay uninitialized, and cpuidle governors
will never choose to enter them.
This patch moves the dummy value initialization from
cpuidle_register_driver to cpuidle_enable_device, which drivers such as
acpi/processor_idle.c will call again when they add or remove C-states.
Tested and verified on an Acer AC700 Chromebook, which supports the C3
state only when it switches from AC to battery power.
Signed-off-by: Julius Werner
---
drivers/cpuidle/cpuidle.c | 24
drivers/cpuidle/driver.c | 25 -
2 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 7f15b85..bef3a31 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -298,6 +298,28 @@ static void poll_idle_init(struct cpuidle_driver *drv)
static void poll_idle_init(struct cpuidle_driver *drv) {}
#endif /* CONFIG_ARCH_HAS_CPU_RELAX */
+static void set_power_states(struct cpuidle_driver *drv)
+{
+ int i;
+
+ /*
+* cpuidle driver should set the drv->power_specified bit
+* before registering if the driver provides
+* power_usage numbers.
+*
+* If power_specified is not set,
+* we fill in power_usage with decreasing values as the
+* cpuidle code has an implicit assumption that state Cn
+* uses less power than C(n-1).
+*
+* With CONFIG_ARCH_HAS_CPU_RELAX, C0 is already assigned
+* an power value of -1. So we use -2, -3, etc, for other
+* c-states.
+*/
+ for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++)
+ drv->states[i].power_usage = -1 - i;
+}
+
/**
* cpuidle_enable_device - enables idle PM for a CPU
* @dev: the CPU
@@ -330,6 +352,8 @@ int cpuidle_enable_device(struct cpuidle_device *dev)
cpuidle_enter_tk : cpuidle_enter;
poll_idle_init(drv);
+ if (!drv->power_specified)
+ set_power_states(drv);
if ((ret = cpuidle_add_state_sysfs(dev)))
return ret;
diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index 87db387..caaed27 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -18,28 +18,6 @@ static struct cpuidle_driver *cpuidle_curr_driver;
DEFINE_SPINLOCK(cpuidle_driver_lock);
int cpuidle_driver_refcount;
-static void set_power_states(struct cpuidle_driver *drv)
-{
- int i;
-
- /*
-* cpuidle driver should set the drv->power_specified bit
-* before registering if the driver provides
-* power_usage numbers.
-*
-* If power_specified is not set,
-* we fill in power_usage with decreasing values as the
-* cpuidle code has an implicit assumption that state Cn
-* uses less power than C(n-1).
-*
-* With CONFIG_ARCH_HAS_CPU_RELAX, C0 is already assigned
-* an power value of -1. So we use -2, -3, etc, for other
-* c-states.
-*/
- for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++)
- drv->states[i].power_usage = -1 - i;
-}
-
/**
* cpuidle_register_driver - registers a driver
* @drv: the driver
@@ -58,9 +36,6 @@ int cpuidle_register_driver(struct cpuidle_driver *drv)
return -EBUSY;
}
- if (!drv->power_specified)
- set_power_states(drv);
-
cpuidle_curr_driver = drv;
spin_unlock(&cpuidle_driver_lock);
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
3.6-rc1: apple-gmux don't link, that mess the wole compilation because no vmlinuz produced
CC init/version.o LD init/built-in.o drivers/built-in.o: In function `gmux_probe': apple-gmux.c:(.devinit.text+0x6daa8): undefined reference to `apple_bl_unregister' drivers/built-in.o: In function `gmux_remove': apple-gmux.c:(.devexit.text+0x8f80): undefined reference to `apple_bl_register' make: [vmlinux] Error 1 (ignored) CC arch/x86/boot/a20.o AS arch/x86/boot/bioscall.o CC arch/x86/boot/cmdline.o AS arch/x86/boot/copy.o HOSTCC arch/x86/boot/mkcpustr CPUSTR arch/x86/boot/cpustr.h CC arch/x86/boot/cpu.o CC arch/x86/boot/cpucheck.o CC arch/x86/boot/early_serial_console.o CC arch/x86/boot/edd.o make[1]: *** No rule to make target `vmlinux', needed by `arch/x86/boot/voffset.h'. --- Professional hosting for everyone - http://www.host.ru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.6-rc1: twl4030 don't compile :(
CC drivers/power/twl4030_charger.o drivers/power/twl4030_charger.c:248:12: error: invalid suffix "b1100" on integer constant drivers/power/twl4030_charger.c:250:12: error: invalid suffix "b1000" on integer constant drivers/power/twl4030_charger.c:252:12: error: invalid suffix "b0100" on integer constant drivers/power/twl4030_charger.c:254:12: error: invalid suffix "b" on integer constant drivers/power/twl4030_charger.c:257:12: error: invalid suffix "b11" on integer constant drivers/power/twl4030_charger.c:259:12: error: invalid suffix "b10" on integer constant drivers/power/twl4030_charger.c:261:12: error: invalid suffix "b01" on integer constant drivers/power/twl4030_charger.c:263:12: error: invalid suffix "b00" on integer constant drivers/power/twl4030_charger.c:266:5: error: invalid suffix "b1100" on integer constant drivers/power/twl4030_charger.c:266:26: error: invalid suffix "b11" on integer constant make[2]: [drivers/power/twl4030_charger.o] Error 1 (ignored) CC drivers/power/lp8727_charger.o CC drivers/power/gpio-charger.o CC drivers/power/charger-manager.o LD drivers/power/avs/built-in.o CC drivers/power/smb347-charger.o LD drivers/power/built-in.o ld: drivers/power/twl4030_charger.o: No such file: No such file or directory make[2]: [drivers/power/built-in.o] Error 1 (ignored) CC [M] drivers/power/ds2760_battery.o that messed the whole compilation because the kernel didn't link :( :( --- Professional hosting for everyone - http://www.host.ru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.5-rc7 Pid: 11, comm: kworker/u:1 Tainted , Pid: 1, comm: swapper/0 Not tainted ,
On an Acer Aspire 5349 I get several error messages during booting, with 3.5-rc7 . Pls inspect the added syslog. wl Jul 16 00:39:53 localhost kernel: WARNING: at drivers/pci/hotplug/ibmphp_ebda.c:282 ibmphp_access_ebda+0x104/0x517() Jul 16 00:39:53 localhost kernel: Hardware name: Aspire 5349 Jul 16 00:39:53 localhost kernel: ibmphp_ebda: next read is beyond ebda_sz Jul 16 00:39:53 localhost kernel: Modules linked in: Jul 16 00:39:53 localhost kernel: Pid: 1, comm: swapper/0 Not tainted 3.5.0-rc7-i486-1sys #1 Jul 16 00:39:53 localhost kernel: Call Trace: Jul 16 00:39:53 localhost kernel: [] ? ibmphp_access_ebda+0x104/0x517 Jul 16 00:39:53 localhost kernel: [] warn_slowpath_common+0x7a/0x8f Jul 16 00:39:53 localhost kernel: [] ? ibmphp_access_ebda+0x104/0x517 Jul 16 00:39:53 localhost kernel: [] warn_slowpath_fmt+0x33/0x35 Jul 16 00:39:53 localhost kernel: [] ibmphp_access_ebda+0x104/0x517 Jul 16 00:39:53 localhost kernel: [] ? init_ops+0x437/0x437 Jul 16 00:39:53 localhost kernel: [] ibmphp_init+0xd1/0x15b Jul 16 00:39:53 localhost kernel: [] do_one_initcall+0x2e/0xe0 Jul 16 00:39:53 localhost kernel: [] do_initcall_level+0x69/0x79 Jul 16 00:39:53 localhost kernel: [] ? do_basic_setup+0x25/0x25 Jul 16 00:39:53 localhost kernel: [] ? do_early_param+0x74/0x74 Jul 16 00:39:53 localhost kernel: [] do_initcalls+0xe/0x16 Jul 16 00:39:53 localhost kernel: [] do_basic_setup+0x23/0x25 Jul 16 00:39:53 localhost kernel: [] kernel_init+0x5d/0xe9 Jul 16 00:39:53 localhost kernel: [] kernel_thread_helper+0x6/0x10 Jul 16 00:39:53 localhost kernel: ---[ end trace 82bc55f036371117 ]--- Jul 16 00:39:53 localhost kernel: sr0: scsi3-mmc drive: 24x/8x writer dvd-ram cd/rw xa/form2 cdda tray Jul 16 00:39:53 localhost kernel: sysctl duplicate entry: /dev/cdrom//info Jul 16 00:39:53 localhost kernel: Pid: 11, comm: kworker/u:1 Tainted: GW3.5.0-rc7-i486-1sys #1 Jul 16 00:39:53 localhost kernel: Call Trace: Jul 16 00:39:53 localhost kernel: [] __register_sysctl_table+0x114/0x126 Jul 16 00:39:53 localhost kernel: [] __register_sysctl_paths+0xb0/0x143 Jul 16 00:39:53 localhost kernel: [] register_sysctl_paths+0x16/0x18 Jul 16 00:39:53 localhost kernel: [] register_sysctl_table+0x14/0x16 Jul 16 00:39:53 localhost kernel: [] cdrom_sysctl_register+0x1b/0x68 Jul 16 00:39:53 localhost kernel: [] register_cdrom+0x5a/0x1ce Jul 16 00:39:53 localhost kernel: [] sr_probe+0x1cb/0x225 Jul 16 00:39:53 localhost kernel: [] really_probe+0x7f/0x12b Jul 16 00:39:53 localhost kernel: [] driver_probe_device+0x31/0x46 Jul 16 00:39:53 localhost kernel: [] __device_attach+0x2d/0x35 Jul 16 00:39:53 localhost kernel: [] bus_for_each_drv+0x3e/0x5f Jul 16 00:39:53 localhost kernel: [] device_attach+0x5f/0x83 Jul 16 00:39:53 localhost kernel: [] ? wait_for_device_probe+0x75/0x75 Jul 16 00:39:53 localhost kernel: [] bus_probe_device+0x27/0x7a Jul 16 00:39:53 localhost kernel: [] device_add+0x1b5/0x2da Jul 16 00:39:53 localhost kernel: [] scsi_sysfs_add_sdev+0x9d/0x1ee Jul 16 00:39:53 localhost kernel: [] ? attribute_container_device_trigger+0x85/0x8d Jul 16 00:39:53 localhost kernel: [] ? ata_find_dev+0xa/0x76 Jul 16 00:39:53 localhost kernel: [] scsi_add_lun+0x36c/0x381 Jul 16 00:39:53 localhost kernel: [] scsi_probe_and_add_lun+0x2a2/0x319 Jul 16 00:39:53 localhost kernel: [] ? _raw_spin_unlock_irqrestore+0x2b/0x37 Jul 16 00:39:53 localhost kernel: [] ? __pm_runtime_resume+0x56/0x5e Jul 16 00:39:53 localhost kernel: [] __scsi_add_device+0xb3/0xe4 Jul 16 00:39:53 localhost kernel: [] ata_scsi_scan_host+0x79/0x14d Jul 16 00:39:53 localhost kernel: [] async_port_probe+0x48/0x4d Jul 16 00:39:53 localhost kernel: [] async_run_entry_fn+0x9d/0x149 Jul 16 00:39:53 localhost kernel: [] ? process_one_work+0x153/0x2a4 Jul 16 00:39:53 localhost kernel: [] process_one_work+0x184/0x2a4 Jul 16 00:39:53 localhost kernel: [] ? maybe_create_worker+0x7f/0xda Jul 16 00:39:53 localhost kernel: [] ? async_synchronize_full+0x32/0x32 Jul 16 00:39:53 localhost kernel: [] worker_thread+0xd9/0x1a4 Jul 16 00:39:53 localhost kernel: [] ? gcwq_mayday_timeout+0x64/0x64 Jul 16 00:39:53 localhost kernel: [] kthread+0x6e/0x73 Jul 16 00:39:53 localhost kernel: [] ? kthread_stop+0x96/0x96 Jul 16 00:39:53 localhost kernel: [] kernel_thread_helper+0x6/0x10 Jul 16 00:39:53 localhost kernel: paride: aten registered as protocol 0 Jul 16 00:39:53 localhost kernel: paride: bpck registered as protocol 1 Jul 16 01:23:32 localhost kernel: WARNING: at drivers/pci/hotplug/ibmphp_ebda.c:282 ibmphp_access_ebda+0x104/0x517() Jul 16 01:23:32 localhost kernel: Hardware name: Aspire 5349 Jul 16 01:23:32 localhost kernel: ibmphp_ebda: next read is beyond ebda_sz Jul 16 01:23:32 localhost kernel: Modules linked in: Jul 16 01:23:32 localhost kernel: Pid: 1, comm: swapper/0 Not tainted 3.5.0-rc7-i486-1sys #1 Jul 16 01:23:32 localhost kernel: Call Trace: Jul 16 01:23:32 lo
3.5-rc6 fb hw inteldrmfb
On a computer of someone else, on which today I tried to install 3.5-rc6 (what on my computer and on an HP pavillon laptop runs without problem - on the laptop however needs ircpoll otherwhise don't find the harddisk), few seconds after start booting it sticks and don't continue longer (reboot not possible with Ctr-Alt-C but only pressing the reboot button), the last message is: "conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver" then the cursor stops blinking, and the computer sticks. With 3.4 the same computer runs since weeks without problems. So, that's a regression. Inspection of syslog, messages, debug don't show anything from this boot, it seems before the crash it hasn't nor time to log something. Below is the lspci of that computer. wl 00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 05:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01) --- Professional hosting for everyone - http://www.host.ru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.5-rcX : Big problem with root device returning
There is a big problem since 3.5-rc1 which potentially mess the installations rdev don't give longer back the root device like /dev/sda1 , but in the bios form like 0x80010300 rdev is essential for the installation programs and for the installation f.ex. of lilo . It's not conveniente to rely on the bios numbers, because on some meinbords they change depending which boot order you select in BIOS, or only if you select another boot device in the bios boot menu with F12. Whilst /dev/sdXY is more reliable. rdev is an old basical function which always worked correctly, until now. The error starts with 3.5-rc1 and is not corrected until 3.5-rc6 .If I go back to an earlier kernel, 3.4 or older, then the same installation works correct (rdev gives /dev/sda1 ) and if I go back then again to 3.5-rcX it's again wrong (rdev gives 0x80010300).Thus, this seems a wrong manner how the kernel gives back the root device, or interact with rdev. It's also possible that this problem happens only under any kernel compilation option, so that below I give the differences in config between 3.4 and 3.5-rc1 This problem should be fixed most quickly, rdev always have to work correctly. wl == 3c3 < # Linux/i386 3.5.0-rc1 Kernel Configuration --- # Linux/i386 3.4.0 Kernel Configuration 11a12,15 CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y 24a29 CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y 25a31 # CONFIG_GENERIC_TIME_VSYSCALL is not set 42a49 CONFIG_KTIME_SCALAR=y 44d50 < CONFIG_ARCH_SUPPORTS_UPROBES=y 48d53 < CONFIG_BUILDTIME_EXTABLE_SORT=y 100,113d104 < CONFIG_CLOCKSOURCE_WATCHDOG=y < CONFIG_KTIME_SCALAR=y < CONFIG_GENERIC_CLOCKEVENTS=y < CONFIG_GENERIC_CLOCKEVENTS_BUILD=y < CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y < CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y < CONFIG_GENERIC_CMOS_UPDATE=y < < # < # Timers subsystem < # < CONFIG_TICK_ONESHOT=y < # CONFIG_NO_HZ is not set < CONFIG_HIGH_RES_TIMERS=y 121d111 < CONFIG_RCU_FANOUT_LEAF=16 144a135 CONFIG_USER_NS=y 186a178 # CONFIG_PERF_COUNTERS is not set 201c193 < CONFIG_KPROBES=y --- # CONFIG_KPROBES is not set 203d194 < CONFIG_OPTPROBES=y 205d195 < CONFIG_KRETPROBES=y 213d202 < CONFIG_HAVE_DMA_CONTIGUOUS=y 215d203 < CONFIG_GENERIC_SMP_IDLE_THREAD=y 227,228d214 < CONFIG_HAVE_ARCH_SECCOMP_FILTER=y < CONFIG_SECCOMP_FILTER=y 325a312,316 CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y 467d457 < CONFIG_CROSS_MEMORY_ATTACH=y 511,512d500 < # CONFIG_PM_AUTOSLEEP is not set < # CONFIG_PM_WAKELOCKS is not set 649a638,640 CONFIG_MCA=y CONFIG_MCA_LEGACY=y CONFIG_MCA_PROC_FS=y 657c648 < CONFIG_ALIX=y --- # CONFIG_ALIX is not set 696d686 < # CONFIG_RAPIDIO_DMA_ENGINE is not set 724d713 < CONFIG_XFRM_ALGO=y 866d854 < CONFIG_NETFILTER_XT_TARGET_HMARK=m 1025a1014 CONFIG_IP6_NF_QUEUE=m 1084d1072 < # CONFIG_NET_DCCPPROBE is not set 1086d1073 < # CONFIG_NET_SCTPPROBE is not set 1125c1112 < CONFIG_LLC=m --- CONFIG_LLC=y 1139a1127,1129 CONFIG_ECONET=m CONFIG_ECONET_AUNUDP=y CONFIG_ECONET_NATIVE=y 1144d1133 < CONFIG_MAC802154=m 1168,1169d1156 < CONFIG_NET_SCH_CODEL=m < CONFIG_NET_SCH_FQ_CODEL=m 1205d1191 < CONFIG_BATMAN_ADV_BLA=y 1218d1203 < # CONFIG_NET_TCPPROBE is not set 1428,1429d1412 < CONFIG_NFC_HCI=m < CONFIG_NFC_SHDLC=y 1436d1418 < CONFIG_PN544_HCI_NFC=m 1464d1445 < # CONFIG_CMA is not set 1627a1609 # CONFIG_MTD_UBI_DEBUG is not set 1638a1621 CONFIG_OF_GPIO=y 1640a1624 CONFIG_OF_SPI=y 1711c1695 < CONFIG_BLK_DEV_NVME=y --- # CONFIG_BLK_DEV_NVME is not set 1757,1759c1741 < CONFIG_BMP085=y < CONFIG_BMP085_I2C=m < CONFIG_BMP085_SPI=m --- CONFIG_BMP085=m 1761a1744 CONFIG_MAX8997_MUIC=m 1791d1773 < CONFIG_INTEL_MEI=m 1983a1966 CONFIG_SCSI_FD_MCS=y 1988a1972,1974 CONFIG_SCSI_IBMMCA=y CONFIG_IBMMCA_SCSI_ORDER_STANDARD=y CONFIG_IBMMCA_SCSI_DEV_RESET=y 1996a1983 CONFIG_SCSI_NCR_D700=y 2005a1993,1996 CONFIG_SCSI_NCR_Q720=y CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8 CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32 CONFIG_SCSI_NCR53C8XX_SYNC=20 2010d2000 < CONFIG_TCM_QLA2XXX=m 2187d2176 < CONFIG_SBP_TARGET=m 2225d2213 < # CONFIG_IEEE802154_FAKELB is not set 2230d2217 < CONFIG_NET_TEAM_MODE_LOADBALANCE=m 2387a2375,2382 CONFIG_NET_VENDOR_IBM=y # CONFIG_IBM_EMAC_ZMII is not set # CONFIG_IBM_EMAC_RGMII is not set # CONFIG_IBM_EMAC_TAH is not set # CONFIG_IBM_EMAC_EMAC4 is not set # CONFIG_IBM_EMAC_NO_FLOW_CTRL is not set # CONFIG_IBM_EMAC_MAL_CLR_ICINTSTAT is not set # CONFIG_IBM_EMAC_MAL_COMMON_ERR is not set 2394d2388 < CONFIG_IGB_PTP=y 2398d2391 < CONFIG_IXGBE_HWMON=y 2401d2393 < # CONFIG_IXGBE_PTP is not set 2405a2398,2399 CONFIG_ELMC=m CONFIG_ELMC_II=m 2422d2415 < CONFIG_MLX4_EN_DCB=y 2437a2431 CONFIG_IBMLANA=m 2449a2444 CONFIG_NE2_MCA=m 2452a2448 CONFIG_ULTRAMCA=m 2519,2524d2514 < CONFIG_NET_VENDOR_WIZNET=y < CONFIG_WIZNE
regression w.r.t. problems #lilo when an usb-key is present: problem no longer
I reported a regression, that when a usb-key is connected, #lilo produces a bootloader which don't work, on 2.6.24-rc6-git2, diferently to kernels before. Yesterday I compiled 2.6.24-rc6-git8 with exactly the same kernel parameters, with this, the problem didnt occure again, on the same 2 computers. Thus probably the problem was resolved == *** www.copaya.yi.org / www.monkey.is-a-geek.net *** O único servidor comunitário na Guiana-Francesa. Situado no local, rápido, imuno contra guerras / desastres na Europa. Serviço não-comercial e gratuito de: http (forum, página web), irc (chat), ftp (download), name (subdomain) .
Problems on booting
There seems to have two regressions between the kernels from yesterday and before-yesterday On the kernel -git7 what didnt happened on -git6 1) My hard disk is /dev/hda, but when I have an usb key sticked in /dev/sba, and run lilo then, then it dont boot but give L99 99 99 99 ... error. When I remove the usb stick from /dev/sba , and run then #lilo , then the result boots. This problem was not present at the -git6 kernel 2) The boot stops / hangs on hardware detection of SCSI. I have an Initio INI-9X00U/UW. The last messages during boot are, that it's verifying i91u scsi2 , then the boot hangs. When I put the pci=off kernel option, then the boot process continues (but with this, by other reasons, my computer works only half, so that this is unpracticable). This problem also didnt happens with the -git6 kernelThis problem happens only on one of my two computers, because the other has no SCSI card inside, that computer boots normally. [EMAIL PROTECTED] == *** www.copaya.yi.org / www.monkey.is-a-geek.net *** O único servidor comunitário na Guiana-Francesa. Situado no local, rápido, imuno contra guerras / desastres na Europa. Serviço não-comercial e gratuito de: http (forum, página web), irc (chat), ftp (download), name (subdomain) .
Fwd: same problem with 2.6.24-rc2
On 7/Nov/2007 20:10 werner wrote .. > With 2.6.23-rc2 is the same problem: it crashed at the beginning: EIP 060 > c03fdea4 > EFLAGS 00010212 EIP is at xor_sse_2+0x34/0x200 > Again during the compilation was reclaimed that > /arch/x86/Makefile.o > cannot be found and were certain dependencies on it not made, such a file > isn't > present in the source code (present are, f.ex. Makefile_32 , Makefile_64 ), > nor > was generated automaticaly during compilation, I think this is incorrect and > the > reason for the problems > > wl > [EMAIL PROTECTED] > = > On 7/Nov/2007 16:14 Andrew Morton wrote .. > > > On Wed, 07 Nov 2007 15:55:12 -0300 (GFT) "werner" <[EMAIL PROTECTED]> > > > wrote: > > > I really don't know what's happening. I don't understand nothing about > > > the > kernel > > error reporting system. Because of this, always when there is a problem, I > report > > it via e-mail to linux-kernel@vger.kernel.org . I don't know what people > > there > > do with my messages. > > > > > > It went like this: > > > > 1: you sent an email to linux-kernel > > > > 2: I sent a reply to you and linux-kernel > > > > 3: you sent a reply to me, but NOT linux-kernel! > > > > In other words, you did "reply", not "reply to all", thus you removed three > > thousand people from the discussion. One of those people is the person who > > created the bug which you're hitting, and that person no longer knows > > what's happening. > > > > > > So please go back and resend all those emails, and retain ALL Cc:'s. Don't > > just send them only to me. Keep all indivisuals and all mailing lists on > > the email Cc: list. > == > *** www.copaya.yi.org / www.monkey.is-a-geek.net *** > O único servidor comunitário na Guiana-Francesa. Situado no local, rápido, > imuno > contra guerras / desastres na Europa. Serviço não-comercial e gratuito de: > http > (forum, página web), irc (chat), ftp (download), name (subdomain) . == *** www.copaya.yi.org / www.monkey.is-a-geek.net *** O único servidor comunitário na Guiana-Francesa. Situado no local, rápido, imuno contra guerras / desastres na Europa. Serviço não-comercial e gratuito de: http (forum, página web), irc (chat), ftp (download), name (subdomain) .
crash 2.6.24-rc1-git10
Kernel Crash -- Details see below globc 2.7 glib2 2.14.2 W.Landgraf www.copaya.yi.org = 2.6.24-rc1-git10 EIP 0600: EFLAGS 00010212 CPU 0 EIUP is at xor_sse_2+0x34/0x200 EAX: 10 EBX fffedb22 ECX c183f000 EDX c183c000 ESS 8005003b EDI c0929614 EBP c183f000 ESP c1823ef0 DS 7b ES 7b FS d8 GS 0 SS 68 Process swapper pid 1 ti: c182200 task c182 task.ti c=1822000 Stack: 8x 08x 0 fffedb22 0 c04067b3 10 c0849b62 c1030780 c183f000 c183c000 call trace c0 4067b3 do_xor_speed+0x53/0xd0 9a9582 calibrate_xor_blocks 0xe2/0x100 (or 1a0 ?) 191594 register_filesystem =0X44/0X70 991565 kernel_init+0x125/0x2f0 10420a ret_from_fork +0x6/0x1c (or 0xb ...) 991440 kernel_init+0x0/0x2f0 " again c0104edf kernel_thread_helper+0x7/0x18 code 08 89 74 24 44 0f 20 cf 0f 06 (or 0b) 0f 11 04 24 0f 11 4c 34 10 0f 11 54 24 20 0f 11 5c 24 30 0f 18 82 00 01 00 00 0f 18 82 20 01 00 00 <00> 20x 0 EIP c0407284 xor_sse_2+0x34/0x200 SS ESP 068: c1823ef0 kernel panic System.map==
Bug in drm modules of kernel 2.6.23-rc9-git2
attn: linux-kernel@vger.kernel.org There is a bug in the drm modules, w.r.t. radeon and savage grafic cards (at least) This bug is present on kernel 2.6.23-rc9-git2 , it was NOT present on 2.6.23-rc8-git4 nor in the previous kernels. Without drm, also compiz snapshot don't work longer I hope you can find and repair this before the 2.6.23 release Below is the beginning of dmesg for the two kernels what I quoted above. Werner Landgraf www.copaya.yi.org == dmesg 2.6.23-rc9-git2 (drm no working longer ...) === Linux version 2.6.23-rc9-git2-i486-1mn ([EMAIL PROTECTED]) (gcc version 4.2.0 20061031 (prerelease)) #1 SMP Thu Oct 4 15:32:50 GFT 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 00f0 (usable) BIOS-e820: 00f0 - 0100 (reserved) BIOS-e820: 0100 - 4000 (usable) BIOS-e820: - 0001 (reserved) 128MB HIGHMEM available. 896MB LOWMEM available. Entering add_active_range(0, 0, 262144) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem229376 -> 262144 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 262144 On node 0 totalpages: 262144 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 256 pages used for memmap HighMem zone: 32512 pages, LIFO batch:7 Movable zone: 0 pages used for memmap DMI 2.2 present. Allocating PCI resources starting at 5000 (gap: 4000:bfff) Built 1 zonelists in Zone order. Total pages: 260096 Kernel command line: BOOT_IMAGE=2623rc9git2 ro root=302 4 root=/dev/hda2 devfs=nomount noapic nolapic acpi=ht mapped APIC to b000 (0180d000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 999.646 MHz processor. Console: colour dummy device 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1033016k/1048576k available (3099k kernel code, 13956k reserved, 1098k data, 408k init, 131072k highmem) virtual kernel memory layout: fixmap : 0xfff4b000 - 0xf000 ( 720 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc0521000 - 0xc0587000 ( 408 kB) .data : 0xc0406e85 - 0xc0519804 (1098 kB) .text : 0xc010 - 0xc0406e85 (3099 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay using timer specific routine.. 2001.41 BogoMIPS (lpj=4002837) Security Framework v1.0.0 initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383f9ff c1cbf9ff CPU: CLK_CTL MSR was fff7f37f. Reprogramming to 2007f37f CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383f9ff c1cbf9ff 0420 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Compat vDSO mapped to e000. Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 16k freed CPU0: AMD Athlon(tm) Processor stepping 01 SMP motherboard not detected. Local APIC not detected. Using dummy APIC emulation. Brought up 1 CPUs Booting paravirtualized kernel on bare hardware NET: Registered protocol family 16 EISA bus registered PCI: PCI BIOS revision 2.10 entry at 0xfb160, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled PnPBIOS: Scanning system for PnP BIOS support... PnPBIOS: Found PnP BIOS installation structure at 0xc00fbc30 PnPBIOS: PnP BIOS version 1.0, entry 0xf:0xbc60, dseg 0xf PnPBIOS: 15 nodes reported by PnP BIOS; 15 recorded by driver SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) Disabling VIA memory write queue (PCI ID 0305, rev 03): [55] 8d & 1f -> 0d PCI quirk: region 6000-607f claimed by vt82c686 HW-mon PCI
Re: [PATCH] Re: Serial USB-driver for Winchiphead CH340/41 chip
Am Freitag, 21. September 2007 18:18 schrieb Greg KH: Hello, > On Fri, Sep 21, 2007 at 10:15:11AM +0200, Werner Cornelius wrote: > > Hello, > > > > attached you will find the patch against the 2.6.23-rc6-mm1 > > > > Changed fetaures: > > > > 1. All baudrates possible (dynamic baudfactor calculation) > > 2. Added support of modem control and status lines. > > You forgot: > 3. broke all formatting sorry about, but that wasn't an intend. This action has been done by one or more of the apps I am using (editor, mailer...). I assume it is a feature of Kmail, inserting plane text seems to be converted to space separated text, discarding tabs. > > :( > > Please redo the patch such that the formating of the file is not changed > (you converted tabs to spaces). > > > --- linux-2.6.23-rc6-mm1/drivers/usb/serial/ch341.c 2007-09-21 > > 09:56:56.0 +0200 > > +++ develop/drivers/usb/serial/ch341.c 2007-09-21 10:00:26.0 > > +0200 @@ -1,5 +1,9 @@ > > /* > > - * Copyright 2007, Frank A Kingswood <[EMAIL PROTECTED]> > > + * Copyright 2007, Frank A Kingswood > > kingswood-consulting.co.uk> > > Why did you change this email address? This address was in the original file I got from the net. Perhaps this file have had spaces instead of tabs, too. > > > + * > > + * Copyright 2007, Werner Cornelius cornelius-consult.de> > > + * for changes/extenions regarding universal baud rate capability and > > modem + * line control/status routines. > > Don't put changelog information in a copyright notice, that's not > needed. Just put your name there please, with a "real" email address. Ok. that should be ok. I am not used to the rules on the kernel traffic list. > > And we need a "Signed-off-by:" line. I did add one on last request. Was this wrong ? Perhaps I need an Howto about mailing to kernel list. I read the main documentation, but didn't found this amount of request rules in a way that would be sufficient to publish a patch which I just wanted to make useable by the whole community. I will try to verify how I could generate the patch in a way that it might be acceptable. > > thanks, > > greg k-h Werner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: Serial USB-driver for Winchiphead CH340/41 chip
Hello,
attached you will find the patch against the 2.6.23-rc6-mm1
Changed fetaures:
1. All baudrates possible (dynamic baudfactor calculation)
2. Added support of modem control and status lines.
Still missing (due to lack of an usb sniffer):
1. Break control
2. Parity
Werner
--- linux-2.6.23-rc6-mm1/drivers/usb/serial/ch341.c 2007-09-21
09:56:56.0 +0200
+++ develop/drivers/usb/serial/ch341.c 2007-09-21 10:00:26.0 +0200
@@ -1,5 +1,9 @@
/*
- * Copyright 2007, Frank A Kingswood <[EMAIL PROTECTED]>
+ * Copyright 2007, Frank A Kingswood kingswood-consulting.co.uk>
+ *
+ * Copyright 2007, Werner Cornelius cornelius-consult.de>
+ * for changes/extenions regarding universal baud rate capability and modem
+ * line control/status routines.
*
* ch341.c implements a serial port driver for the Winchiphead CH341.
*
@@ -21,327 +25,548 @@
#include
#include
-#define DEFAULT_BAUD_RATE 2400
+#define DEFAULT_BAUD_RATE 9600
#define DEFAULT_TIMEOUT 1000
+/* flags for IO-Bits */
+#define CH341_BIT_RTS (1 << 6)
+#define CH341_BIT_DTR (1 << 5)
+
+/**/
+/* interrupt pipe definitions */
+/**/
+/* always 4 interrupt bytes */
+/* first irq byte normally 0x08 */
+/* second irq byte base 0x7d + below */
+/* third irq byte base 0x94 + below */
+/* fourth irq byte normally 0xee */
+
+/* second interrupt byte */
+#define CH341_MULT_STAT 0x04 /* multiple status since last interrupt event */
+
+/* status returned in third interrupt answer byte, inverted in data from irq
*/
+#define CH341_BIT_CTS 0x01
+#define CH341_BIT_DSR 0x02
+#define CH341_BIT_RI 0x04
+#define CH341_BIT_DCD 0x08
+#define CH341_BITS_MODEM_STAT 0x0f /* all bits */
+
+/***/
+/* baudrate calculation factor */
+/***/
+#define CH341_BAUDBASE_FACTOR 1532620800
+#define CH341_BAUDBASE_DIVMAX 3
+
static int debug;
static struct usb_device_id id_table [] = {
- { USB_DEVICE(0x4348, 0x5523) },
- { },
+ { USB_DEVICE(0x4348, 0x5523) },
+ { },
};
MODULE_DEVICE_TABLE(usb, id_table);
struct ch341_private {
- unsigned baud_rate;
- u8 dtr;
- u8 rts;
+spinlock_t lock; /* access lock */
+wait_queue_head_t delta_msr_wait; /* wait queue for modem status */
+unsigned baud_rate; /* set baud rate */
+u8 line_control; /* set line control value RTS/DTR */
+u8 line_status; /* active status of modem control inputs */
+u8 multi_status_change; /* status changed multiple since last call */
};
static int ch341_control_out(struct usb_device *dev, u8 request,
-u16 value, u16 index)
+u16 value, u16 index)
{
- int r;
- dbg("ch341_control_out(%02x,%02x,%04x,%04x)", USB_DIR_OUT|0x40,
- (int)request, (int)value, (int)index);
+ int r;
+ dbg("ch341_control_out(%02x,%02x,%04x,%04x)", USB_DIR_OUT|0x40,
+ (int)request, (int)value, (int)index);
- r = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), request,
- USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
- value, index, NULL, 0, DEFAULT_TIMEOUT);
+ r = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), request,
+ USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ value, index, NULL, 0, DEFAULT_TIMEOUT);
- return r;
+ return r;
}
static int ch341_control_in(struct usb_device *dev,
- u8 request, u16 value, u16 index,
- char *buf, unsigned bufsize)
+ u8 request, u16 value, u16 index,
+ char *buf, unsigned bufsize)
{
- int r;
- dbg("ch341_control_in(%02x,%02x,%04x,%04x,%p,%u)", USB_DIR_IN|0x40,
- (int)request, (int)value, (int)index, buf, (int)bufsize);
-
- r = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), request,
- USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
- value, index, buf, bufsize, DEFAULT_TIMEOUT);
- return r;
-}
-
-static int ch341_set_baudrate(struct usb_device *dev,
- struct ch341_private *priv)
-{
- short a, b;
- int r;
-
- dbg("ch341_set_baudrate(%d)", priv->baud_rate);
- switch (priv->baud_rate) {
- case 2400:
- a = 0xd901;
- b = 0x0038;
- break;
- case 4800:
- a = 0x6402;
- b = 0x001f;
- break;
- case 9600:
- a = 0xb202;
- b = 0x0013;
- break;
- case 19200:
- a = 0xd902;
- b = 0x000d;
- break;
- case 38400:
- a = 0x6403;
- b = 0x000a;
[PATCH] Re: Serial USB-driver for Winchiphead CH340/41 chip
Hello,
attached you will find the patch against the 2.6.23-rc6-mm1
Changed fetaures:
1. All baudrates possible (dynamic baudfactor calculation)
2. Added support of modem control and status lines.
Still missing (due to lack of an usb sniffer):
1. Break control
2. Parity
Werner
--- linux-2.6.23-rc6-mm1/drivers/usb/serial/ch341.c 2007-09-21
09:56:56.0 +0200
+++ develop/drivers/usb/serial/ch341.c 2007-09-21 10:00:26.0 +0200
@@ -1,5 +1,9 @@
/*
- * Copyright 2007, Frank A Kingswood <[EMAIL PROTECTED]>
+ * Copyright 2007, Frank A Kingswood kingswood-consulting.co.uk>
+ *
+ * Copyright 2007, Werner Cornelius cornelius-consult.de>
+ * for changes/extenions regarding universal baud rate capability and modem
+ * line control/status routines.
*
* ch341.c implements a serial port driver for the Winchiphead CH341.
*
@@ -21,327 +25,548 @@
#include
#include
-#define DEFAULT_BAUD_RATE 2400
+#define DEFAULT_BAUD_RATE 9600
#define DEFAULT_TIMEOUT 1000
+/* flags for IO-Bits */
+#define CH341_BIT_RTS (1 << 6)
+#define CH341_BIT_DTR (1 << 5)
+
+/**/
+/* interrupt pipe definitions */
+/**/
+/* always 4 interrupt bytes */
+/* first irq byte normally 0x08 */
+/* second irq byte base 0x7d + below */
+/* third irq byte base 0x94 + below */
+/* fourth irq byte normally 0xee */
+
+/* second interrupt byte */
+#define CH341_MULT_STAT 0x04 /* multiple status since last interrupt event */
+
+/* status returned in third interrupt answer byte, inverted in data from irq
*/
+#define CH341_BIT_CTS 0x01
+#define CH341_BIT_DSR 0x02
+#define CH341_BIT_RI 0x04
+#define CH341_BIT_DCD 0x08
+#define CH341_BITS_MODEM_STAT 0x0f /* all bits */
+
+/***/
+/* baudrate calculation factor */
+/***/
+#define CH341_BAUDBASE_FACTOR 1532620800
+#define CH341_BAUDBASE_DIVMAX 3
+
static int debug;
static struct usb_device_id id_table [] = {
- { USB_DEVICE(0x4348, 0x5523) },
- { },
+ { USB_DEVICE(0x4348, 0x5523) },
+ { },
};
MODULE_DEVICE_TABLE(usb, id_table);
struct ch341_private {
- unsigned baud_rate;
- u8 dtr;
- u8 rts;
+spinlock_t lock; /* access lock */
+wait_queue_head_t delta_msr_wait; /* wait queue for modem status */
+unsigned baud_rate; /* set baud rate */
+u8 line_control; /* set line control value RTS/DTR */
+u8 line_status; /* active status of modem control inputs */
+u8 multi_status_change; /* status changed multiple since last call */
};
static int ch341_control_out(struct usb_device *dev, u8 request,
-u16 value, u16 index)
+u16 value, u16 index)
{
- int r;
- dbg("ch341_control_out(%02x,%02x,%04x,%04x)", USB_DIR_OUT|0x40,
- (int)request, (int)value, (int)index);
+ int r;
+ dbg("ch341_control_out(%02x,%02x,%04x,%04x)", USB_DIR_OUT|0x40,
+ (int)request, (int)value, (int)index);
- r = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), request,
- USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
- value, index, NULL, 0, DEFAULT_TIMEOUT);
+ r = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), request,
+ USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ value, index, NULL, 0, DEFAULT_TIMEOUT);
- return r;
+ return r;
}
static int ch341_control_in(struct usb_device *dev,
- u8 request, u16 value, u16 index,
- char *buf, unsigned bufsize)
+ u8 request, u16 value, u16 index,
+ char *buf, unsigned bufsize)
{
- int r;
- dbg("ch341_control_in(%02x,%02x,%04x,%04x,%p,%u)", USB_DIR_IN|0x40,
- (int)request, (int)value, (int)index, buf, (int)bufsize);
-
- r = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), request,
- USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
- value, index, buf, bufsize, DEFAULT_TIMEOUT);
- return r;
-}
-
-static int ch341_set_baudrate(struct usb_device *dev,
- struct ch341_private *priv)
-{
- short a, b;
- int r;
-
- dbg("ch341_set_baudrate(%d)", priv->baud_rate);
- switch (priv->baud_rate) {
- case 2400:
- a = 0xd901;
- b = 0x0038;
- break;
- case 4800:
- a = 0x6402;
- b = 0x001f;
- break;
- case 9600:
- a = 0xb202;
- b = 0x0013;
- break;
- case 19200:
- a = 0xd902;
- b = 0x000d;
- break;
- case 38400:
- a = 0x6403;
- b = 0x000a;
Serial USB-driver for Winchiphead CH340/41 chip
Hello, I know that there has been a patch for the Winchiphead CH340/41 USB to serial converter chips on the net, but they have been implemented with only a basic feature and limited baudrates due to the lack of any datasheets. I picked these patches up and added all common baudrates as well as the complete modem control and status handling to be able of using this adapter in nearly all applications. Features still missing: - character length other than 8 bits - parity settings - break control I don't have an USB sniffer, if someone may send me sniffer logs for various settings these features may be added to the driver of course. I am not listening on this mailing list, so please address me directly if there are any questions or comments. The patch is against the 2.6.22.5 kernel, but should work for newer kernels, too. Werner --- linux-2.6.22.5/Documentation/usb/usb-serial.txt 2007-08-23 01:23:54.0 +0200 +++ linux-2.6.22.5-cc/Documentation/usb/usb-serial.txt 2007-09-14 14:13:28.0 +0200 @@ -428,6 +428,19 @@ See http://www.uuhaus.de/linux/palmconnect.html for up-to-date information on this driver. +Winchiphead CH341 Driver + + This driver is for the Winchiphead CH341 USB-RS232 Converter. This chip + also implements an IEEE 1284 parallel port, I2C and SPI, but that is not + supported by the driver. The protocol was analyzed from the behaviour + of the Windows driver, no datasheet is available at present. + The manufacturer's website: http://www.winchiphead.com/. + For any questions or problems with this driver, please contact + frank kingswood-consulting.co.uk. + Extensions for universal baudrate settings and modem status/control has + been added by werner cornelius-consult.de. + + Generic Serial driver If your device is not one of the above listed devices, compatible with --- linux-2.6.22.5/drivers/usb/serial/Kconfig 2007-08-23 01:23:54.0 +0200 +++ linux-2.6.22.5-cc/drivers/usb/serial/Kconfig2007-09-11 11:53:58.0 +0200 @@ -92,6 +92,17 @@ To compile this driver as a module, choose M here: the module will be called belkin_sa. +config USB_SERIAL_CH341 + tristate "USB Winchiphead CH341 Single Port Serial Driver" + depends on USB_SERIAL + help + Say Y here if you want to use a Winchiphead CH341 single port + USB to serial adapter. + + To compile this driver as a module, choose M here: the + module will be called ch341. + + config USB_SERIAL_WHITEHEAT tristate "USB ConnectTech WhiteHEAT Serial Driver" depends on USB_SERIAL --- linux-2.6.22.5/drivers/usb/serial/Makefile 2007-08-23 01:23:54.0 +0200 +++ linux-2.6.22.5-cc/drivers/usb/serial/Makefile 2007-09-11 11:54:39.0 +0200 @@ -15,6 +15,7 @@ obj-$(CONFIG_USB_SERIAL_AIRPRIME) += airprime.o obj-$(CONFIG_USB_SERIAL_ARK3116) += ark3116.o obj-$(CONFIG_USB_SERIAL_BELKIN)+= belkin_sa.o +obj-$(CONFIG_USB_SERIAL_CH341) += ch341.o obj-$(CONFIG_USB_SERIAL_CP2101)+= cp2101.o obj-$(CONFIG_USB_SERIAL_CYBERJACK) += cyberjack.o obj-$(CONFIG_USB_SERIAL_CYPRESS_M8)+= cypress_m8.o --- linux-2.6.22.5/drivers/usb/serial/ch341.c 1970-01-01 01:00:00.0 +0100 +++ linux-2.6.22.5-cc/drivers/usb/serial/ch341.c2007-09-14 13:43:28.0 +0200 @@ -0,0 +1,579 @@ +/* + * Copyright 2007, Frank A Kingswood kingswood-consulting.co.uk> + * + * Copyright 2007, Werner Cornelius cornelius-consult.de> + * for changes/extenions regarding universal baud rate capability and modem + * line control/status routines. + * + * ch341.c implements a serial port driver for the Winchiphead CH341. + * + * The CH341 device can be used to implement an RS232 asynchronous + * serial port, an IEEE-1284 parallel printer port or a memory-like + * interface. In all cases the CH341 supports an I2C interface as well. + * This driver only supports the asynchronous serial interface. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version + * 2 as published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include +#include + +#define DEFAULT_BAUD_RATE 9600 +#define DEFAULT_TIMEOUT 1000 + +/* flags for IO-Bits */ +#define CH341_BIT_RTS (1 << 6) +#define CH341_BIT_DTR (1 << 5) + +/**/ +/* interrupt pipe definitions */ +/**/ +/* always 4 interrupt bytes */ +/* first irq byte normally 0x08 */ +/* second irq byte base 0x7d + below */ +/* third irq byte base 0x94 + below */ +/* fourth irq byte normally 0xee */ + +/* second interrupt byte */ +#define CH341_MULT_STAT 0x04 /* multiple status since last interrupt event */ + +/* status returned in third
PROBLEM: Network sky2 Module
[1.] One line summary of the problem: hw csum failure appears in syslog [2.] Full description of the problem/report: hw csum failure appears in syslog and sometimes, under heavy network utilization, with NFS-Daemon the Network Device totally fails. Then no Network Access is possible. Reboot is not required but i must restart the Network with the following commands: "ifdown eth0" and "rmmod sky2", then "insmod sky2" and "ifup eth0". [3.] Keywords (i.e., modules, networking, kernel): sky2 (Marvell Yukon Onboard Ethernet), networking, checksum [4.] Kernel version (from /proc/version): Linux version 2.6.18.8 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #6 SMP Sun Aug 5 15:09:57 CEST 2007 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) endeavour:~ # dmesg -c : hw csum failure. Call Trace: [] __skb_checksum_complete+0x4a/0x62 [] udp_poll+0x67/0xf3 [] do_select+0x285/0x46d [] __pollwait+0x0/0xe0 [] default_wake_function+0x0/0xe [] _spin_lock_bh+0x9/0x14 [] release_sock+0x13/0xaa [] udp_sendmsg+0x480/0x563 [] sock_sendmsg+0xf3/0x110 [] sock_recvmsg+0x101/0x120 [] autoremove_wake_function+0x0/0x2e [] sock_aio_write+0x51/0x60 [] try_to_wake_up+0x3e2/0x3f3 [] sys_select+0x26f/0x3d6 [] sys_sendto+0x119/0x14c [] system_call+0x7e/0x83 [6.] A small shell script or example program which triggers the problem (if possible) - [7.] Environment Homebrew Server (Asus P5WDG2-WS Motherboard). [7.1.] Software (add the output of the ver_linux script here) Linux endeavour 2.6.18.8 #6 SMP Sun Aug 5 15:09:57 CEST 2007 x86_64 x86_64 x86_6 4 GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17.50.0.5 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.39 jfsutils 1.1.11 reiserfsprogs 3.6.19 xfsprogs 2.8.11 PPP2.4.4 Linux C Library> libc.2.5 Dynamic linker (ldd) 2.5 Procps 3.2.7 Net-tools 1.60 Kbd1.12 Sh-utils 6.4 udev 103 Modules Loaded capability commoncap sky2 nfs lockd nfs_acl sunrpc iptabl e_filter ip_tables x_tables nls_utf8 af_packet w83627ehf hwmon i2c_isa eeprom i2 c_dev joydev st sd_mod ide_cd truecrypt nls_iso8859_1 nls_cp437 vfat fat vmnet v mmon ipv6 button battery ac sg sr_mod cdrom loop usb_storage scsi_mod dm_mod i2c _i801 shpchp pci_hotplug ehci_hcd uhci_hcd i2c_core usbcore floppy parport_pc lp parport ext3 mbcache jbd edd fan piix thermal processor ide_disk ide_core [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 6 model name : Intel(R) Pentium(R) D CPU 3.60GHz stepping: 4 cpu MHz : 3612.869 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips: 7231.81 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual [7.3.] Module information (from /proc/modules): capability 22536 0 - Live 0x88435000 commoncap 25472 1 capability, Live 0x8842d000 sky2 61444 0 - Live 0x8811b000 nfs 275768 0 - Live 0x883e8000 lockd 86800 1 nfs, Live 0x883d1000 nfs_acl 20608 1 nfs, Live 0x883ca000 sunrpc 193224 3 nfs,lockd,nfs_acl, Live 0x88399000 iptable_filter 20096 0 - Live 0x88393000 ip_tables 39656 1 iptable_filter, Live 0x88388000 x_tables 35336 1 ip_tables, Live 0x8837e000 nls_utf8 19072 0 - Live 0x88378000 af_packet 57356 0 - Live 0x88368000 w83627ehf 33548 0 - Live 0x8835e000 hwmon 20488 1 w83627ehf, Live 0x88357000 i2c_isa 23040 1 w83627ehf, Live 0x8835 eeprom 24976 0 - Live 0x88348000 i2c_dev 28168 0 - Live 0x8834 joydev 28160 0 - Live 0x88338000 st 57764 0 - Live 0x88328000 sd_mod 39296 0 - Live 0x8831d000 ide_cd 59552 0 - Live 0x8830d000 truecrypt 173088 1 - Live 0x882c nls_iso8859_1 22144 1 - Live 0x88306000 nls_cp437 23808 1 - Live 0x882ff000 vfat 31104 1 - Live 0x8822 fat 73008 1 vfat, Live 0x882ec000 vmnet 76976 21 - Live 0
Problems with kernel 2.6.22-git15, 2.6.23-rc1
There are incompatibilities in kmem_cache_create , which makes that a lot of important progs dont compile longer -- such as ndiskwrapper , btrfs (in this file system, me and other people storage important data) and others. Also obexfs/bluetooth seems to dont work more correctly, however by other incompatibility This is since 2.6.22-git15 and on 2.6.23-rc1 , too The kernel need to stay compatible to old versions of the file system and other fundamental programs. Please correct this Werner Landgraf www.copaya.yi.org Example: == /usr/local/src/btrfs-0.2/inode.c: In function 'btrfs_init_cachep': /usr/local/src/btrfs-0.2/inode.c:1941: error: too many arguments to function 'kmem_cache_createmake[1]: Leaving directory `/usr/src/linux-2.6.23-rc1-i486-1mn' ts to function 'kmem_cache_create' /usr/local/src/btrfs-0.2/inode.c:1955: error: too many arguments to function 'kmem_cache_create' /usr/local/src/btrfs-0.2/inode.c:1962: error: too many arguments to function 'kmem_cache_create' /usr/local/src/btrfs-0.2/inode.c:1970: error: too many arguments to function 'kmem_cache_create' make[2]: *** [/usr/local/src/btrfs-0.2/inode.o] Error 1 make[1]: *** [_module_/usr/local/src/btrfs-0.2] Error 2 make: *** [all] Error 2
copy: Problems with kernel 2.6.22-git15, 2.6.23-rc1
There are incompatibilities in kmem_cache_create , which makes that a lot of important progs dont compile longer -- such as ndiskwrapper , btrfs (in this file system, me and other people storage important data) and others. Also obexfs/bluetooth seems to dont work more correctly, however by other incompatibility This is since 2.6.22-git15 and on 2.6.23-rc1 , too The kernel need to stay compatible to old versions of the file system and other fundamental programs. Please correct this Werner Landgraf www.copaya.yi.org Example: == /usr/local/src/btrfs-0.2/inode.c: In function 'btrfs_init_cachep': /usr/local/src/btrfs-0.2/inode.c:1941: error: too many arguments to function 'kmem_cache_createmake[1]: Leaving directory `/usr/src/linux-2.6.23-rc1-i486-1mn' ts to function 'kmem_cache_create' /usr/local/src/btrfs-0.2/inode.c:1955: error: too many arguments to function 'kmem_cache_create' /usr/local/src/btrfs-0.2/inode.c:1962: error: too many arguments to function 'kmem_cache_create' /usr/local/src/btrfs-0.2/inode.c:1970: error: too many arguments to function 'kmem_cache_create' make[2]: *** [/usr/local/src/btrfs-0.2/inode.o] Error 1 make[1]: *** [_module_/usr/local/src/btrfs-0.2] Error 2 make: *** [all] Error 2
Incompatibilities of kmem_cache_create
Of the kernel 2.6.22-git15 of this night, kmem_cache_create is not compatible and causes compiling errors of some fundamental programs. Before, this error didnt occur. At least this happened on compiling the externel modules for btrfs and ndiskwrapper.Principally the compatibility of the Kernel with older and new versions of the file systems have to be observed very good, for the reliability to can read dates. Thus this should be checked, and corrected Werner Landgraf [EMAIL PROTECTED] www.copaya.yi.org
Kernel Error / Crash
To: linux-kernel@vger.kernel.org copied from the screen: ... proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) Starting udevd: /sbin/udevd -- daemon [cut here]--- Kernel BUG at mm/slub.c:2401! Invalid opcode: [#1] SMP Modules linked in: CPU: 0 EIP: 0060: [] Not tainted VLI EFLAGS: 00010046 (2.6.22-git13-i486-1mn #1) EIP is at ksize + 0x40/0x50 . Obs: With 2.6.22-git11 that problem didnt occur Werner Landgraf [EMAIL PROTECTED]
Memory stick reader Ricoh R5C592 supported?
Folks, my Dell Inspiron 6400 laptop has both a Ricoh R5C822 host adapter (for SD, MMC, etc.) and a Ricoh R5C592 host adapter for memory sticks. While the former works just fine, it seems to me that the latter hasn't any support. Indeed, inserting a Sony MSA-128A memory stick causes no reaction whatsoever. Searching with google, I haven't found anything related to this chip; looking into the kernel source code wasn't successful either. Can you please shed some light on the current situation? I'm using kernel 2.6.20. Werner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] partitions/msdos.c
Andries Brouwer wrote: > In other words, we need the user space command `partition', > where "partition -t dos /dev/sda" reads a DOS-type partition > table. So if you e.g. hotplug a new device, its partitions won't be accessible before you (or some hotplug manager, etc.) run "partition" ? > The two variants are: (i) partition tells the kernel > to do the partition table reading, and (ii) partition uses partx > to read the partition table and tells the kernel one-by-one > about the partitions found this way. I guess, once you've reached the point where the kernel is unable to find partitions without user-space help, you may as well do everything in user space. > Since this is a fundamental change, Pretty much, yes. Except for a few embedded systems (*), this would mark the end of kernels that can do anything useful without initrd or initramfs. (*) Oh, regarding the other exception, ceterum censeo nfsroot esse delendam. > a long transition period > is needed, and that period could start with a kernel boot parameter > telling the kernel not to do partition table parsing on a particular > disk, or a particular type of disks, or all disks. ... and allow "partition" to override partitions previously auto-detected by the kernel. That way, you can phase in "partition" without needing to change your kernel setup. Besides, the ability to correct past mistakes would also be useful if auto-detection from user space yields garbage. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts
Erik van Konijnenburg wrote: > Yaird is intended to find out whether that assumption is correct: if so, > a program to build initrd images will be more reliable if it's written > in perl, if it uses sysfs to determine what hardware needs to be supported, > and if it closely follows the methods hotplug uses find the modules > needed to support some hardware. This is great, and was long overdue. Thanks for fixing my sins of omission dating back from 1996 :-) - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Friday 11 March 2005 10:04, Jesse Barnes wrote: > On Friday, March 11, 2005 9:59 am, Bjorn Helgaas wrote: > > > Right, it's a special agp driver, sgi-agp.c. > > > > Where's sgi-agp.c? The HP (ia64-only at the moment) code is hp-agp.c. > > It does make a fake PCI dev for the bridge because DRM still seemed to > > want that. > > I think Mike posted it but hasn't submitted it to Dave yet since it needed > another change that only just made it into the ia64 tree. > > Jesse > Hi, sgi-agp.c was sent to Dave about 2 weeks ago. I assumed he was waiting for the TIO header files to make it from the ia64 tree into Linus's tree. Yours, Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6
Eric W. Biederman wrote: > For detecting devices especially in the case that takes > a while that isn't something we need to do early > in the boot process. Yes, but I'd rather have a generic mechanism that works in all reasonable cases. Things have a tendency of growing in the oddest directions. E.g. when introducing the boot command line, all I had in mind was to have a way to boot single-user mode :-) > Well the data structure is still yet to be defined. The > question you raised is how to pass it. Err yes, that's what I wanted to say :) Some new mechanism to pass the data, or a weird data structure instead of (as opposed to be on) initrd/initramfs. > Something like that.I have yet to see a even a proof of concept > of the idea of passing device information, to clean up probes. Yes, the kexec-based boot loader first, then this. For a kexec-based boot loader, passing device scan results will be very useful, plus it's a good environment for experimenting with such a feature. - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm2
Ingo Molnar wrote: > the pro applications will always want to have a 100% guarantee (it > really sucks to generate a nasty audio click during a live performance) ... and the "generic kernels" distributions use will follow just as swiftly, as soon as the feature appears stable enough. It even makes sense: no need to switch kernels if "pro audio" applications (or whatever else may end up wanting this) are added to the mix, and fewer configurations to test. You can run, but you cannot hide :-) - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6
Eric W. Biederman wrote: > Actually this is trivial to do by using a file in initramfs. > If we need something in a well defined format anyway. Yes, constructing an additional initramfs, or modifying an existing one to hold such data is certainly a possibility. I think there are mainly three choices: 1) the command line 2) an initramfs 3) some other, yet to be defined data structure 1) is relatively easy to do, but leads to more little parsers and doesn't scale too well. 2) scales well but has a relatively high overhead (constructing/scanning a cpio archive, etc., particularly for items needed early in the boot process), and does not work too well for discontiguous data structures. 3) is of course what we should try to avoid :-) So far, I also think that using an initramfs, or at least something that looks like one, even if not normally used as such, is the thing to try first. - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arp_queue: serializing unlink + kfree_skb
David S. Miller wrote: > Absolutely, I agree. My fingers even itched as I typed those lines > in. I didn't change the wording because I couldn't come up with > anything better. How about something like: Unlike the above routines, atomic_???_return are required to perform memory barriers [...] I think "implicit" and "explicit" here are just confusing, because you don't define them, and there's no intuitively correct meaning either. Perhaps a little warning could also be useful for the reader who wasn't paying close attention to whose role is described: Note: this means that a caller of atomic_add, etc., who needs a memory barrier before or after that call has to code the memory barrier explicitly, whereas a caller of atomic_???_return can rely on said functions to provide the barrier without further ado. For the implementor of the atomic functions, the roles are reversed. > You still get the memory barrier, whether you read the return > value or not. That might be something worth mentioning. Not that a construct is used that gcc can optimize away when nobody cares about the return value. - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arp_queue: serializing unlink + kfree_skb
David S. Miller wrote: > This document is intended to serve as a guide to Linux port > maintainers on how to implement atomic counter and bitops operations > properly. Finally, some light is shed into one of the most arcane areas of the kernel ;-) Thanks ! > Unlike the above routines, it is required that explicit memory > barriers are performed before and after the operation. It must > be done such that all memory operations before and after the > atomic operation calls are strongly ordered with respect to the > atomic operation itself. Hmm, given that this description will not only be read by implementers of atomic functions, but also by users, the "explicit memory barriers" may be confusing. Who does them, the atomic_* function, or the user ? In fact, I would call them "implicit", because they're hidden in the atomic_foo functions :-) > void smb_mb__before_atomic_dec(void); > void smb_mb__after_atomic_dec(void); > void smb_mb__before_atomic_inc(void); > void smb_mb__after_atomic_dec(void); s/smb_/smp/ :-) Do they also work for atomic_add and atomic_sub, or do we have to fall back to smb_mb or atomic_add_return (see below) there ? > With the memory barrier semantics required of the atomic_t > operations which return values, the above sequence of memory > visibility can never happen. What happens if the operation could return a value, but the user ignores it ? E.g. if I don't like smp_mb__*, could I just use atomic_inc_and_test(foo); instead of smp_mb__before_atomic_inc(); atomic_inc(foo); smp_mb__after_atomic_dec(); ? If yes, is this a good idea ? > These routines, like the atomic_t counter operations returning > values, require explicit memory barrier semantics around their > execution. Very confusing: the barriers aren't around the routines (that is something the user would be doing), but around whatever does the atomic stuff inside them. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/8] lib/sort: turn off self-test
Matt Mackall wrote: > It's a nice self-contained unit test. By the way, I think it would be useful if there was a more formalized frame for such unit tests, so that they could be used in automated kernel testing. To avoid false positives when grepping through the code, perhaps such tests could be placed in separate files, using a different extension, e.g. .ct for ".c test", or in some "test" directory. (That is, in case they're distributed along with the kernel code, which, IMHO, would help to avoid code drift.) Just an idea ... - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6
Andi Kleen wrote: > It's dependent on the architecture already. I would like to enable > it on i386/x86-64 because the kernel command line is often used > to pass parameters to installers, and having a small limit there > can be awkward. Something to keep in mind when extending the command line is that we'll probably need a mechanism for passing additional (and possibly large) data blocks from the boot loader soon. The reason for this is that, if booting through kexec, it would be attractive to pass device scan results, so that the second kernel doesn't have to repeat the work. As an obvious extension, anyone who wants to boot *quickly* could also pass such data from persistent storage without actually performing the device scan at all when the machine is booted. The command line may be suitable for this, but to allow for passing a lot of data, its place in memory should perhaps just be reserved, at least until the system has passed initialization, without trying to copy it to a "safe" place early in kernel startup. - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling
[ Cc:s trimmed, added abiss-general ] Con Kolivas wrote: > Possibly reiserfs journal related. That has larger non-preemptible code > sections. If I understand your workload right, it should consist mainly of computation, networking (?), and disk reads. I don't know much about ReiserFS, but in some experiments with ext3, using ABISS, we found that a reader application competing with best effort readers would experience worst-case delays of dozens of milliseconds. They were caused by journaled atime updates. Mounting the file system with "noatime" reduced delays to a few hundred microseconds (still worst-case). - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-tracecalls, a clarification
Carl Spalletta wrote: > +#The name of an operations structure member, wrongly interpreted by > +#cscope as the name of an actual function - it should be ignored, > +#since it has been confused by cscope with the name of some actual > +#caller. HOWEVER the callbacks are found anyway, under their actual > names. > +#and if any function pointed to by a callback is part of a chain to > +#our initial target it _will_ be found, the same as any other caller. Hmm, but it doesn't seem to follow function pointers anyway. Example: http://www.linuxrd.com/~carl/cgi-bin/lnxtc.pl?file=fs/jbd/transaction.c&func=do_get_write_access should contain, among many others, this call chain: fs/read_write.c:sys_read fs/read_write.c:vfs_read fs/ext3/file.c:ext3_file_operations.read = fs/read_write.c:do_sync_read fs/ext3/file.c:ext3_file_operations.aio_read = mm/filemap.c:generic_file_aio_read mm/filemap.c:__generic_file_aio_read include/linux/fs.h:do_generic_file_read mm/filemap.c:do_generic_mapping_read include/linux/fs.h:file_accessed include/linux/fs.h:touch_atime fs/inode.c:update_atime include/linux/fs.h:mark_inode_dirty_sync fs/fs-writeback.c:__mark_inode_dirty fs/ext3/super.c:ext3_sops.dirty_inode = fs/ext3/inode.c:ext3_dirty_inode include/linux/ext3_jbd.h:ext3_journal_get_write_access fs/jbd/transaction.c:journal_get_write_access fs/jbd/transaction.c:do_get_write_access Note the three functions pointers that were used in this. This kind of construct is extremely common in the kernel, and it's usually the main source of confusion that will actually make one want to use a call chain discovery tool. I see that you're handling inline functions correctly. Another thing that seems to be missing are macros. E.g. this query http://www.linuxrd.com/~carl/cgi-bin/lnxtc.pl?file=include/linux/seqlock.h&func=seqcount_init should probably have found the reference in fs.h (it's somewhat obscured by #ifdefs, so, depending on how your tree was set up, the response may actually be correct). Also, this query should have returned something: http://www.linuxrd.com/~carl/cgi-bin/lnxtc.pl?file=include/linux/blkdev.h&func=blk_queue_plugged Since the call trees fan out very quickly (in either direction), I think an interactive browser that lets you select which branch(es) to follow (while remembering the chain you've already visited) would be more useful than a huge dump that may require significant post-processing. It would also be nice to be able to go both ways, from called to caller, and from caller to called. Again, the tricky bit here are the function pointers. I think that a tool that can handle the most common idioms found in the kernel would be very useful. - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Instrumentation (was Re: 2.6.11-rc1-mm1)
[ 3rd try. Apologies to Karim, Thomas, and Roman, who apparently also received my previous attempts. For some reason, one of my upstream DNS servers decided to send me highly bogus MX records. ] Karim Yaghmour wrote: > Might I add that this is part of the problem ... No personal > offence intended, but there's been _A LOT_ of things said about > LTT that were based on third-hand account and no direct contact > with the toolset/code. Sigh, yes, guilty as charged ... At least today, I have a good excuse: my cable modem died, and I couldn't possibly have download things to look at :) > > As far as kprobes go, then you still need to have some form or another > > of marking the code for key events, unless you keep maintaining a set > > of kprobes-able points separately, which really makes it unusable for > > the rest of us, as the users of LTT have discovered over time (having > > to create a new patch for every new kernel that comes out.) Yes, I think you will need some set of "pads" in the code, where you can attach probes. I'm not sure how many, though. An alternative, at least in some cases, would be to move such things into separate functions, so that you could put the probe just at function entry. Then add a comment that this function isn't supposed to be torn apart without dire need. > > Generating new interrupts is simply unacceptable for LTT's functionality. Absolutely. If I remember correctly, this is in the process of being addressed in kprobes. You basically have the following choices: - if the probe target is an instruction long enough, replace it with a jump or call (that's what I think the kprobes folks are working on. I remember for sure that they were thinking about it.) - if the probe target is in a basic block with enough room after the target, see above (needs feedback from compiler or assembler) - if all else fails, add some NOPs (i.e. the marker approach) > I have received very little feedback on this suggestion, Probably because everybody saw that it was good :-) > As for the location of ltt trace points, then they are very rarely > at function boundaries. Here's a classic: > prepare_arch_switch(rq, next); > ltt_ev_schedchange(prev, next); > prev = context_switch(rq, prev, next); Yes, in some cases, you don't have a choice but to add some marker. > > Removing this data would require more data for each event to > > be logged, and require parsing through the trace before reading it in > > order to obtain markers allowing random access. So you need seeking, even in the presence of fine-grained control over what gets traced in the first place ? (As opposed to extracting the interesting data from the full trace, given that the latter shouldn't contain too much noise.) > If I understand you correctly, you are talking about the fact that > the transport layer's management of the buffers is syncrhonized > with some user-space entity that consumes the buffers produced > and talks back to relayfs (albeit indirectly) to let it know that > said buffers are now available? Or that they have been consumed. My question is just whether this kind of aggregation is something you need. > I have nothing against kprobes. People keep refering to it as if > it magically made all the related problems go away, and it doesn't. Yes, I know just too well :-) In umlsim, I have pretty much the same problems, and the solutions aren't always nice. So far, I've been lucky enough that I could almost always find a suitable function entry to abuse. However, since a kprobes-based mechanism is - in the worst case, i.e. when needing markup - as good as direct calls to LTT, and gives you a lot more flexibility if things aren't quite as hostile, I think it makes sense to focus on such a solution. > Nothing precludes us to move in this direction once something is > in the kernel, it's all currently hidden away in a .h, and it would > be the same with this. Yup, but you could move even more intelligence outside the kernel. All you really need in the kernel is a place to put the probe, plus some debugging information to tell you where you find the data (the latter possibly combined with gently coercing the compiler to put it at some accessible place). - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] Re: [PATCH 0/29] overview
Eric W. Biederman wrote: > The hard one there is support of arbitrary OS's. Bah, couldn't care less :-) If all else fails, you can fall back to the "old-style" boot loader, and let this one boot the legacy OS. (Well, for GRUB, you'd need the fallback extension, if this isn't a standard feature yet.) > Most people want to implement simple boot policies, > and really don't care for the full complexity that some firmware > solutions allow. So what I have seen is people will take kexec > and implement their custom policy instead of doing something complex. I think many of them would just be as happy with a more complex solution, as long as it comes in a nice bundle. Of course, if there is no nice package to start from, they'll only implement the bare minimum. Also, in most cases, we can probably ignore space issues for now, leave some room for experiments, and optimize later. > The goal > now is to build enough confidence so that we can move from the > development to the stable kernel. Yes, that's what I mean with it being in "mainline". For user space to begin making use of kexec, it really should be part of a kernel most people can accept for regular use. > Want to help? Trying to, by explaining why it should move on :-) Anything else you need ? - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] Re: [PATCH 0/29] overview
Eric W. Biederman wrote: > To some extent. It is worth noting that the first 13 of my patches > are not core functionality they are bug fixes or feature enhancements > of code that simply have come to be associated with the work on kexec. Good point. I didn't even think of the low-level parts of the boot process. I'm more worried about the high-level side. Since GRUB, not much seems to have happened. I think we should have a much richer boot environment by now. We're still not even at the level of functionality typically found in the boot PROMs of classical Unix workstations, whereas I think we should have been running circles around them for years already. So if there was a vote to be cast for getting kexec into mainline as quickly as possible, you'd certainly have mine :-) - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Instrumentation (was Re: 2.6.11-rc1-mm1)
>From all I've heard and seen of LTT (and I have to admit that most of it comes from reading this thread, not from reading the code), I have the impression that it may try to be a bit too specialized, and thus might miss opportunities for synergy. You must be getting tired of people trying to redesign things from scratch, but maybe you'll humor me anyway ;-) Karim Yaghmour wrote: > If you really want to define layers, then there are actually four > layers: > 1- hooking mechanism > 2- event definition / registration > 3- event management infrastructure > 4- transport mechanism For 1, kprobes would seem largely sufficient. In cases where you don't have a usable attachment point (e.g. in the middle of a function and you need access to variables with unknown location), you can add lightweight instrumentation that arranges the code flow suitably. [1, 2] 2 and 3 should be the main domain of LTT, with 2 sitting on top of kprobes. kprobes currently doesn't have a nice way for describing handlers, but that can be fixed [3]. But you probably don't need a "nice" interface right now, but might be satisfied with one that works and is fast (?) >From the discussion, it seems that the management is partially done by relayfs. I find this a little strange. E.g. instead of filtering events, you may just not generate them in the first place, e.g. by not placing a probe, or by filtering in LTT, before submitting the event. Timestamps may be fine either way. Restoring sequence should be a task user-space can handle: in the worst case, you'd have to read and merge from #cpus streams. Seeking works in that context, too. Last but not least, 4 should be simple. Particularly since you're worried about extreme speeds, there should be as little processing as you can afford. If you need to seek efficiently (do you, really ?), you may not even want message boundaries at that level. Something that isn't entirely clear to me is if you also need to aggregate information in buffers. E.g. by updating a record until is has been retrieved by user space, or by updating a record when there is no space to create a new one. Such functionality would add complexity and needs tight sychronization with the transport. [1] I've seen the argument that kprobes aren't portable. This strikes me a highly questionable. Even if an architecture doesn't have a trap instruction (or equivalent code sequence) that is at least as short as the shortest instruction, you can always fall back to adding instrumentation [2]. Also, if you know where your basic blocks are, you may be able to use traps that span multiple instructions. I recall that things of this kind are already planned for kprobes. [2] See the "reliable markers" of umlsim from umlsim.sf.net. Implementation: cd umlsim/lib; make; tail -50 markers_kernel.h Examples: cd umlsim/sim/tests; cat sbug.marker They're basically extra-light markup in the source code. Works on ia32, but I haven't found a way to get the assembler to cooperate for amd64, yet. [3] I've already solved this problem in umlsim: there, I have a Perl/C-like scripting language that allows handlers to do pretty much anything they want. Of course, kprobes would want pre-compiled C code, not some scripts, but I think the design could be developped in a direction that would allow both. Will take a while, but since I'll eventually have to rewrite the "microcode" anyway, ... So my comments are basically as follows: 1) kprobes seems like a suitable and elegant mechanism for placing all the hooks LTT needs, so I think that it would be better to build on this basis, and extend it where necessary, than to build yet another specialized variant in parallel. 2) LTT should do what it is good at, and not have to worry about the rest (i.e. supporting infrastructure). 3) relayfs should be lean and fast, as you intend it to be, so that non-LTT tracing or fnord debugging fnord code may find it useful, too. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Wait and retry mounting root device (revised)
William Park wrote: > The problem at hand is that USB key drive (which is my immediate > concern) takes 5sec to show up. So, it's much better approach than > 'initrd'. I'm a little biased, but I disagree ;-) The main problems with initrd seem to be that it adds at least one more moving part, and that most initrd-making procedures give you something non-interactive that hardly interacts with the outside world. Lo and behold, nobody likes sudden silent failure of a complex and opaque subsystem, particularly if it happens to be vitally important. I think initrds could be greatly improved by including a BusyBox in their failure paths (plus a way to manually enter the BusyBox, in case apparent success still means failure). That way, you can actually try to fix things if there are problems. Another issue is configuration data that has to exist in the initrd, yielding a possibly complex initrd construction process that has to follow each configuration change. Also there, an initrd could be able to try to access the regular file system to access such information, possibly combined with caching and heuristics. (I realize that this isn't trivial and bears a high risk of intractable failure paths, but I also think that it's worth exploring this direction.) Regarding the delayed mount problem, I think some retry procedure may be the best possible band-aid for a while. While it would be desirable for the USB subsystem (etc.) to just block until the device is ready, this doesn't work so well if the presence of the device can't be predicted at that point, e.g. if a "devfs" (udev, etc.) name has to be looked up first. I'm not sure I understand Al's concern with devices popping up in the middle of the loop. For all practical purposes, mounting the root file system has a single target anyway, so it can't really compete with anything else. Automatically selected alternative roots can make sense, but that's sufficiently policy-ish that I think it would be better kept in an initrd, where instrumentation is more naturally added than in the kernel. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Proper procedure for reporting possible security vulnerabilities?
Chris Wright wrote: > +SECURITY CONTACT > +P: Security Officers > +M: [EMAIL PROTECTED], vger.kernel.org, wherever} > +S: Supported If you mean this in the sense of "choose one, then put it here", this looks good. If you're suggesting multiple choices, to be made by the bug reporter, I'm not so sure. A single contact point, preferably with a human being that can confirm that the message has been received and understood, and indicate that there's now somebody taking care of it who knows what to do (which may just be forwarding it to someone else or some list, and monitoring the reaction), should be useful. - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cherokee Nation Posts Open Source Legisation - Invites comments from Community Members
Rik van Riel wrote: > Only secrets can be trade secrets. I think he's just trying to re-invent patents under a different name. IMHO, this isn't necessarily an outright lunatic idea, but I wouldn't be surprised if it received a friendlier reception if contradictory naming could be avoided. - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix: macros to detect existance of unlocked_ioctl and compat_ioctl
[ Cc:s trimmed a little ] Greg KH wrote: > Sorry, the "policy" I was referring to was the "out-of-the-tree drivers > are on their own" statement. Not the use of the HAVE macros. Not all users of kernel code are in- or out-of-tree drivers and the like. E.g. tcsim (from tcng.sf.net) grabs substantial portions of the traffic control and netlink code and merges them with user space. It also tries to be compatible with most 2.4 kernels. For feature tests, I use basically anything that doesn't run away quickly enough. And I'm sure you want none of *that* kind of code anywhere near mainline ;-) Not that I currently have more troubles with it than usually. I just want to point out that there are other, strange but legitimate (at least in the "all shall eventually be GPL" sense) users of the kernel, who don't mind a friendly environment. - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #define HZ 1024 -- negative effects?
On Wed, 25 Apr 2001, Dan Maas wrote: > > Are there any negative effects of editing include/asm/param.h to change > > HZ from 100 to 1024? Or any other number? This has been suggested as a > > way to improve the responsiveness of the GUI on a Linux system. > > I have also played around with HZ=1024 and wondered how it affects > interactivity. I don't quite understand why it could help - one thing I've > learned looking at kernel traces (LTT) is that interactive processes very, > very rarely eat up their whole timeslice (even hogs like X). So more > frequent timer interrupts shouldn't have much of an effect... > > If you are burning CPU doing stuff like long compiles, then the increased HZ > might make the system appear more responsive because the CPU hog gets > pre-empted more often. However, you could get the same result just by > running the task 'nice'ly... A tradeoff of having better system responsiveness by having the kernel to check more often if a running process should be preempted is that the CPU spends more time in Kernel Mode and less time in User Mode. And as a consequence, user programs run slower. Regards, Werner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.3 - Problems with poweroff
I have trouble with the APM in kernel 2.4.3. I'm booting Win98SE and run loadlin 1.6a to booting the linux kenel 2.4.3. Everything goes ok, but my machine will not turn off if I use the command poweroff. If I booting MS-DOS 6.22 from disk at the same machine, then running the same loadlin and loading the same kernel, then the poweroff command will turn off my computer. I'm not sure if this is a kernel specific problem, but I don't know where to ask to help me. I don't understand, whats the difference to load the kernel from Win98SE or from MS-Dos 6.22. Maybe someone can help me. Thanks Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] The Janitor Project
Arnaldo Carvalho de Melo wrote:
> http://bazar.conectiva.com.br/~acme/TODO
BTW, I don't know if you're already interacting, but it seems to me that
there are a lot of things on your list that look as if the MC project at
Stanford ("CHECKER") could provide automated tests for them.
- Werner
--
_____
/ Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regression testing
Eric W. Biederman wrote: > Yes user-mode linux > could help here (you could stress test the core kernel without worry > that when it crashes your machine will crash as well). A similar approach can be used for very detailed tests of specific subsystems. E.g. that's what we've started doing, kind of as a by-product of some other work, with tcsim, which runs most of the traffic control subsystem in user space. (ftp://icaftp.epfl.ch/pub/linux/tcng/) The advantage over using UML is that we have a much simpler environment, allowing for more straightforward integration, and we can exercise tight control over infrastructure parts like timers or network events. Once UML is part of the mainstream kernel, it would be interesting to try to obtain the same functionality with UML too. Some added goodies include the ability to run kernel code with malloc debuggers like Electric Fence, which has already helped to find a few real bugs. (Does EFence work with UML ?) - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question \ information request on init \ boot sequence when using initrd
Amit D Chaudhary wrote: > To put it in brief, since running sbin/init from /linuxrc as resulting > in init not having PID 1 and thereby not doing some initialization as > expected. Easy solution: don't run linuxrc, run something else instead. E.g. putting the following into the kernel's command line should do th trick: init=/your_script root=/dev/ram (With your_script being the original version, without real-root-dev) > Thereby instead of loading running /sbin/init, we just set > /proc/sys/kernel/real-root-dev to /dev/ram0's value which then does the Anything involving real-root-dev is likely to be an anachronism. Combining it with pivot_root just makes it more weird. > Is this ok or should be modify /sbin/init to run properly inspite of PID > <> 1 or is there a 3rd way of doing this? I'd consider the "PID of init must be 1" a bit of an anachronism too. After all, a modern Unix system has quite a few demons that you don't want to kill either, so why make init special ? But anyway, you don't need to change init. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /linuxrc query
Amit D Chaudhary wrote: > So, it is not a requirement currently but it is useful to have the script not > dependent on the current pivot_root implementation. Yes. Also note that the relative path for dev/console works in either case, while /dev/console would fail without the implied chroot in pivot_root. > But other information in the > initrd.txt mentions otherwise, hence the query here. Hmm, sounds like a bug. Where did you find this ? > I am assuming umount and thereby blockdev after pivot_script and before > "chroot . init ..." don't make sense as files(dev/console among others) > are\might still be in use. Exactly. They's in use in any case until you close and re-open the console. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /linuxrc query
Amit D Chaudhary wrote: > To summarize, pivot_root has been a life saver as the earlier real_root_dev > might not have been useful in this case. The whole old change_root mechanism with real_root_dev is best forgotten quickly ;-) It's also completely helpless as soon as you fire off some kernel threads that don't call exit_fs. > Not using the ramfs limits for now, will do soon. BTW, if you can't free the RAM disk, you may have to apply http://icawww1.epfl.ch/~almesber/patches/rdfree - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /linuxrc query
Amit D Chaudhary wrote: > what does redirecting stdin\stdout\stderr to dev/console achieve? I thought > since the root is now the "new" root, dev/console will be used automatically? No, you would continue using the file descriptors which are already open, i.e. on /dev/console on the old root. > Also, why chroot, why not call init directly? To make sure the root of the current process is indeed changed. pivot_root currently forces a chroot on all processes (except the ones that have explicitly moved out of /) in order to move all the kernel threads too, but this is not a nice solution. Once a better solution is implemented for the kernel threads, we might drop the forced chroot, and then the explicit chroot here becomes important. > Since the above never returns, what follows in not freed. You can run them later, e.g. /etc/rc.d/rc.local Or, if you needs the space immediately, make "what-follows" a script than first frees them, and then exec's init. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux should better cope with power failure
Richard B. Johnson wrote: > Unix and other such variants have what's called a Virtual File System > (VFS). Correct, but hardly relevant here, except possibly that this enables you to use a different, perhaps more resilient file system. > The idea behind this is to keep as much recently-used file stuff > in memory so that the system can be as fast as if you used a RAM disk > instead of real physical (slow) hard disks. Correct, but does not require VFS. Nice try, though. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft begining to open source Windows 2000?
Venkatesh Ramamurthy wrote: > send a patch and they would put it in thier next version. Is this not the > same way Linux Kernel is developed?. Only thing microsoft does not want to > immediately go full open sourcing and get embarrased at the hands of linux > people. Is this linux-kernel or "The Onion" ? I can already see it: " suspends execution of dissidents for one week. Amnesty International hails this as a significant move, showing their determination to move swiftly to full compliance with human rights." - Werner (couldn't resist ;-) -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][CFT] per-process namespaces for Linux
Alexander Viro wrote: > No. Just an overmount. Ah, too bad. Union mounts would have been really elegant (allowing the operation to be repeated without residues, and also allowing umounting of the covered FS as a sanity check). But I guess there's no way to implement them without performance penalty ... > Is it worth emptying? Probably not ... the only interesting case would be if you could completely umount it. > BTW, Werner - could you take a look at the > prepare_namespace()/handle_initrd()? Okay, I'll have a look. > That's our late boot process taken into one place. I'm really not happy > about the following: Agreed on all three counts. Also, change_root might just die by evolution, just like most of NFS-root-from-initrd (using change_root) died. What we need is a migration plan. Right now, it seems that most people still use change_root. Hopefully they read the little message I left them in linux/Documentation/initrd.txt: Current kernels still support it, but you should _not_ rely on its continued availability. So with some luck, distributors will switch to pivot_root sometime soon, when deploying 2.4. So if we drop all the old junk in 2.5, the amount of letter bombs should be small ;-) > Again, current patch reproduces the behaviour of the main tree. Since you've already done all the work ... ;-) It's good if we can make one change at a time. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][CFT] per-process namespaces for Linux
Alexander Viro wrote: > No kludges actually needed. "Simplified boot sequence" _is_ simplified - > we overmount the "final" root over ramfs. Initially empty. So you have > the normal environment when you load ramdisk, etc. So is this the Holy Grail, err, union mount we've discussed about one year ago ? I.e. stat foo# output A mount /dev/whatever / stat foo# output B with A != B ? If yes, is there also a way to destroy/empty ramfs after this ? - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New net features for added performance
Chris Wedgwood wrote: > That said, it would be an extemely neat thing to do from a technical > perspective, but I don't know if you would ever get really good > performance from it. Well, you'd have to re-design the networking code to support NUMA architectures, with a fairly fine granularity. I'm not sure you'd gain anything except possibly for the forwarding fast path. A cheaper, and probably more useful possibility is hardware assistance for specific operations. E.g. hardware-accelerated packet classification looks interesting. I'd also like to see hardware-assistance for shaping on other media than ATM. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New net features for added performance
Jeff Garzik wrote: > 1) Rx Skb recycling. Sounds like a potentially useful idea. To solve the most immediate memory pressure problems, maybe VM could provide some function that does a kfree in cases of memory shortage, and that does nothing otherwise, so the driver could offer to free the skb after netif_rx. You still need to go over the list in idle periods, though. > 2) Tx packet grouping. Hmm, I think we need an estimate of how long a packet train you'd usually get. A flag looks reasonably inexpensive. Estimated numbers sound like over-engineering. > Disadvantages? Can this sort of knowledge be obtained by a netdevice > right now, without any kernel modifications? Question is what the hardware really needs. If you can change the interrupt point easily, it's probably cheapest to do all the work in hard_start_xmit. > 3) Slabbier packet allocation. Hmm, this may actually be worse during bursts: if you burst exceeds the preallocated size, you have to perform more expensive/slower operations (e.g. running a tasklet) to refill your cache. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.2
Alan Cox wrote: > I think the key word is actually probably 'predictability'. The Linus tree > is conservative. (IMHO too conservative and probably in his not conservative > enough 8)) Hmm, given that there are several patches in your tree that never seem to make it to Linus' tree, would it make sense to flag patches that should go into 2.4 as "Not for Alan; Linus _please_ pick it up" (and to keep on pushing until Linus does) ? - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
Henning P . Schmiedehausen wrote: > No, I don't. I don't at all. But I prefer a more pragmatic approach to > the developers and companies who don't. I actually think it's good if we appear to be a little more "hard-liners" than we really are. If companies assume that only open source will get them anywhere, they'll err on the safe side. In the end, this is likely to be to their own benefit: they won't waste time designing not-quite open models that fail in the end (and may generate a lot of bad blood), and can focus directly on options that make everybody happy. > And yes, there _is_ IMHO a difference in telling someone on LKM, > especially someone without deeper knowledge that is lookin for help: Yes, also rejection can be delivered in a civilized way. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
Jeff Garzik wrote: > FWIW, -every single- Windows driver source code I've seen has been > bloody awful. Asking them to release that code would probably result in > embarrassment. Maybe a good analogy is that drivers are to hardware companies like excrements are to living creatures: in order to stay alive, they have to produce them, but you don't put much love into their production, and their internals (like their development) may be a little disgusting. > Same reasoning why many companies won't release hardware > specifications... The internal docs are bad. Really bad. A fair number of hardware documents I have came with "here's all the material you'll need, but please don't show this to anyone" (but no NDA), which is fine with me: it doesn't complicate development in any way, and in those few cases where I really needed to share a document, they were flexible enough to allow this. Of course, it's better if documentation is entirely in the public too, but considering the typical overhead of clearing a document for public release, I can understand why companies frequently don't do it. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LONG RANT] Re: Linux stifles innovation...
Henning P. Schmiedehausen wrote: > Company wants to make at least some bucks with their > products and the driver is part of the product. So they may want to > release a driver which is "closed source". Usually, the driver doesn't play a large role in product differentiation, at least not in a positive way. Also, we must balance the value closed-sourcing the driver may have for a company, against the damage this does to Linux development. Now what's at stake ? Look at the Windows world. Also there, companies could release their drivers as Open Source. Quick, how many do this ? Almost none. So, given the choice, most companies have defaulted to closed source. Consistently complaining when a company tries to release only closed source drivers for Linux seems to generally have the desired effect of making them change their policy. So if we'd follow your line of reasoning, we'd end up with almost all drivers being closed-source. Since drivers are an essential part of any Linux kernel, this would essentially mean that all of the Linux kernel would be subjected to the constraints of closed-source development. Fine. So you've reinvented AIX, HP-UX, SCO, etc. The question is what you expect from Linux. After all, you strongly disagree with the main common denominator of Linux developers, that it be Open Source. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
Matt D. Robinson wrote: > Actually I do. Perhaps I should define enterprise as "big iron". In > that way, enterprise kernels would be far more innovative than a > secure kernel (which cares less about performance gains and large > features and more about just being "secure"). Hmm, and if you want a secure "big iron" ? Do you then start another branch merging from both lines, or try to merge all the "enterprise" enhancements into the "secure" system or vice versa ? If the latter is easy, why was the split needed in the first place ? If it isn't easy, will you succeed ? After all, you're facing the integration of a large portion of code, and you only have a probably small "special interest" group of people for it. > In fact, I think > if some of these vendors created their own kernel trees, it would > inevitably lead to inclusion of the best features into the primary > kernel tree. Where's the harm in that? Temporary splits or "private" add-ons are not a problem. In fact, this happens all the time. If there are more fundamental and permanent splits, I would expect it to become increasingly difficult to maintain compatibility for components. This should affect drivers first, then deeper regions of the kernel (e.g. networking, then MM). Actually, there is a live experiment of this nature going on: with BSD, you have several specialized lines. I'm not following their development, but maybe somebody who does could comment on how they compare in terms of compatibility among themselves, and in terms of features/drivers with Linux. Also, code that is supposed to run on multiple platforms easily degenerates into a wild collection of #ifdefs, or requires the addition of further abstraction layers. (*) Again, the quality of BSD drivers (both in readability and efficiency) should be indicative for whether my assumption is true. (* Further abstraction layers can sometimes be very efficient, e.g. the UP/SMP support in Linux. The hard part is to put them at the right place. If your kernels are sufficiently different, you may end up with translation modules at fairly deep layers, e.g. instead of, say, VFS in all kernels providing the same set of functions, you'd translate between VFS variants in your file system driver, which is probably less efficient, and much more likely to result in bugs.) In my personal experience, it's already painful enough to maintain a piece of software that should run in 2.2 and 2.3 kernels, despite rather good compatibility support. > And I don't think that convergence happens quickly or efficiently > enough, despite all the great work Linus and Alan do. One of the largest obstacles to covergence that I've seen so far is that some groups isolate their work too much. Rapid convergence is only possible if all relevant parties understand what's going on, at least at the point of what happens at interfaces. This means that large projects should be done openly, with occasional announcements on linux-kernel. Building that killer subsystem in-house until perfection is reached, and then submitting a multi-megabyte patch isn't going to make anybody happy. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
Matt D. Robinson wrote: > My feeling is we should splinter the kernel development for > different purposes (enterprise, UP, security, etc.). I'm sure > it isn't a popular view, but I feel it would allow faster progression > of kernel functionality and features in the long run. "enterprise" XOR security ? I think you understand the problem with your approach well ;-) Linux scales well from PDAs to large clusters. This is quite an achievement. Other operating systems are not able to match this. So why do you think that Linux should try to mimic their flaws ? Out of pity ? BTW, parallel development does happen all the time. The point of convergence in a single "mainstream" kernel is that you benefit from all the work that's been going on while you did the stuff you care most about. - Werner (having pity with the hungry looking trolls) -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LILO and serial speeds over 9600
Alan Cox wrote: > Explain 'controlled buffer overrun'. That's probably the ability to send new data even if there's unacked old data (e.g. because the receiver can't keep up or because we've had losses). Such a feature would be mainly useful in cases where data becomes useless if too old, e.g. VoIP. Ironically, for the console, the opposite may be true: if the kernel all of a sudden starts vomiting printks, the relevant information is more likely to be at the beginning than at the end. One advantage of TCP would be that such an implementation is more likely to get congestion control right, so it would be safer to use over the Internet. (And using UDP wouldn't make this any easier.) Also, when using TCP, it's more likely that some reasonable session management is built into the design. BTW, as far as the boot loader is concerned: any of the Linux boots Linux designs should nicely solve this, with the possible exception of environments where a legacy OS needs to be booted. Reminds me that I should find some time besides traffic control to work a bit on bootimg ... - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: [ANNOUNCE] Animated framebuffer logo for 2.4.1
Mike A. Harris wrote: > On Thu, 8 Feb 2001, Pavel Machek wrote: >> wondering when linux boot gets so long that mpeg2 player gets >> integrated into kernel. > > ;o) > > I doubt strongly that that is technically possible. In fact I'm > sure it is not. Why not ? Just preload the movie with the kernel, and you can start playing as soon as framebuffer, timers, and interrupts are available. Of course, if the word gets out that you're writing such a patch, the people from the village may come with torches ... ;-) - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Animated framebuffer logo for 2.4.1
Miles Lane wrote: > I suppose perhaps an even more useful tweak to the this > idea would be that if the user holds down a special key > during the start of boot, the whole prettyfication stuff > isn't used and the VT number 1 gets all the boot messages. Hmm, this adds a lot of steps between the first occurrence of the problem and the first useful diagnostic message. I think telephone support people would really hate to walk their customers through this ... Besides, people may not have the patience or knowledge to retry, and pursue other theories first, possibly causing more damage. Of course, readily available diagnostics can't stop them, but they may at least make it a bit more likely that people do the right thing. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Animated framebuffer logo for 2.4.1
Miles Lane wrote: > Since, as Christophe mentions, the boot messages would > still be accessible via CTRL-ALT-F2, I don't see what > the problem is with at least making this an option. Except if some initialization hangs your machine so badly that it even won't respond to Ctrl-Alt-F2. This could of course be cured by a little window where the last three or four printk lines are shown ... - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cosmetic: missing includes (net/sched)
This patch for 2.4.2-pre1 adds a few includes I forgot in sch_atm.c and sch_dsmark.c Their absence didn't cause any kernel compilation problems, but it may well in the future (or when compiling things in a different context, that's why I, ehm ... finally, noticed the problem). - Werner patch --- linux.orig/net/sched/sch_atm.c Wed Mar 22 08:38:27 2000 +++ linux/net/sched/sch_atm.c Fri Feb 9 01:56:07 2001 @@ -5,6 +5,8 @@ #include #include +#include +#include #include #include #include --- linux.orig/net/sched/sch_dsmark.c Mon Jan 22 22:30:21 2001 +++ linux/net/sched/sch_dsmark.cFri Feb 9 01:56:58 2001 @@ -6,6 +6,8 @@ #include #include #include +#include +#include #include #include /* for pkt_sched */ #include -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] redundant call to vm_enough_memory
This patch removes a redundant call to vm_enough_memory from mm/mmap.c:sys_brk. Exactly the same test is made in mm/mmap.c:do_brk, with the exception that the latter is done after calling do_munmap. Note that do_munmap in do_brk has no effect when called from sys_brk, because the check for find_vma_intersection only lets us pass if there are no memory objects in the way. The patch is for 2.4.2-pre1, with my /proc/sys/vm/max_map_count patch applied. (The latter only changes some offsets, not the context of this patch.) - Werner patch --- linux.orig/mm/mmap.cMon Jan 29 17:10:41 2001 +++ linux/mm/mmap.c Fri Feb 9 01:12:55 2001 @@ -148,10 +149,6 @@ if (find_vma_intersection(mm, oldbrk, newbrk+PAGE_SIZE)) goto out; - /* Check if we have enough memory.. */ - if (!vm_enough_memory((newbrk-oldbrk) >> PAGE_SHIFT)) - goto out; - /* Ok, looks good - let it rip. */ if (do_brk(oldbrk, newbrk-oldbrk) != oldbrk) goto out; -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.2-pre1] rootfs boot parameter
Tigran Aivazian wrote: > This patch adds "rootfs" boot parameter which selects the filesystem type > for the root filesystem. Could you please make this rootfstype= or fstype= or maybe root=[,] or such ? Calling it "rootfs" is just asking for trouble ... - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] /proc/sys/vm/max_map_count
A few days ago, a colleague asked me for help with some malloc problem.
I applied my usual solution, efence, and found the bug. Then she ran a
larger simulation, and it promptly failed with ENOMEM. After a bit of
searching, I found that MAX_MAP_COUNT was the culprit, and that in
order to raise the limit, I had to rebuild the kernel and reboot the
machine. Reboot a Linux system to change one stupid little integer !
I felt very embarrassed ...
Okay, here's a patch for 2.4.1 that should prevent further humiliations
of that type from happening. (I'm now hitting a limit at around 229309
maps (~0.87GB), but that's something else. Test program to exercise
max_map_count at ftp://icaftp.epfl.ch/pub/people/almesber/junk/mm.c)
BTW, I've noticed that mm/mmap.c:sys_brk and do_brk both check
vm_enough_memory. Do we really need this ? Removing one of them may
make sys_brk about 2% faster ;-)
- Werner
patch
--- linux.orig/include/linux/sched.hTue Jan 30 08:24:56 2001
+++ linux/include/linux/sched.h Sat Feb 3 14:29:41 2001
@@ -195,7 +195,9 @@
}
/* Maximum number of active map areas.. This is a random (large) number */
-#define MAX_MAP_COUNT (65536)
+#define DEFAULT_MAX_MAP_COUNT (65536)
+
+extern int max_map_count;
/* Number of map areas at which the AVL tree is activated. This is arbitrary. */
#define AVL_MIN_MAP_COUNT 32
--- linux.orig/include/linux/sysctl.h Tue Jan 30 08:24:55 2001
+++ linux/include/linux/sysctl.hSat Feb 3 14:29:49 2001
@@ -132,7 +132,8 @@
VM_PAGECACHE=7, /* struct: Set cache memory thresholds */
VM_PAGERDAEMON=8, /* struct: Control kswapd behaviour */
VM_PGT_CACHE=9, /* struct: Set page table cache parameters */
- VM_PAGE_CLUSTER=10 /* int: set number of pages to swap together */
+ VM_PAGE_CLUSTER=10, /* int: set number of pages to swap together */
+ VM_MAX_MAP_COUNT=11,/* int: Maximum number of active map areas */
};
--- linux.orig/kernel/sysctl.c Fri Dec 29 23:07:24 2000
+++ linux/kernel/sysctl.c Sat Feb 3 14:28:05 2001
@@ -257,6 +257,8 @@
&pgt_cache_water, 2*sizeof(int), 0644, NULL, &proc_dointvec},
{VM_PAGE_CLUSTER, "page-cluster",
&page_cluster, sizeof(int), 0644, NULL, &proc_dointvec},
+ {VM_MAX_MAP_COUNT, "max_map_count",
+&max_map_count, sizeof(int), 0644, NULL, &proc_dointvec},
{0}
};
--- linux.orig/mm/mmap.cMon Jan 29 17:10:41 2001
+++ linux/mm/mmap.c Sat Feb 3 14:28:49 2001
@@ -37,6 +37,7 @@
};
int sysctl_overcommit_memory;
+int max_map_count = DEFAULT_MAX_MAP_COUNT;
/* Check that a process has enough memory to allocate a
* new virtual mapping.
@@ -207,7 +208,7 @@
return -EINVAL;
/* Too many mappings? */
- if (mm->map_count > MAX_MAP_COUNT)
+ if (mm->map_count > max_map_count)
return -ENOMEM;
/* mlock MCL_FUTURE? */
@@ -691,7 +692,7 @@
/* If we'll make "hole", check the vm areas limit */
if ((mpnt->vm_start < addr && mpnt->vm_end > addr+len)
- && mm->map_count >= MAX_MAP_COUNT)
+ && mm->map_count >= max_map_count)
return -ENOMEM;
/*
@@ -809,7 +810,7 @@
> current->rlim[RLIMIT_AS].rlim_cur)
return -ENOMEM;
- if (mm->map_count > MAX_MAP_COUNT)
+ if (mm->map_count > max_map_count)
return -ENOMEM;
if (!vm_enough_memory(len >> PAGE_SHIFT))
--- linux.orig/mm/filemap.c Tue Jan 16 02:14:41 2001
+++ linux/mm/filemap.c Sat Feb 3 14:18:02 2001
@@ -1923,7 +1923,7 @@
int error = 0;
/* This caps the number of vma's this process can own */
- if (vma->vm_mm->map_count > MAX_MAP_COUNT)
+ if (vma->vm_mm->map_count > max_map_count)
return -ENOMEM;
if (start == vma->vm_start) {
--- linux.orig/Documentation/sysctl/vm.txt Tue Aug 8 08:01:34 2000
+++ linux/Documentation/sysctl/vm.txt Sat Feb 3 14:33:14 2001
@@ -21,6 +21,7 @@
- buffermem
- freepages
- kswapd
+- max_map_count
- overcommit_memory
- page-cluster
- pagecache
@@ -171,6 +172,19 @@
and don't use much of it.
Look at: mm/mmap.c::vm_enough_memory() for more information.
+
+==
+
+max_map_count:
+
+This file contains the maximum number of memory map areas a
+process may have. Memory map areas are used as a side-effect
+of calling malloc, directly by mmap and mprotect, and also
+when loading shared libraries.
+
+While most applications need less than a thousand maps,
+certain programs, particularly malloc debuggers, may consume
+lots of them, e.g. up to one or two m
Re: [OT?] Coding Style
Admin Mailing Lists wrote: >hand-holding of that magnitude. We don't write code for idiots. But if you have to, you can at least enjoy it: - diversity makes life interesting: use switch() with local variables or without curly braces - de-referencing is like a hotel: the more stars, the better - observe proper punctuation: use the comma operator frequently - know thy C: few people know that 5[x] is valid, but they can usually guess what it does. They probably won't get x[5[y]], though. - know thy CPP: nest macros and exercise token-concatenation and stingification - if your code allows you to, put #define while if in some header file - Werner (couldn't resist ;-) -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: "Pass module parameters" to built-in drivers
Keith Owens wrote: > Inconsistent methods for setting the same parameter are bad. I can and > will do this cleanly in 2.5. If your approach isn't overly intrusive (i.e. doesn't require changes to all files containing module parameters, or such), maybe you could make a patch for 2.4.x and wave it a little under Linus' nose. Maybe he likes the scent ;-) In any case, once it's in 2.5.x, and if it is as useful as I suspect it to be, it would probably be back-ported to 2.4 sooner or later. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
Matti Aarnio wrote: > 2.4.0 with devfs mounted at boot time into /dev/ Or /proc/partitions, which - according to the mount(8) man page - has been around since 2.1.116. So we're not exactly talking crazy upgrade paths here. > This new style (which contains, hopefully, physical PCI location) > mount device paths will failry easily handle question about which > is where... And the partitions are PHYSICAL partition numbers, Hmm, without PCI locations, you still need to know how the system determines which interface becomes host0. Also, PCI locations probably aren't the most user-friendly way for identifying things ;-) But for the occasional problem case where label or uuid don't work, any such information is, of course, valuable. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
Venkatesh Ramamurthy wrote: > [Venkatesh Ramamurthy] The LILO boot loader and the LILO command > line utility should be changed for this. There are some issues when we have Grr, I was just waiting for this ... See sections 2.6 and 3.5 of ftp://icaftp.epfl.ch/pub/people/almesber/booting/bootinglinux-0.ps.gz for my views on such things. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux not adhering to BIOS Drive boot order?
[ Ccs trimmed ] Dr. Kelsey Hudson wrote: > *single* scsi adapter in their systems? do we need to bloat the kernel > with automatic things like this? no... i think it is handled fine the way "no", because you don't have to do it in the kernel. You can mount by uuid or label. For the root FS, you do this from an initrd. Problem solved. The only cases when you really need to know the name of a disk is when - doing disk-level management, e.g. partitioning or creating file systems (*) - adding a swap partition (sigh) - telling your boot loader where to put its boot sector (* in principle, you could even avoid this, if you have some means of identifying a disk (e.g. via the uuid of a file system). However, I would consider such a solution to be overly fragile.) - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 + iproute2
Andi Kleen wrote: > Configuring a complex subsystem like CBQ which has dozens of parameters > with only a single ed'esque error message (EINVAL) when something goes > wrong is just bad. The underlying problem is of course that all those sanity checks should be done in user space, not in the kernel. (See also ftp://icaftp.epfl.ch/pub/people/almesber/slides/tmp-tc.ps.gz The bitching starts on slide 11, some ideas for fixing the problem on slide 16, but heed the warning on slide 15.) Besides that, I agree that we have far too many EINVALs in the kernel. Maybe we should just record file name and line number of the EINVAL in *current and add an eh?(2) system call ;-) - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: HP Pavilion 8290 HANGS on boot 2.4/2.4-test9
On Sat, 13 Jan 2001, Andre Hedrick wrote: > On Sat, 13 Jan 2001, Werner wrote: > > > The first and last message I get is: > > "Uncompressing Linux... OK, booting the kernel" > > > # lspci > > 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge(rev 02) > > 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge(rev 02) > > 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) > > 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) > > It is to early to be caught by a DMA engine fault, but you have one of the > award winning systems that designed flaw in the hardware. Only if the > BIOS with INT13 calls are performing DMA stuff until the OS takes over > could this be a player. > > If you disable DMA in the BIOS does that help? No, it didn't make any difference. Is there a safe way to add debug information like simple string prints in arch/i386/boot/compressed/head.s and in arch/i386/kernel/head.S so that I can see at the console where the boot process hangs? Thanks Werner > > Regards, > > Andre Hedrick > Linux ATA Development > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: HP Pavilion 8290 HANGS on boot 2.4/2.4-test9
I guess I confused some people. I didn't copy the kernel from PIII to PII etc.. I compiled the kernel on all my PCs separately. I just have problems with one PC, the HP Pavilion. On Sat, 13 Jan 2001, Werner wrote: > > HP Pavilion 8290, PII 400MHz, 256MB hangs on boot 2.4 and 2.4-test9 on RH7.0. > I tried to compile 2.4-test9 on RH 7.0 with gcc versions 2.96-54, 2.96-69, > and with kgcc 1.1.2-40 (egcs-2.91.66) without success. > > The first and last message I get is: > "Uncompressing Linux... OK, booting the kernel" > > I never get to the start_kernel() function in main.c > I had no problems to get 2.4 (testx) running on IBM 300PL (PIII 500MHz, 192MB). > After running 'make mrproper' and 'make xconfig' I changed only SMP to No. > > Can you please tell me how I can print debug information to the console in > arch/i386/boot/compressed/head.s and in arch/i386/kernel/head.S > _without_ impacting the rest of the assembly code? > > # lspci > 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge(rev 02) > 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge(rev 02) > 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) > 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) > 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) > 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) > 00:0a.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] > 00:0b.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74) > 00:0c.0 Ethernet controller: National Semiconductor Corporation: Unknown device 0020 > 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev >5c) > > Let me know what I can do. > > Thanks > Werner > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
HP Pavilion 8290 HANGS on boot 2.4/2.4-test9
HP Pavilion 8290, PII 400MHz, 256MB hangs on boot 2.4 and 2.4-test9 on RH7.0. I tried to compile 2.4-test9 on RH 7.0 with gcc versions 2.96-54, 2.96-69, and with kgcc 1.1.2-40 (egcs-2.91.66) without success. The first and last message I get is: "Uncompressing Linux... OK, booting the kernel" I never get to the start_kernel() function in main.c I had no problems to get 2.4 (testx) running on IBM 300PL (PIII 500MHz, 192MB). After running 'make mrproper' and 'make xconfig' I changed only SMP to No. Can you please tell me how I can print debug information to the console in arch/i386/boot/compressed/head.s and in arch/i386/kernel/head.S _without_ impacting the rest of the assembly code? # lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge(rev 02) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge(rev 02) 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:0a.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] 00:0b.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74) 00:0c.0 Ethernet controller: National Semiconductor Corporation: Unknown device 0020 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 5c) Let me know what I can do. Thanks Werner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Referencing PHYSICAL (what you see on the bus) memory?
Richard B. Johnson wrote: > I am finishing up a memory-test program. I want to get the > true linear address of some failing memory. I have obtained > the virtual (user-space) address. > > Since going through all the PTEs seems to be a bitch, I thought > it would be easier to do the following: Hmm, for some unusual definition of "easy", perhaps ... For an ugly hack that works remarkably well, look at ptable.c in Andrew Tridgell's capture program: http://samba.org/picturebook/ Note: you probably also want to check if you find multiple addresses for the page, i.e. if the hack didn't quite work. (Due to odd side-effects, incomplete address decoding, etc.) - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TIOCGDEV ioctl
On Fri, Dec 15, 2000 at 05:11:07PM -0800, Linus Torvalds wrote:
>
>
> On Sat, 16 Dec 2000, Kurt Garloff wrote:
> >
> > The kernel provides this information -- sort of:
> > It contains the TIOCTTYGSTRUCT syscall which returns a struct. Of course,
> > it changes between different kernel archs and revisions, so using it is
> > an ugly hack. Grab for TIOCTTYGSTRUCT_HACK in the bootlogd.c file of the
> > sysvinit sources. Shudder!
>
> Please instead do the same thing /dev/tty does, namely a sane interface
> that shows it as a symlink in /proc (or even in /dev)
Not a symlink but this is what is needed: if fd 0 of the current task is a
tty then give the hash of the tty. I'm using fd 0 because current->tty may
not be set for spawned tasks of init.
I've attached two patches, one for 2.4 and one for 2.2. They're rather
simple, therefore one may use this for setting a link.
Werner
BTW: I'm missing a real replacement for my sys_revoke() patch done at the
end of October. Al Viro has wipe it out but never shows an alternative way
of implementing such a beast.
--- fs/proc/proc_tty.c
+++ fs/proc/proc_tty.c Thu Dec 21 15:16:08 2000
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -22,6 +23,8 @@
int count, int *eof, void *data);
static int tty_ldiscs_read_proc(char *page, char **start, off_t off,
int count, int *eof, void *data);
+static int real_tty_read_proc(char *page, char **start, off_t off,
+ int count, int *eof, void *data);
/*
* The /proc/tty directory inodes...
@@ -128,7 +131,32 @@
}
/*
- * Thsi function is called by register_tty_driver() to handle
+ * This is the handler for /proc/tty/tty
+ */
+static int real_tty_read_proc(char *page, char **start, off_t off,
+ int count, int *eof, void *data)
+{
+ struct file * zero = fcheck(0); /* of current task */
+ struct tty_struct * tty = NULL;
+ unsigned int dev = 0;
+ int len = 0;
+ off_t begin = 0;
+
+ if (zero)
+ tty = (struct tty_struct *)zero->private_data;
+ if (tty && tty->magic == TTY_MAGIC)
+ dev = kdev_t_to_nr(tty->device);
+
+ len += sprintf(page+len, "%u\n", dev);
+
+ if (off >= len+begin)
+ return 0;
+ *start = page + (off-begin);
+ return ((count < begin+len-off) ? count : begin+len-off);
+}
+
+/*
+ * This function is called by register_tty_driver() to handle
* registering the driver's /proc handler into /proc/tty/driver/
*/
void proc_tty_register_driver(struct tty_driver *driver)
@@ -178,4 +206,5 @@
create_proc_read_entry("tty/ldiscs", 0, 0, tty_ldiscs_read_proc,NULL);
create_proc_read_entry("tty/drivers", 0, 0, tty_drivers_read_proc,NULL);
+ create_proc_read_entry("tty/tty", 0, 0, real_tty_read_proc,NULL);
}
--- fs/proc/proc_tty.c
+++ fs/proc/proc_tty.c Thu Dec 21 15:14:12 2000
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -22,6 +23,8 @@
int count, int *eof, void *data);
static int tty_ldiscs_read_proc(char *page, char **start, off_t off,
int count, int *eof, void *data);
+static int real_tty_read_proc(char *page, char **start, off_t off,
+int count, int *eof, void *data);
/*
* The /proc/tty directory inodes...
@@ -128,7 +131,32 @@
}
/*
- * Thsi function is called by register_tty_driver() to handle
+ * This is the handler for /proc/tty/tty
+ */
+static int real_tty_read_proc(char *page, char **start, off_t off,
+int count, int *eof, void *data)
+{
+ struct file * zero = fcheck_task(current, 0);
+ struct tty_struct * tty = NULL;
+ unsigned int dev = 0;
+ int len = 0;
+ off_t begin = 0;
+
+ if (zero)
+ tty = (struct tty_struct *)zero->private_data;
+ if (tty && tty->magic == TTY_MAGIC)
+ dev = kdev_t_to_nr(tty->device);
+
+ len += sprintf(page+len, "%u\n", dev);
+
+ if (off >= len+begin)
+ return 0;
+ *start = page + (off-begin);
+ return ((count < begin+len-off) ? count : begin+len-off);
+}
+
+/*
+ * This function is called by register_tty_driver() to handle
* registering the driver's /proc handler into /proc/tty/driver/
*/
void proc_tty_register_driver(struct tty_driver *driver)
@@ -185,5 +213,7 @@
ent = create_proc_entry("tty/drivers", 0, 0);
ent->read_proc = tty_drivers_read_proc;
-}
+ ent = create_proc_entry("tty/tty", 0, 0);
+ ent->read_proc = real_tty_read_proc;
+}
Re: Linus's include file strategy redux
Joe deBlaquiere wrote: > but actually the best thing about it is > that the compiler people of the work might make generating a proper > cross-toolchain less difficult by one or two magnitudes... You have a point here ... particularly gcc-glibc interdependencies are a little irritating (not sure if they still cause build failures - they were great fun in egcs-1.1b) > This way I can upgrade my host system from RH6.2 to RH7 and not worry > about compiler differences affecting my kernel builds for the various > projects I'm working on... including systems based on 2.0, 2.2 and 2.4... Ah, you mean you _do_ use a different compiler, but you _don't_ have to change the compiler you normally invoke with "gcc" ? I see. > If anybody thinks gcc-2.96 messes up a 2.4 kernel, you should see what > happens when you compile 2.0.33 ;o). I think a -Wall-as-of=2.7.2 might be convenient at times ;-) - Werner (drifting off-topic :-( ) -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
J . A . Magallon wrote: > Easier: public kernel interfaces only work through pointers. Requires more elaborate wrappers or a new layer of wrapper functions around system calls, if you want to make this completely general. Also, doesn't provide FOOSIZE to "public" space. > Too kind-of-classroom-not-real-world-useless-thing ? I'm afraid so ... I don't think there are many opaque types where there's no trival solution. Actually, I don't think there are many opaque types at kernel APIs to start with. The one I know offhand is atm_kptr_t in include/linux/atmapi.h, in this case, there's little risk in exposing the internal structure. So I'd consider opaque types more as a hypothetical obstacle. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
Matt D. Robinson wrote: > I personally think the definition of an environment variable to point to > a header file location is the right way to go. I see two disadvantages of this, compared to a script: - need to hard-code a default (unless we assume the variables are always set) - the way how environment variables are propagated A script-based approach has the advantage that one can make a single change (to a file) that instantly affects the whole local environment (be this system-wide, per-user, or whatever). So there's no risk of typing "make" to that forgotten xterm and an incompatible build starts. I like environment variables as a means to override auto-detected defaults, though. Also, environment variables don't solve the problem of conveniently providing other compiler arguments (the kmodcc idea - the problem is very old, but I think it's still not solved). - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
LA Walsh wrote: > I think in my specific case, perhaps, linux/malloc.h *is* a public > interface that is to be included by module writers and belongs in the > 'public interface dir -- and that's great. But it includes files like > 'slab.h' which are kernel mm-specific that may change in the future. As far as I understand the scenario you're describing, this seems to be the only problem. /malloc.h shouldn't need to include /slab.h. If there's anything /slab.h provides (either directly or indirectly) that is needed in /malloc.h, that should either be in another public header, or malloc.h actually shouldn't depend on it. Exception: opaque types; there one would have to go via a __ identifier, i.e. /foo.h defines struct __foo ...; /bar.h includes /foo.h and uses #define FOOSIZE sizeof(struct __foo) /foo.h either typedef struct __foo foo_t; or #define foo __foo /* ugly */ Too bad there's no typedef struct __foo struct foo; I don't think restructuring the headers in this way would cause a long period of instability. The main problem seems to be to decide what is officially private and what isn't. > Any other solution, as I see it, would break existing module code. Hmm, I think what I've outlined above wouldn't break more code than your approach. Obviously, modiles currently using "private" interfaces are in trouble either way. - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
Joe deBlaquiere wrote: > My solution to this has always been to make a cross compiler environment ;-))) I think lots of people would really enjoy to have "build a cross-gcc" added to the prerequisites for installing some driver module ;-) I know, it's not *that* bad. But it still adds quite a few possible points of failure. Also, it adds a fair amount of overhead to any directory name change or creation of a new kernel tree. > The other advantage to this is that I can switch my host environment > (within reason - compatible host glibcs, ok) and not have to change the > target compiler. Hmm, I don't quite understand what you mean here. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
[EMAIL PROTECTED] wrote: > Just out of curiosity, what would happen with redirection if your source > tree for 'the currently running kernel' version happens to be configured > for a different 'the currently running kernel', perhaps a machine of a > foreign arch that you are cross-compiling for? Two choices: 1) try to find an alternative. If there's none, fail. 2) make the corresponding asm or asm/arch branch available (non-trivial and maybe not desirable) > I do this: I use ONE machine to compile kernels for five: four i386 and > one SUN4C. My other machines don't even HAVE /usr/src/linux, so where does > this redirection leave them? Depends on your distribution: if it doesn't install any kernel-specific headers, you wouldn't be able to compile programs requiring anything beyond what it provided by your libc. Otherwise, there could be a default location (such as /usr/src/linux is a default location now). The main advantage of a script would be that one could easily compile for multiple kernels, e.g. with export TARGET_KERNEL=2.0.4 make Even if your system is running 2.4.13-test1. The architecture could be obtained from the tree or the tree could be picked based on the architecture. This is a policy decision that could be hidden in the script. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
Alexander Viro wrote: > In the situation above they should have -I/include > in CFLAGS. Always had to. No links, no pain in ass, no interference with > userland compiles. As long as there's a standard location for "", this is fine. In most cases, the tree one expects to find is "roughly the kernel we're running". Actually, maybe a script to provide the path would be even better (*). Such a script could also complain if there's an obvious problem. I think there are three possible directions wrt visibility of kernel headers: - non at all - anything that needs kernel headers needs to provide them itself - kernel-specific extentions only; libc is self-contained, but user space can get items from .../include/linux (the current glibc approach) - share as much as possible; libc relies on kernel for "standard" definitions (the libc5 approach, and also reasonably feasible today) My personal preference is the third direction, because it simplifies the deployment of new "standard" elements, and changes to existing interfaces. The first direction would effectively discourage any new interfaces or changes to existing ones, while the second direction allows at least a moderate amount of flexibility for kernel-specific interfaces. In my experiments with newlib, I was largely able to use the third approach. I don't want to re-open the discussion on which way is better for glibc, but I think we can agree that "clean" kernel headers are always a good idea. So we get at least the following levels of visibility: 0) kernel-internal interfaces; should only be visible to "base" kernel 1) public kernel interfaces; should be visible to modules (exposing type 0 interfaces to modules may create ways to undermine the GPL) 2) interfaces to kernel-specific user space tools (modutils, mount, etc.); should be visible to user space that really wants them 3) interface to common non-POSIX extensions (BSD system calls, etc.); should be visible to user space on request, or on an opt-out basis 4) interfaces to POSIX elements (e.g. struct stat, mode_t); should be visible unconditionally (**) Distinguishing level 0 and 1 is always a little difficult. It seems that a "kmodcc" that inserts the necessary flags would be useful there (*). There needs to be a clear distinction between level 1 and 2 (the current #ifdef __KERNEL__). This boundary could certainly be improved be moving user-space-visible header files to a separate directory. Levels 2, 3, and 4 are more difficult to separate, because the people who know what should go where are not always the ones writing the kernel headers. Perhaps some more input from libc hackers could help. (*) Crude examples for such scripts (for newlib): newlib-flags and newlib-cc in ftp://icaftp.epfl.ch/pub/people/almesber/misc/newlib-linux/ newlib-linux-20.tar.gz (**) Multiple versions of the interface can be a problem here, e.g. struct oldold_utsname vs. struct old_utsname vs. struct new_utsname. It would be nice to have them prefixed at least with __. Maybe a __LATEST_utsname macro would be useful too ;-) (I know, breaks binary compatibility, hence the smiley.) So ... what's the opinion on slowly introducing a redirection via scripts ? - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel boot params
Timothy A. DeWees wrote:
> Could someone be so kind to point me to a page where I can find
> a list of parameters I can pass to a kernel on boot.
The following script lists almost all parameters your 2.4 kernel accepts.
The exceptions are parameters obtained via non-standard means, i.e.
- init= in init/main.c
- mem=, nopentium, etc. in arch/*/kernel/setup.c (i386 examples)
- anything your boot loader catches and hides (e.g. vga=, initrd=)
Only tested on i386. Probably works on other 32 bit platforms, but
not on true 64 bit platforms. Should do more error checking.
Usage:
./lss.pl /wherever/vmlinux
- Werner
--- lss.pl
#!/usr/bin/perl
open(KERNEL,$ARGV[0]) || die "open $ARGV[0]: $!";
for (split("\n",`objdump -h $ARGV[0]`)) {
next unless /^\s*\d+\s+(\S+)\s+(\S+)\s+(\S+)\s+\S+\s+(\S+)/;
($size{$1}, $addr{$1}, $offset{$1}) = (hex $2, hex $3, hex $4);
}
die "kernel too old for __setup" unless defined $size{".setup.init"};
for ($i = 0; $i < $size{".setup.init"}; $i += 8) {
sysseek(KERNEL,$offset{".setup.init"}+$i,0);
sysread(KERNEL,$pos,4);
$pos = unpack("L",$pos);
sysseek(KERNEL,$pos-$addr{".data.init"}+$offset{".data.init"},0);
sysread(KERNEL,$str,256);
$str =~ s/\000.*/\n/s;
print $str;
}
--
_
/ Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH,RFC] initrd vs. BLKFLSBUF
Jeff Chua wrote: > I'm posting this again hoping that it'll get incorporated into the kernel. It's already in Alan's tree (e.g. patch-2.4.0test11-ac1.bz2) and should find its way from there into Linus' tree soon (i.e. probably by test12). - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
David S. Miller wrote: > There is no guarentee that contiguous data or bss section members > will appear contiguous and in the same order, in the final object. That's a different issue and actually okay in this case. What I meant to show is an example where the compiler happens to allocate the variables in sequence, and where it could access them either by referencing each by absolute address, with relocation (so that objdump-patcher could change that), or by generating a pointer and using pointer-relative addressing or pointer increment (so we only get one relocation and never know what may go wrong with the other variables). - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
Adam J. Richter wrote: > At the moment, I have started daydreaming about instead > writing an "elf squeezer" to do this and other space optimizations > by modifying objdump. Hmm, this would require that gcc never calculates the location of an explicitly initialized static variable based on the address of another one. E.g. in static int a = 0, b = 0, c = 0, d = 0; ... ... a+b+c+d ... ... egcs-2.91.66 indeed doesn't seem to make this optimization on i386. (Maybe the pointer increment or pointer offset solution would actually be slower - didn't check.) But I'm not sure if this is also true for other versions/architectures, or other code constructs. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
Andries Brouwer wrote: > On Sat, Nov 25, 2000 at 10:27:15PM +, Tigran Aivazian wrote: I think it's a bad sign if people like the two of you start flaming each other ... On the issue of static int foo = 0; vs. static int foo; I'd agree with Andries' view. It's a common enough idiom that it is useful to convey the intentions of the programmer. On "optimizing" changes: there are plenty of very ugly things you can do to a C program to make source or object code smaller (e.g. use only one-character identifiers for smaller code; re-use variables as much as possible, maybe with casts for smaller stack footprint, etc.). We usually avoid these too, so a few extra initializations in the source shouldn't hurt. On the .data segment size: if all the energy that went into this thread would have gone into implementing a gcc option to move all-zero .data objects to .bss, the technical side of the problem would be solved already ;-) > Does the kernel contain a bug? Panic! I don't think my alpha would > have gotten an uptime of 1198 days under that paradigm. > (I don't think you were serious, but still..) Hmm, sometimes a panic _is_ the right answer, though. If a critical subsystem just politely returns an error to user space and tries to continue, it may take a while until somebody realizes that there's something wrong at all ... - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: beware of dead string constants
Michael Elizabeth Chastain wrote: > I have a compiler from gcc.gnu.org's CVS tree that's only a few days old, > so I can verify Jakub's claim. BTW, do you have any estimate of how much dead string space it actually removed ? (I.e. did the .data segment size change significantly, or was is lost in the normal inter-gcc-version noise ?) Just curious, - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW DRIVER] firestream
Mitchell Blank Jr wrote: > * I don't like header files that define the registers of the chip - since > the header file is only included in the driver's .c For a non-hypothetical case why it makes sense to have such things in their own header file: if you dig out some older versions of the ATM distribution, you'll find the programs called endump.c and zndump.c in atm/debug. They run in user space and dump the card status, decoding the "interesting" bits. And, of course, they include the register headers. Since they're strictly for development, it's okay that they include things from deep down in /usr/src/linux (i.e. no need to move the headers to linux/include/*), but it's important that they can share the same definitions (to avoid version conflicts, etc.). Besides, using a specific header file for the registers lowers the risk that definitions get scattered all over the driver, so it makes it easier to look for copy-from-manual bugs. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: USB: Wacom Graphire mouse wheel does not work anymore
[EMAIL PROTECTED] wrote: >> I used the IMPS/2 compatible mouse emulation of the wacom driver >> (/dev/input/mice). > > Don't do that. It's evil. Use the xinput driver instead. Uh, it's not *that* bad ... (what's good: better noise filtering than the Xinput driver I'm using (xf86Graphireusb.so, June 15, under XF86 3.3.6); what's bad: only provides mouse). But anyway, the mouse wheel is also unavailable with the Xinput driver. - Werner -- _____ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Defective Red Hat Distribution poorly represents Linux
Charles Turner, Ph.D. wrote:
> I can even see obvious bugs in the trace, i.e., :
> stat("/usrusr/lib/ldscripts", 0xba7c) = -1 ENOENT (No such file or directory)
Probably only a cosmetic problem. A regular run (RedHat binutils-2.9.5.0.22-6)
yields:
stat("/usrusr/lib/ldscripts", 0xb5c4) = -1 ENOENT (No such file or directory
)
stat("/usr/bin/ldscripts", 0xb5c4) = -1 ENOENT (No such file or directory)
stat("/usr/bin/../lib/ldscripts", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
So it's not perfect, but it works.
- Werner
--
_____
/ Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
