Re: 2.6.22-rc2-mm1
On Tue, Jul 03, 2007 at 10:50:40AM +0200, Cornelia Huck wrote: > On Fri, 1 Jun 2007 05:38:48 -0700, > Greg KH <[EMAIL PROTECTED]> wrote: > > [Sorry for taking so long to respond, I've been offline for a month] > > > Can you resend me the new patch, I seem to have lost it in this thread > > :( > > Andrew has the fixup patch in his -mm lineup as > driver-core-check-return-code-of-sysfs_create_link-fix.patch. Do you > need anything else? No, that should be fine, I'll pull it from him there. thanks, greg k-h - 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.22-rc2-mm1
On Tue, Jul 03, 2007 at 10:50:40AM +0200, Cornelia Huck wrote: On Fri, 1 Jun 2007 05:38:48 -0700, Greg KH [EMAIL PROTECTED] wrote: [Sorry for taking so long to respond, I've been offline for a month] Can you resend me the new patch, I seem to have lost it in this thread :( Andrew has the fixup patch in his -mm lineup as driver-core-check-return-code-of-sysfs_create_link-fix.patch. Do you need anything else? No, that should be fine, I'll pull it from him there. thanks, greg k-h - 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.22-rc2-mm1
On Fri, 1 Jun 2007 05:38:48 -0700, Greg KH <[EMAIL PROTECTED]> wrote: [Sorry for taking so long to respond, I've been offline for a month] > Can you resend me the new patch, I seem to have lost it in this thread > :( Andrew has the fixup patch in his -mm lineup as driver-core-check-return-code-of-sysfs_create_link-fix.patch. Do you need anything else? Cornelia - 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.22-rc2-mm1
On Fri, 1 Jun 2007 05:38:48 -0700, Greg KH [EMAIL PROTECTED] wrote: [Sorry for taking so long to respond, I've been offline for a month] Can you resend me the new patch, I seem to have lost it in this thread :( Andrew has the fixup patch in his -mm lineup as driver-core-check-return-code-of-sysfs_create_link-fix.patch. Do you need anything else? Cornelia - 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.22-rc2-mm1
On Tue, May 29, 2007 at 07:25:11PM +0200, Cornelia Huck wrote: > On Tue, 29 May 2007 18:55:21 +0200, > Tilman Schmidt <[EMAIL PROTECTED]> wrote: > > > Am 29.05.2007 09:25 schrieb Cornelia Huck: > > > Could those folks that had trouble with this kernel check out whether > > > the following patch helps? > > > > Yes, that patch fixes my problem. > > > > Thanks, > > Tilman > > Thanks for testing (to both of you) and again sorry for the breakage. Can you resend me the new patch, I seem to have lost it in this thread :( thanks, greg k-h - 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.22-rc2-mm1
On Tue, May 29, 2007 at 07:25:11PM +0200, Cornelia Huck wrote: On Tue, 29 May 2007 18:55:21 +0200, Tilman Schmidt [EMAIL PROTECTED] wrote: Am 29.05.2007 09:25 schrieb Cornelia Huck: Could those folks that had trouble with this kernel check out whether the following patch helps? Yes, that patch fixes my problem. Thanks, Tilman Thanks for testing (to both of you) and again sorry for the breakage. Can you resend me the new patch, I seem to have lost it in this thread :( thanks, greg k-h - 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] Input: i8042 - cleanup of debug code (was Re: 2.6.22-rc2-mm1)
On Wed, 30 May 2007, Dmitry Torokhov wrote: > I'd rather leave it as is in case someone wants to squeeze last bit of > memory savings from the kernel. Yup, that's why I left CONFIG_HID_DEBUG still in place to let users that care that much to turn in off. > Also there some security issues (someone breaking into the box and > enabling i8042 debug and capturing all keycodes) so uber-sensitive folks > can use it to disable debug completely. Well this doesn't seem to an issue at all to me - if someone breaks into the box, he has dozens of other possibilities how to capture the keystrokes than enabling i8042 debug. Thanks, -- Jiri Kosina - 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] Input: i8042 - cleanup of debug code (was Re: 2.6.22-rc2-mm1)
Hi Jiri, On 5/30/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: From: Jiri Kosina <[EMAIL PROTECTED]> Input: i8042 - cleanup of debug code Debugging facility of i8042 is now toggled in runtime instead of needing to recompile the kernel. Therefore the DEBUG macro is useless (it's hardcoded to be defined anyway). Remove it. I'd rather leave it as is in case someone wants to squeeze last bit of memory savings from the kernel. Also there some security issues (someone breaking into the box and enabling i8042 debug and capturing all keycodes) so uber-sensitive folks can use it to disable debug completely. -- Dmitry - 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] Input: i8042 - cleanup of debug code (was Re: 2.6.22-rc2-mm1)
(some irrelevant CCs dropped)
On Wed, 23 May 2007, Dmitry Torokhov wrote:
> It looks like you are now in the same position I was some time ago WRT
> to debug information for i8042 - constantly asking people to enable
> debug, recompile and send the results. May I recommend changing
> CONFIG_HID_DEBUG to "default y if !EMBEDDED" and controlling debug
> output via a module parameter? -ENOPATCH though...
Hi Dmitry,
I have just queued corresponding patch in HID tree.
BTW when looking at the i8042 code I have just noticed that the trivial
cleanup below could be possible.
From: Jiri Kosina <[EMAIL PROTECTED]>
Input: i8042 - cleanup of debug code
Debugging facility of i8042 is now toggled in runtime instead
of needing to recompile the kernel. Therefore the DEBUG macro
is useless (it's hardcoded to be defined anyway). Remove it.
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 3888dc3..5c3405d 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -69,12 +69,9 @@ module_param_named(nopnp, i8042_nopnp, b
MODULE_PARM_DESC(nopnp, "Do not use PNP to detect controller settings");
#endif
-#define DEBUG
-#ifdef DEBUG
static int i8042_debug;
module_param_named(debug, i8042_debug, bool, 0600);
MODULE_PARM_DESC(debug, "Turn i8042 debugging mode on and off");
-#endif
#include "i8042.h"
diff --git a/drivers/input/serio/i8042.h b/drivers/input/serio/i8042.h
index b3eb7a7..eec4b32 100644
--- a/drivers/input/serio/i8042.h
+++ b/drivers/input/serio/i8042.h
@@ -106,7 +106,6 @@
* Debug.
*/
-#ifdef DEBUG
static unsigned long i8042_start_time;
#define dbg_init() do { i8042_start_time = jiffies; } while (0)
#define dbg(format, arg...)
\
@@ -115,9 +114,4 @@ static unsigned long i8042_start_time;
printk(KERN_DEBUG __FILE__ ": " format " [%d]\n" ,
\
## arg, (int) (jiffies - i8042_start_time));
\
} while (0)
-#else
-#define dbg_init() do { } while (0)
-#define dbg(format, arg...) do {} while (0)
-#endif
-
#endif /* _I8042_H */
-
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.22-rc2-mm1: SLUB-related panic
On Tue, 29 May 2007, Christoph Lameter wrote: > > when trying to reproduce a bugreport in bugzilla, I am experiencing > > panics upon boot. The .config which causes this is at [1] > Please reboot with "slub_debug" to identify what causes this. Hi Christoph, with slub_debug, there is no panic (which just supports that there is a race somewhere). The boot with slub_debug below up to the point where it panics without slub_debug Linux version 2.6.22-rc2-mm1 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070302 (prerelease) (SUSE Linux)) #85 SMP PREEMPT Wed May 30 01:44:05 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 3f68 (usable) BIOS-e820: 3f68 - 3f692000 (ACPI data) BIOS-e820: 3f692000 - 3f70 (ACPI NVS) BIOS-e820: 3f70 - 4000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fed0 - fed00400 (reserved) BIOS-e820: fed14000 - fed1a000 (reserved) BIOS-e820: fed1c000 - fed9 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff00 - 0001 (reserved) 118MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f6010 Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem229376 -> 259712 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 259712 DMI present. ACPI: RSDP 000F5F80, 0014 (r0 PTLTD ) ACPI: RSDT 3F689EF2, 0048 (r1 PTLTD Capell00 604 LTP0) ACPI: FACP 3F691E25, 0074 (r1 INTEL CALISTGA 604 LOHR 5A) ACPI: DSDT 3F68B5C6, 685F (r1 INTEL CALISTGA 604 INTL 20050624) ACPI: FACS 3F692FC0, 0040 ACPI: APIC 3F691E99, 0068 (r1 INTEL CALISTGA 604 LOHR 5A) ACPI: HPET 3F691F01, 0038 (r1 INTEL CALISTGA 604 LOHR 5A) ACPI: MCFG 3F691F39, 003C (r1 INTEL CALISTGA 604 LOHR 5A) ACPI: BOOT 3F691F75, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: ASF! 3F691F9D, 0063 (r32 CETP CETP 604 PTL 1) ACPI: SSDT 3F68AF77, 064F (r1 SataRe SataPri 1000 INTL 20050624) ACPI: SSDT 3F68A8DB, 069C (r1 SataRe SataSec 1000 INTL 20050624) ACPI: SSDT 3F689F3A, 0508 (r1 PmRefCpuPm 3000 INTL 20050624) ACPI: PM-Timer IO Port: 0x1008 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:14 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 6:14 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Enabling APIC mode: Flat. Using 1 I/O APICs ACPI: HPET id: 0x8086a201 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 5000 (gap: 4000:a000) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 256162 Kernel command line: root=/dev/sda6 vga=normal resume=/dev/sda1 showopts console=tty0 console=ttyS0,9600n8 slub_debug 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 1833.519 MHz processor. Console: colour VGA+ 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 992 kB per task-struct memory footprint: 1200 bytes Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1012416k/1038848k available (1975k kernel code, 25728k reserved, 1495k data, 244k init, 121344k highmem) virtual kernel memory layout: fixmap : 0xfff83000 - 0xf000 ( 496 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc0569000 - 0xc05a6000 ( 244 kB) .data : 0xc03edd37 - 0xc0563b94 (1495 kB) .text : 0xc020 - 0xc03edd37 (1975 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=23, HWalign=64, Order=0-3, MinObjects=16, Processors=2, Nodes=1 hpet0: at MMIO 0xfed0, IRQs 2, 8, 0 hpet0: 3
Re: 2.6.22-rc2-mm1: SLUB-related panic
On Tue, 29 May 2007, Christoph Lameter wrote: when trying to reproduce a bugreport in bugzilla, I am experiencing panics upon boot. The .config which causes this is at [1] Please reboot with slub_debug to identify what causes this. Hi Christoph, with slub_debug, there is no panic (which just supports that there is a race somewhere). The boot with slub_debug below up to the point where it panics without slub_debug Linux version 2.6.22-rc2-mm1 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070302 (prerelease) (SUSE Linux)) #85 SMP PREEMPT Wed May 30 01:44:05 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 3f68 (usable) BIOS-e820: 3f68 - 3f692000 (ACPI data) BIOS-e820: 3f692000 - 3f70 (ACPI NVS) BIOS-e820: 3f70 - 4000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fed0 - fed00400 (reserved) BIOS-e820: fed14000 - fed1a000 (reserved) BIOS-e820: fed1c000 - fed9 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff00 - 0001 (reserved) 118MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f6010 Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 229376 HighMem229376 - 259712 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 - 259712 DMI present. ACPI: RSDP 000F5F80, 0014 (r0 PTLTD ) ACPI: RSDT 3F689EF2, 0048 (r1 PTLTD Capell00 604 LTP0) ACPI: FACP 3F691E25, 0074 (r1 INTEL CALISTGA 604 LOHR 5A) ACPI: DSDT 3F68B5C6, 685F (r1 INTEL CALISTGA 604 INTL 20050624) ACPI: FACS 3F692FC0, 0040 ACPI: APIC 3F691E99, 0068 (r1 INTEL CALISTGA 604 LOHR 5A) ACPI: HPET 3F691F01, 0038 (r1 INTEL CALISTGA 604 LOHR 5A) ACPI: MCFG 3F691F39, 003C (r1 INTEL CALISTGA 604 LOHR 5A) ACPI: BOOT 3F691F75, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: ASF! 3F691F9D, 0063 (r32 CETP CETP 604 PTL 1) ACPI: SSDT 3F68AF77, 064F (r1 SataRe SataPri 1000 INTL 20050624) ACPI: SSDT 3F68A8DB, 069C (r1 SataRe SataSec 1000 INTL 20050624) ACPI: SSDT 3F689F3A, 0508 (r1 PmRefCpuPm 3000 INTL 20050624) ACPI: PM-Timer IO Port: 0x1008 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:14 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 6:14 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Enabling APIC mode: Flat. Using 1 I/O APICs ACPI: HPET id: 0x8086a201 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 5000 (gap: 4000:a000) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 256162 Kernel command line: root=/dev/sda6 vga=normal resume=/dev/sda1 showopts console=tty0 console=ttyS0,9600n8 slub_debug 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 1833.519 MHz processor. Console: colour VGA+ 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 992 kB per task-struct memory footprint: 1200 bytes Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1012416k/1038848k available (1975k kernel code, 25728k reserved, 1495k data, 244k init, 121344k highmem) virtual kernel memory layout: fixmap : 0xfff83000 - 0xf000 ( 496 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc0569000 - 0xc05a6000 ( 244 kB) .data : 0xc03edd37 - 0xc0563b94 (1495 kB) .text : 0xc020 - 0xc03edd37 (1975 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=23, HWalign=64, Order=0-3, MinObjects=16, Processors=2, Nodes=1 hpet0: at MMIO 0xfed0, IRQs 2, 8, 0 hpet0: 3 64-bit timers,
[PATCH] Input: i8042 - cleanup of debug code (was Re: 2.6.22-rc2-mm1)
(some irrelevant CCs dropped)
On Wed, 23 May 2007, Dmitry Torokhov wrote:
It looks like you are now in the same position I was some time ago WRT
to debug information for i8042 - constantly asking people to enable
debug, recompile and send the results. May I recommend changing
CONFIG_HID_DEBUG to default y if !EMBEDDED and controlling debug
output via a module parameter? -ENOPATCH though...
Hi Dmitry,
I have just queued corresponding patch in HID tree.
BTW when looking at the i8042 code I have just noticed that the trivial
cleanup below could be possible.
From: Jiri Kosina [EMAIL PROTECTED]
Input: i8042 - cleanup of debug code
Debugging facility of i8042 is now toggled in runtime instead
of needing to recompile the kernel. Therefore the DEBUG macro
is useless (it's hardcoded to be defined anyway). Remove it.
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 3888dc3..5c3405d 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -69,12 +69,9 @@ module_param_named(nopnp, i8042_nopnp, b
MODULE_PARM_DESC(nopnp, Do not use PNP to detect controller settings);
#endif
-#define DEBUG
-#ifdef DEBUG
static int i8042_debug;
module_param_named(debug, i8042_debug, bool, 0600);
MODULE_PARM_DESC(debug, Turn i8042 debugging mode on and off);
-#endif
#include i8042.h
diff --git a/drivers/input/serio/i8042.h b/drivers/input/serio/i8042.h
index b3eb7a7..eec4b32 100644
--- a/drivers/input/serio/i8042.h
+++ b/drivers/input/serio/i8042.h
@@ -106,7 +106,6 @@
* Debug.
*/
-#ifdef DEBUG
static unsigned long i8042_start_time;
#define dbg_init() do { i8042_start_time = jiffies; } while (0)
#define dbg(format, arg...)
\
@@ -115,9 +114,4 @@ static unsigned long i8042_start_time;
printk(KERN_DEBUG __FILE__ : format [%d]\n ,
\
## arg, (int) (jiffies - i8042_start_time));
\
} while (0)
-#else
-#define dbg_init() do { } while (0)
-#define dbg(format, arg...) do {} while (0)
-#endif
-
#endif /* _I8042_H */
-
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] Input: i8042 - cleanup of debug code (was Re: 2.6.22-rc2-mm1)
Hi Jiri, On 5/30/07, Jiri Kosina [EMAIL PROTECTED] wrote: From: Jiri Kosina [EMAIL PROTECTED] Input: i8042 - cleanup of debug code Debugging facility of i8042 is now toggled in runtime instead of needing to recompile the kernel. Therefore the DEBUG macro is useless (it's hardcoded to be defined anyway). Remove it. I'd rather leave it as is in case someone wants to squeeze last bit of memory savings from the kernel. Also there some security issues (someone breaking into the box and enabling i8042 debug and capturing all keycodes) so uber-sensitive folks can use it to disable debug completely. -- Dmitry - 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] Input: i8042 - cleanup of debug code (was Re: 2.6.22-rc2-mm1)
On Wed, 30 May 2007, Dmitry Torokhov wrote: I'd rather leave it as is in case someone wants to squeeze last bit of memory savings from the kernel. Yup, that's why I left CONFIG_HID_DEBUG still in place to let users that care that much to turn in off. Also there some security issues (someone breaking into the box and enabling i8042 debug and capturing all keycodes) so uber-sensitive folks can use it to disable debug completely. Well this doesn't seem to an issue at all to me - if someone breaks into the box, he has dozens of other possibilities how to capture the keystrokes than enabling i8042 debug. Thanks, -- Jiri Kosina - 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.22-rc2-mm1: SLUB
On Tue, 29 May 2007 11:32:27 -0700 (PDT) Christoph Lameter wrote: > Oh. I forgot the usual instruction: Try to boot with slub_debug on the > kernel command line. SLUB will attempt to remedy the situation to allow > the boot to continue if it finds anything that goes wrong. Yes, that boots, thanks. Problem was the dmi-off-by-one kmalloc. I used the patch that Andrew has merged and it works fine now. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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.22-rc2-mm1: SLUB
Oh. I forgot the usual instruction: Try to boot with slub_debug on the kernel command line. SLUB will attempt to remedy the situation to allow the boot to continue if it finds anything that goes wrong. - 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.22-rc2-mm1: SLUB
On Tue, 29 May 2007, Randy Dunlap wrote: > Nope, still no booty. Your .configs boot fine here (until it panics since I \have another root fs) root (hd0,0) Filesystem type is reiserfs, partition type 0x83 kernel /boot/vmlinuz root=/dev/hda1 console=ttyS0,115200 [Linux-bzImage, setup=0x2800, size=0x245d88] îinux version 2.6.22-rc2-mm1slub ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Deb an 4.1.1-21)) #37 SMP Tue May 29 11:24:17 PDT 2007 Command line: root=/dev/hda1 console=ttyS0,115200 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3fff (usable) BIOS-e820: 3fff - 3fff3000 (ACPI NVS) BIOS-e820: 3fff3000 - 4000 (ACPI data) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) end_pfn_map = 1048576 DMI 2.2 present. ACPI: RSDP 000F6EB0, 0014 (r0 AWARD ) ACPI: RSDT 3FFF3000, 002C (r1 AWARD AWRDACPI 42302E31 AWRD0) ACPI: FACP 3FFF3040, 0074 (r1 AWARD AWRDACPI 42302E31 AWRD0) ACPI: DSDT 3FFF30C0, 3AA4 (r1 AWARD AWRDACPI 1000 MSFT 10E) ACPI: FACS 3FFF, 0040 ACPI: APIC 3FFF6B80, 005A (r1 AWARD AWRDACPI 42302E31 AWRD0) Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 262128 ACPI: PM-Timer IO Port: 0x1008 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl) Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000f swsusp: Registered nosave memory region: 000f - 0010 Allocating PCI resources starting at 5000 (gap: 4000:bec0) SMP: Allowing 1 CPUs, 0 hotplug CPUs PERCPU: Allocating 33416 bytes of per cpu data Built 1 zonelists in Zone order, mobility grouping on. Total pages: 256420 Kernel command line: root=/dev/hda1 console=ttyS0,115200 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) time.c: Detected 2199.446 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Checking aperture... CPU 0: aperture @ e000 size 128 MB Memory: 1023688k/1048512k available (3194k kernel code, 24184k reserved, 1723k data, 228k init) SLUB: Genslabs=23, HWalign=64, Order=0-3, MinObjects=16, Processors=1, Nodes=1 Calibrating delay using timer specific routine.. 4400.89 BogoMIPS (lpj=8801786) kswapd reclaim order set to 3 Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) SMP alternatives: switching to UP code Freeing SMP alternatives: 25k freed ACPI: Core revision 20070126 Using local APIC timer interrupts. result 13746556 Detected 13.746 MHz APIC timer. Brought up 1 CPUs NET: Registered protocol family 16 No dock devices found. ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: (supports S0 S1 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 *7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 *12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: bus type pnp registered pnp: PnP ACPI: found 8 devices ACPI: ACPI bus type pnp unregistered SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report PCI: Cannot allocate resource region 0 of device :00:00.0 agpgart: Detected
Re: 2.6.22-rc2-mm1: SLUB
Christoph Lameter wrote: On Mon, 28 May 2007, Randy Dunlap wrote: Has then already been posted and I missed it.. and it's fixed? :) /me hopes Maybe this patch wil help? Nope, still no booty. SLUB: Fix NUMA / SYSFS bootstrap issue The kmem_cache_node cache is very special because it is needed for NUMA bootstrap. Under certain conditions (like for example if lockdep is enabled and significantly increases the size of spinlock_t) the structure may become exactly the size as one of the larger caches in the kmalloc array. That early during bootstrap we cannot perform merging properly. The unique id for the kmem_cache_node cache will match one of the kmalloc array. Sysfs will complain about a duplicate directory entry. All of this occurs while the console is not yet fully operational. Thus boot may appear to be silently failing. The kmem_cache_node cache is very special. During early boostrap the main allocation function is not operational yet and so we have to run our own small special alloc function during early boot. It is also special in that it is never freed. We really do not want any merging on that cache. Set the refcount -1 and forbid merging of slabs that have a negative refcount. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- mm/slub.c |7 +++ 1 file changed, 7 insertions(+) Index: slub/mm/slub.c === --- slub.orig/mm/slub.c 2007-05-25 18:28:42.0 -0700 +++ slub/mm/slub.c 2007-05-25 18:29:46.0 -0700 @@ -2473,6 +2473,7 @@ void __init kmem_cache_init(void) */ create_kmalloc_cache(_caches[0], "kmem_cache_node", sizeof(struct kmem_cache_node), GFP_KERNEL); + kmalloc_caches[0].refcount = -1; #endif /* Able to allocate the per node structures */ @@ -2520,6 +2521,12 @@ static int slab_unmergeable(struct kmem_ if (s->ctor) return 1; + /* +* We may have set a slab to be unmergeable during bootstrap. +*/ + if (s->refcount < 0) + return 1; + return 0; } -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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.22-rc2-mm1
On Tue, 29 May 2007 18:55:21 +0200, Tilman Schmidt <[EMAIL PROTECTED]> wrote: > Am 29.05.2007 09:25 schrieb Cornelia Huck: > > Could those folks that had trouble with this kernel check out whether > > the following patch helps? > > Yes, that patch fixes my problem. > > Thanks, > Tilman Thanks for testing (to both of you) and again sorry for the breakage. - 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.22-rc2-mm1: SLUB
On Mon, 28 May 2007, Randy Dunlap wrote: > Has then already been posted and I missed it.. and it's fixed? :) > /me hopes Maybe this patch wil help? SLUB: Fix NUMA / SYSFS bootstrap issue The kmem_cache_node cache is very special because it is needed for NUMA bootstrap. Under certain conditions (like for example if lockdep is enabled and significantly increases the size of spinlock_t) the structure may become exactly the size as one of the larger caches in the kmalloc array. That early during bootstrap we cannot perform merging properly. The unique id for the kmem_cache_node cache will match one of the kmalloc array. Sysfs will complain about a duplicate directory entry. All of this occurs while the console is not yet fully operational. Thus boot may appear to be silently failing. The kmem_cache_node cache is very special. During early boostrap the main allocation function is not operational yet and so we have to run our own small special alloc function during early boot. It is also special in that it is never freed. We really do not want any merging on that cache. Set the refcount -1 and forbid merging of slabs that have a negative refcount. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- mm/slub.c |7 +++ 1 file changed, 7 insertions(+) Index: slub/mm/slub.c === --- slub.orig/mm/slub.c 2007-05-25 18:28:42.0 -0700 +++ slub/mm/slub.c 2007-05-25 18:29:46.0 -0700 @@ -2473,6 +2473,7 @@ void __init kmem_cache_init(void) */ create_kmalloc_cache(_caches[0], "kmem_cache_node", sizeof(struct kmem_cache_node), GFP_KERNEL); + kmalloc_caches[0].refcount = -1; #endif /* Able to allocate the per node structures */ @@ -2520,6 +2521,12 @@ static int slab_unmergeable(struct kmem_ if (s->ctor) return 1; + /* +* We may have set a slab to be unmergeable during bootstrap. +*/ + if (s->refcount < 0) + return 1; + return 0; } - 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.22-rc2-mm1: SLUB-related panic
On Mon, 28 May 2007, Jiri Kosina wrote: > when trying to reproduce a bugreport in bugzilla, I am experiencing panics > upon boot. The .config which causes this is at [1] Please reboot with "slub_debug" to identify what causes this. - 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.22-rc2-mm1
Am 29.05.2007 09:25 schrieb Cornelia Huck: > Could those folks that had trouble with this kernel check out whether > the following patch helps? Yes, that patch fixes my problem. Thanks, Tilman > From: Cornelia Huck <[EMAIL PROTECTED]> > > Fix check when to create certain symlinks (the device link and some > compatible links). > > Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]> > [...] -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: 2.6.22-rc2-mm1
On Tue, May 29, 2007 at 09:25:43AM +0200, Cornelia Huck wrote: > On Mon, 28 May 2007 00:41:19 +0200, > "Kay Sievers" <[EMAIL PROTECTED]> wrote: > > > Cornelia, > > in the patch is: > > + if (dev->kobj.parent == >class->subsys.kobj) > > + return 0; > > > > which will skip the creation of the "device"-link, right? > > ...and this is certainly broken. Argl. > > Could those folks that had trouble with this kernel check out whether > the following patch helps? Works for me! Tested-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. - 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.22-rc2-mm1
On Mon, 2007-05-28 at 19:22 +0200, Cornelia Huck wrote: > On Mon, 28 May 2007 00:41:19 +0200, > "Kay Sievers" <[EMAIL PROTECTED]> wrote: > > > Cornelia, > > in the patch is: > > + if (dev->kobj.parent == >class->subsys.kobj) > > + return 0; > > > > which will skip the creation of the "device"-link, right? > > Uh, looking at the code again, this doesn't seem to be what I wanted :( > > > But still, I don't think the transaction-style of error handling is > > what we want, it's for some critical subsystems the equivalent of > > adding PANIC(), and this just for a failing symlink-creation. I think > > we just want to print the to the logs, and not let the whole core > > device registration fail entirely. > > Hm, but failure to create a symlink usually signifies something's really > wrong (no memory, or an object is there which shouldn't)? Sure, but this is core code, which is used by _all_ drivers and _all_ devices. Subsystems can decide to panic if this appropriate, but generic core code should probably not make such decisions. With this change, a single failing symlink (or attribute) for a scsi/ide/block/... device may crash the whole box during bootup. I'm not sure that this is what we want. It's a failure that should be logged (the patch doesn't even add that), but there is probably no reason to refuse the creation of a device, if something non-vital like a symlink or attribute fails to be created. Thanks, Kay - 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.22-rc2-mm1
On Mon, 28 May 2007 00:41:19 +0200,
"Kay Sievers" <[EMAIL PROTECTED]> wrote:
> Cornelia,
> in the patch is:
> + if (dev->kobj.parent == >class->subsys.kobj)
> + return 0;
>
> which will skip the creation of the "device"-link, right?
...and this is certainly broken. Argl.
Could those folks that had trouble with this kernel check out whether
the following patch helps?
From: Cornelia Huck <[EMAIL PROTECTED]>
Fix check when to create certain symlinks (the device link and some
compatible links).
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
---
drivers/base/core.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
--- linux-2.6.orig/drivers/base/core.c
+++ linux-2.6/drivers/base/core.c
@@ -657,12 +657,12 @@ static int device_add_class_symlinks(str
* If this is not a "fake" compatible device, then create the
* symlink from the class to the device.
*/
- if (dev->kobj.parent == >class->subsys.kobj)
- return 0;
- error = sysfs_create_link(>class->subsys.kobj, >kobj,
- dev->bus_id);
- if (error)
- goto out_subsys;
+ if (dev->kobj.parent != >class->subsys.kobj) {
+ error = sysfs_create_link(>class->subsys.kobj, >kobj,
+ dev->bus_id);
+ if (error)
+ goto out_subsys;
+ }
if (dev->parent) {
error = sysfs_create_link(>kobj, >parent->kobj,
"device");
@@ -689,7 +689,8 @@ out_device:
sysfs_remove_link(>kobj, "device");
#endif
out_busid:
- sysfs_remove_link(>class->subsys.kobj, dev->bus_id);
+ if (dev->kobj.parent != >class->subsys.kobj)
+ sysfs_remove_link(>class->subsys.kobj, dev->bus_id);
out_subsys:
sysfs_remove_link(>kobj, "subsystem");
out:
@@ -712,7 +713,8 @@ static void device_remove_class_symlinks
#endif
sysfs_remove_link(>kobj, "device");
}
- sysfs_remove_link(>class->subsys.kobj, dev->bus_id);
+ if (dev->kobj.parent != >class->subsys.kobj)
+ sysfs_remove_link(>class->subsys.kobj, dev->bus_id);
sysfs_remove_link(>kobj, "subsystem");
}
-
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.22-rc2-mm1
On Mon, 28 May 2007 00:41:19 +0200,
Kay Sievers [EMAIL PROTECTED] wrote:
Cornelia,
in the patch is:
+ if (dev-kobj.parent == dev-class-subsys.kobj)
+ return 0;
which will skip the creation of the device-link, right?
...and this is certainly broken. Argl.
Could those folks that had trouble with this kernel check out whether
the following patch helps?
From: Cornelia Huck [EMAIL PROTECTED]
Fix check when to create certain symlinks (the device link and some
compatible links).
Signed-off-by: Cornelia Huck [EMAIL PROTECTED]
---
drivers/base/core.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
--- linux-2.6.orig/drivers/base/core.c
+++ linux-2.6/drivers/base/core.c
@@ -657,12 +657,12 @@ static int device_add_class_symlinks(str
* If this is not a fake compatible device, then create the
* symlink from the class to the device.
*/
- if (dev-kobj.parent == dev-class-subsys.kobj)
- return 0;
- error = sysfs_create_link(dev-class-subsys.kobj, dev-kobj,
- dev-bus_id);
- if (error)
- goto out_subsys;
+ if (dev-kobj.parent != dev-class-subsys.kobj) {
+ error = sysfs_create_link(dev-class-subsys.kobj, dev-kobj,
+ dev-bus_id);
+ if (error)
+ goto out_subsys;
+ }
if (dev-parent) {
error = sysfs_create_link(dev-kobj, dev-parent-kobj,
device);
@@ -689,7 +689,8 @@ out_device:
sysfs_remove_link(dev-kobj, device);
#endif
out_busid:
- sysfs_remove_link(dev-class-subsys.kobj, dev-bus_id);
+ if (dev-kobj.parent != dev-class-subsys.kobj)
+ sysfs_remove_link(dev-class-subsys.kobj, dev-bus_id);
out_subsys:
sysfs_remove_link(dev-kobj, subsystem);
out:
@@ -712,7 +713,8 @@ static void device_remove_class_symlinks
#endif
sysfs_remove_link(dev-kobj, device);
}
- sysfs_remove_link(dev-class-subsys.kobj, dev-bus_id);
+ if (dev-kobj.parent != dev-class-subsys.kobj)
+ sysfs_remove_link(dev-class-subsys.kobj, dev-bus_id);
sysfs_remove_link(dev-kobj, subsystem);
}
-
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.22-rc2-mm1
On Mon, 2007-05-28 at 19:22 +0200, Cornelia Huck wrote: On Mon, 28 May 2007 00:41:19 +0200, Kay Sievers [EMAIL PROTECTED] wrote: Cornelia, in the patch is: + if (dev-kobj.parent == dev-class-subsys.kobj) + return 0; which will skip the creation of the device-link, right? Uh, looking at the code again, this doesn't seem to be what I wanted :( But still, I don't think the transaction-style of error handling is what we want, it's for some critical subsystems the equivalent of adding PANIC(), and this just for a failing symlink-creation. I think we just want to print the to the logs, and not let the whole core device registration fail entirely. Hm, but failure to create a symlink usually signifies something's really wrong (no memory, or an object is there which shouldn't)? Sure, but this is core code, which is used by _all_ drivers and _all_ devices. Subsystems can decide to panic if this appropriate, but generic core code should probably not make such decisions. With this change, a single failing symlink (or attribute) for a scsi/ide/block/... device may crash the whole box during bootup. I'm not sure that this is what we want. It's a failure that should be logged (the patch doesn't even add that), but there is probably no reason to refuse the creation of a device, if something non-vital like a symlink or attribute fails to be created. Thanks, Kay - 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.22-rc2-mm1
On Tue, May 29, 2007 at 09:25:43AM +0200, Cornelia Huck wrote: On Mon, 28 May 2007 00:41:19 +0200, Kay Sievers [EMAIL PROTECTED] wrote: Cornelia, in the patch is: + if (dev-kobj.parent == dev-class-subsys.kobj) + return 0; which will skip the creation of the device-link, right? ...and this is certainly broken. Argl. Could those folks that had trouble with this kernel check out whether the following patch helps? Works for me! Tested-by: Matt Mackall [EMAIL PROTECTED] -- Mathematics is the supreme nostalgia of our time. - 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.22-rc2-mm1
Am 29.05.2007 09:25 schrieb Cornelia Huck: Could those folks that had trouble with this kernel check out whether the following patch helps? Yes, that patch fixes my problem. Thanks, Tilman From: Cornelia Huck [EMAIL PROTECTED] Fix check when to create certain symlinks (the device link and some compatible links). Signed-off-by: Cornelia Huck [EMAIL PROTECTED] [...] -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: 2.6.22-rc2-mm1: SLUB-related panic
On Mon, 28 May 2007, Jiri Kosina wrote: when trying to reproduce a bugreport in bugzilla, I am experiencing panics upon boot. The .config which causes this is at [1] Please reboot with slub_debug to identify what causes this. - 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.22-rc2-mm1: SLUB
On Mon, 28 May 2007, Randy Dunlap wrote: Has then already been posted and I missed it.. and it's fixed? :) /me hopes Maybe this patch wil help? SLUB: Fix NUMA / SYSFS bootstrap issue The kmem_cache_node cache is very special because it is needed for NUMA bootstrap. Under certain conditions (like for example if lockdep is enabled and significantly increases the size of spinlock_t) the structure may become exactly the size as one of the larger caches in the kmalloc array. That early during bootstrap we cannot perform merging properly. The unique id for the kmem_cache_node cache will match one of the kmalloc array. Sysfs will complain about a duplicate directory entry. All of this occurs while the console is not yet fully operational. Thus boot may appear to be silently failing. The kmem_cache_node cache is very special. During early boostrap the main allocation function is not operational yet and so we have to run our own small special alloc function during early boot. It is also special in that it is never freed. We really do not want any merging on that cache. Set the refcount -1 and forbid merging of slabs that have a negative refcount. Signed-off-by: Christoph Lameter [EMAIL PROTECTED] --- mm/slub.c |7 +++ 1 file changed, 7 insertions(+) Index: slub/mm/slub.c === --- slub.orig/mm/slub.c 2007-05-25 18:28:42.0 -0700 +++ slub/mm/slub.c 2007-05-25 18:29:46.0 -0700 @@ -2473,6 +2473,7 @@ void __init kmem_cache_init(void) */ create_kmalloc_cache(kmalloc_caches[0], kmem_cache_node, sizeof(struct kmem_cache_node), GFP_KERNEL); + kmalloc_caches[0].refcount = -1; #endif /* Able to allocate the per node structures */ @@ -2520,6 +2521,12 @@ static int slab_unmergeable(struct kmem_ if (s-ctor) return 1; + /* +* We may have set a slab to be unmergeable during bootstrap. +*/ + if (s-refcount 0) + return 1; + return 0; } - 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.22-rc2-mm1
On Tue, 29 May 2007 18:55:21 +0200, Tilman Schmidt [EMAIL PROTECTED] wrote: Am 29.05.2007 09:25 schrieb Cornelia Huck: Could those folks that had trouble with this kernel check out whether the following patch helps? Yes, that patch fixes my problem. Thanks, Tilman Thanks for testing (to both of you) and again sorry for the breakage. - 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.22-rc2-mm1: SLUB
Christoph Lameter wrote: On Mon, 28 May 2007, Randy Dunlap wrote: Has then already been posted and I missed it.. and it's fixed? :) /me hopes Maybe this patch wil help? Nope, still no booty. SLUB: Fix NUMA / SYSFS bootstrap issue The kmem_cache_node cache is very special because it is needed for NUMA bootstrap. Under certain conditions (like for example if lockdep is enabled and significantly increases the size of spinlock_t) the structure may become exactly the size as one of the larger caches in the kmalloc array. That early during bootstrap we cannot perform merging properly. The unique id for the kmem_cache_node cache will match one of the kmalloc array. Sysfs will complain about a duplicate directory entry. All of this occurs while the console is not yet fully operational. Thus boot may appear to be silently failing. The kmem_cache_node cache is very special. During early boostrap the main allocation function is not operational yet and so we have to run our own small special alloc function during early boot. It is also special in that it is never freed. We really do not want any merging on that cache. Set the refcount -1 and forbid merging of slabs that have a negative refcount. Signed-off-by: Christoph Lameter [EMAIL PROTECTED] --- mm/slub.c |7 +++ 1 file changed, 7 insertions(+) Index: slub/mm/slub.c === --- slub.orig/mm/slub.c 2007-05-25 18:28:42.0 -0700 +++ slub/mm/slub.c 2007-05-25 18:29:46.0 -0700 @@ -2473,6 +2473,7 @@ void __init kmem_cache_init(void) */ create_kmalloc_cache(kmalloc_caches[0], kmem_cache_node, sizeof(struct kmem_cache_node), GFP_KERNEL); + kmalloc_caches[0].refcount = -1; #endif /* Able to allocate the per node structures */ @@ -2520,6 +2521,12 @@ static int slab_unmergeable(struct kmem_ if (s-ctor) return 1; + /* +* We may have set a slab to be unmergeable during bootstrap. +*/ + if (s-refcount 0) + return 1; + return 0; } -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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.22-rc2-mm1: SLUB
On Tue, 29 May 2007, Randy Dunlap wrote: Nope, still no booty. Your .configs boot fine here (until it panics since I \have another root fs) root (hd0,0) Filesystem type is reiserfs, partition type 0x83 kernel /boot/vmlinuz root=/dev/hda1 console=ttyS0,115200 [Linux-bzImage, setup=0x2800, size=0x245d88] îinux version 2.6.22-rc2-mm1slub ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Deb an 4.1.1-21)) #37 SMP Tue May 29 11:24:17 PDT 2007 Command line: root=/dev/hda1 console=ttyS0,115200 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3fff (usable) BIOS-e820: 3fff - 3fff3000 (ACPI NVS) BIOS-e820: 3fff3000 - 4000 (ACPI data) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) end_pfn_map = 1048576 DMI 2.2 present. ACPI: RSDP 000F6EB0, 0014 (r0 AWARD ) ACPI: RSDT 3FFF3000, 002C (r1 AWARD AWRDACPI 42302E31 AWRD0) ACPI: FACP 3FFF3040, 0074 (r1 AWARD AWRDACPI 42302E31 AWRD0) ACPI: DSDT 3FFF30C0, 3AA4 (r1 AWARD AWRDACPI 1000 MSFT 10E) ACPI: FACS 3FFF, 0040 ACPI: APIC 3FFF6B80, 005A (r1 AWARD AWRDACPI 42302E31 AWRD0) Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 262128 ACPI: PM-Timer IO Port: 0x1008 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl) Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000f swsusp: Registered nosave memory region: 000f - 0010 Allocating PCI resources starting at 5000 (gap: 4000:bec0) SMP: Allowing 1 CPUs, 0 hotplug CPUs PERCPU: Allocating 33416 bytes of per cpu data Built 1 zonelists in Zone order, mobility grouping on. Total pages: 256420 Kernel command line: root=/dev/hda1 console=ttyS0,115200 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) time.c: Detected 2199.446 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Checking aperture... CPU 0: aperture @ e000 size 128 MB Memory: 1023688k/1048512k available (3194k kernel code, 24184k reserved, 1723k data, 228k init) SLUB: Genslabs=23, HWalign=64, Order=0-3, MinObjects=16, Processors=1, Nodes=1 Calibrating delay using timer specific routine.. 4400.89 BogoMIPS (lpj=8801786) kswapd reclaim order set to 3 Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) SMP alternatives: switching to UP code Freeing SMP alternatives: 25k freed ACPI: Core revision 20070126 Using local APIC timer interrupts. result 13746556 Detected 13.746 MHz APIC timer. Brought up 1 CPUs NET: Registered protocol family 16 No dock devices found. ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: (supports S0 S1 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 *7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 *12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: bus type pnp registered pnp: PnP ACPI: found 8 devices ACPI: ACPI bus type pnp unregistered SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try pci=routeirq. If it helps, post a report PCI: Cannot allocate resource region 0 of device :00:00.0 agpgart: Detected AGP
Re: 2.6.22-rc2-mm1: SLUB
Oh. I forgot the usual instruction: Try to boot with slub_debug on the kernel command line. SLUB will attempt to remedy the situation to allow the boot to continue if it finds anything that goes wrong. - 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.22-rc2-mm1: SLUB
On Tue, 29 May 2007 11:32:27 -0700 (PDT) Christoph Lameter wrote: Oh. I forgot the usual instruction: Try to boot with slub_debug on the kernel command line. SLUB will attempt to remedy the situation to allow the boot to continue if it finds anything that goes wrong. Yes, that boots, thanks. Problem was the dmi-off-by-one kmalloc. I used the patch that Andrew has merged and it works fine now. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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.22-rc2-mm1
On Mon, 28 May 2007 00:41:19 +0200, "Kay Sievers" <[EMAIL PROTECTED]> wrote: > Cornelia, > in the patch is: > + if (dev->kobj.parent == >class->subsys.kobj) > + return 0; > > which will skip the creation of the "device"-link, right? Uh, looking at the code again, this doesn't seem to be what I wanted :( > But still, I don't think the transaction-style of error handling is > what we want, it's for some critical subsystems the equivalent of > adding PANIC(), and this just for a failing symlink-creation. I think > we just want to print the to the logs, and not let the whole core > device registration fail entirely. Hm, but failure to create a symlink usually signifies something's really wrong (no memory, or an object is there which shouldn't)? - 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.22-rc2-mm1 - a different BUG: at mm/slab.c:777 __find_general_cachep()
On Mon, 28 May 2007 13:43:12 +0300, Pekka Enberg said: > On 5/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > [4294667.472000] BUG: at mm/slab.c:777 __find_general_cachep() > > [snip] > > > Any suggestions before I go doing the bisect shuffle? > > It's complaining about a kmalloc() with size zero. The warning is new > and harmless for now, so no need to bisect this (it will point you at > the mm/slab.c change by Christoph Lameter). I knew *that* part. Closer look at drivers/firmware/dmi-id.c indicates that it's likely a busticated DMI field in my BIOS - looking around at the stuff in /sys/devices/virtual/dmi/id I found that the files product_version, board_version board_asset_tag, chassis_version, and chassis_asset_tag are empty (trying to 'cat' them gets just a \n) - the other values all look sane. This looks fishy: #define ADD_DMI_ATTR(_name, _field) if (dmi_get_system_info(_field)) sys_dmi_attributes[i++] = & sys_dmi_##_name##_attr.attr; Should that be making a check that it's not pointing at a null string? pgp1GNIMszx81.pgp Description: PGP signature
Re: 2.6.22-rc2-mm1 - a different BUG: at mm/slab.c:777 __find_general_cachep()
On 5/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: [4294667.472000] BUG: at mm/slab.c:777 __find_general_cachep() [snip] Any suggestions before I go doing the bisect shuffle? It's complaining about a kmalloc() with size zero. The warning is new and harmless for now, so no need to bisect this (it will point you at the mm/slab.c change by Christoph Lameter). - 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.22-rc2-mm1 - a different BUG: at mm/slab.c:777 __find_general_cachep()
On Wed, 23 May 2007 00:42:33 PDT, Andrew Morton said: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ Dell Latitude D820 laptop, Intel T7200 dual-core, x86_64 kernel. Does something wonky during very early boot, before userspace has started: [4294667.471000] Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz stepping 06 [4294667.471000] Brought up 2 CPUs [4294667.471000] NET: Registered protocol family 16 [4294667.472000] ACPI: ACPI Dock Station Driver [4294667.472000] ACPI: bus type pci registered [4294667.472000] BUG: at mm/slab.c:777 __find_general_cachep() [4294667.472000] [4294667.472000] Call Trace: [4294667.472000] [] dump_trace+0xca/0x3cb [4294667.472000] [] show_trace+0x3c/0x52 [4294667.472000] [] dump_stack+0x15/0x17 [4294667.472000] [] __kmalloc+0x41/0xb2 [4294667.472000] [] get_modalias+0x6c/0x107 [4294667.472000] [] dmi_dev_uevent+0x35/0x4d [4294667.472000] [] dev_uevent+0x19b/0x1d1 [4294667.472000] [] kobject_uevent_env+0x244/0x477 [4294667.472000] [] kobject_uevent+0xb/0xd [4294667.472000] [] device_add+0x2b5/0x4eb [4294667.472000] [] device_register+0x19/0x1d [4294667.472000] [] dmi_id_init+0x2d1/0x2e9 [4294667.472000] [] kernel_init+0x168/0x2da [4294667.472000] [] child_rip+0xa/0x12 [4294667.472000] [4294667.473000] PCI: Using MMCONFIG at f000 - f3ff [4294667.489000] ACPI: SSDT 7FE819CE, 0043 (r1 LMPWR DELLLOM 1001 INTL 20050624) Any suggestions before I go doing the bisect shuffle? pgpSyNoPNC4Pc.pgp Description: PGP signature
Re: 2.6.22-rc2-mm1 - a different BUG: at mm/slab.c:777 __find_general_cachep()
On Wed, 23 May 2007 00:42:33 PDT, Andrew Morton said: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ Dell Latitude D820 laptop, Intel T7200 dual-core, x86_64 kernel. Does something wonky during very early boot, before userspace has started: [4294667.471000] Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz stepping 06 [4294667.471000] Brought up 2 CPUs [4294667.471000] NET: Registered protocol family 16 [4294667.472000] ACPI: ACPI Dock Station Driver [4294667.472000] ACPI: bus type pci registered [4294667.472000] BUG: at mm/slab.c:777 __find_general_cachep() [4294667.472000] [4294667.472000] Call Trace: [4294667.472000] [8020b2a8] dump_trace+0xca/0x3cb [4294667.472000] [8020b5e5] show_trace+0x3c/0x52 [4294667.472000] [8020b610] dump_stack+0x15/0x17 [4294667.472000] [8028952e] __kmalloc+0x41/0xb2 [4294667.472000] [8042c450] get_modalias+0x6c/0x107 [4294667.472000] [8042c520] dmi_dev_uevent+0x35/0x4d [4294667.472000] [803b7d5f] dev_uevent+0x19b/0x1d1 [4294667.472000] [8034bd3c] kobject_uevent_env+0x244/0x477 [4294667.472000] [8034bf7a] kobject_uevent+0xb/0xd [4294667.472000] [803b7971] device_add+0x2b5/0x4eb [4294667.472000] [803b7bc0] device_register+0x19/0x1d [4294667.472000] [807dd71a] dmi_id_init+0x2d1/0x2e9 [4294667.472000] [807c1651] kernel_init+0x168/0x2da [4294667.472000] [8020acd8] child_rip+0xa/0x12 [4294667.472000] [4294667.473000] PCI: Using MMCONFIG at f000 - f3ff [4294667.489000] ACPI: SSDT 7FE819CE, 0043 (r1 LMPWR DELLLOM 1001 INTL 20050624) Any suggestions before I go doing the bisect shuffle? pgpSyNoPNC4Pc.pgp Description: PGP signature
Re: 2.6.22-rc2-mm1 - a different BUG: at mm/slab.c:777 __find_general_cachep()
On 5/28/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [4294667.472000] BUG: at mm/slab.c:777 __find_general_cachep() [snip] Any suggestions before I go doing the bisect shuffle? It's complaining about a kmalloc() with size zero. The warning is new and harmless for now, so no need to bisect this (it will point you at the mm/slab.c change by Christoph Lameter). - 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.22-rc2-mm1 - a different BUG: at mm/slab.c:777 __find_general_cachep()
On Mon, 28 May 2007 13:43:12 +0300, Pekka Enberg said: On 5/28/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [4294667.472000] BUG: at mm/slab.c:777 __find_general_cachep() [snip] Any suggestions before I go doing the bisect shuffle? It's complaining about a kmalloc() with size zero. The warning is new and harmless for now, so no need to bisect this (it will point you at the mm/slab.c change by Christoph Lameter). I knew *that* part. Closer look at drivers/firmware/dmi-id.c indicates that it's likely a busticated DMI field in my BIOS - looking around at the stuff in /sys/devices/virtual/dmi/id I found that the files product_version, board_version board_asset_tag, chassis_version, and chassis_asset_tag are empty (trying to 'cat' them gets just a \n) - the other values all look sane. This looks fishy: #define ADD_DMI_ATTR(_name, _field) if (dmi_get_system_info(_field)) sys_dmi_attributes[i++] = sys_dmi_##_name##_attr.attr; Should that be making a check that it's not pointing at a null string? pgp1GNIMszx81.pgp Description: PGP signature
Re: 2.6.22-rc2-mm1
On Mon, 28 May 2007 00:41:19 +0200, Kay Sievers [EMAIL PROTECTED] wrote: Cornelia, in the patch is: + if (dev-kobj.parent == dev-class-subsys.kobj) + return 0; which will skip the creation of the device-link, right? Uh, looking at the code again, this doesn't seem to be what I wanted :( But still, I don't think the transaction-style of error handling is what we want, it's for some critical subsystems the equivalent of adding PANIC(), and this just for a failing symlink-creation. I think we just want to print the to the logs, and not let the whole core device registration fail entirely. Hm, but failure to create a symlink usually signifies something's really wrong (no memory, or an object is there which shouldn't)? - 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.22-rc2-mm1
On 5/28/07, Tilman Schmidt <[EMAIL PROTECTED]> wrote: Am 26.05.2007 18:01 schrieb Andrew Morton: > On Sat, 26 May 2007 17:59:15 +0200 Tilman Schmidt <[EMAIL PROTECTED]> wrote: >> This breaks network initialization on my SuSE 10.0 box [...] > > Thanks. I think others have seen similar things and it was attributed to > driver-core-check-return-code-of-sysfs_create_link.patch. That's it. After reverting that patch, the Ethernet interface comes up fine again. Cornelia, in the patch is: + if (dev->kobj.parent == >class->subsys.kobj) + return 0; which will skip the creation of the "device"-link, right? But still, I don't think the transaction-style of error handling is what we want, it's for some critical subsystems the equivalent of adding PANIC(), and this just for a failing symlink-creation. I think we just want to print the to the logs, and not let the whole core device registration fail entirely. Thanks, Kay - 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.22-rc2-mm1
Am 26.05.2007 18:01 schrieb Andrew Morton: > On Sat, 26 May 2007 17:59:15 +0200 Tilman Schmidt <[EMAIL PROTECTED]> wrote: >> This breaks network initialization on my SuSE 10.0 box [...] > > Thanks. I think others have seen similar things and it was attributed to > driver-core-check-return-code-of-sysfs_create_link.patch. That's it. After reverting that patch, the Ethernet interface comes up fine again. Thanks, Tilman -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: 2.6.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, 25 May 2007 17:02:09 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > This wouldn't be the first time this patch has broken things :( > > Why does checking these errors cause ipw2200 to fail? I'd like to know this as well. Could someone stick in some printk's to find out which symlink creation fails (which is most likely the problem)? > > > Andrew, can you drop this from your tree? > > Would prefer that we debug things first. It could be that ipw2200 is > trying to create symlinks which already exist. This might indicate a > programming error in ipw2200, which is what the patch is *for*. If it > is indeed an ipw2200 bug then the lesson is that we should have been checking > for errors on day one - that way, we'd never have shipped a buggy ipw2200 > driver. > > I have an ipw2200 - I'll see if I can reproduce this and I'll add some > debugging code in there. Probably that debugging code should become > permanent. Thanks, that would be much appreciated. > > > Cornelia, can you rework this to not break things? > > Things might be already broken? Or I might have messed up (I hope not). Sorry for the pain anyway. - 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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, 25 May 2007 17:02:09 -0700, Andrew Morton [EMAIL PROTECTED] wrote: This wouldn't be the first time this patch has broken things :( Why does checking these errors cause ipw2200 to fail? I'd like to know this as well. Could someone stick in some printk's to find out which symlink creation fails (which is most likely the problem)? Andrew, can you drop this from your tree? Would prefer that we debug things first. It could be that ipw2200 is trying to create symlinks which already exist. This might indicate a programming error in ipw2200, which is what the patch is *for*. If it is indeed an ipw2200 bug then the lesson is that we should have been checking for errors on day one - that way, we'd never have shipped a buggy ipw2200 driver. I have an ipw2200 - I'll see if I can reproduce this and I'll add some debugging code in there. Probably that debugging code should become permanent. Thanks, that would be much appreciated. Cornelia, can you rework this to not break things? Things might be already broken? Or I might have messed up (I hope not). Sorry for the pain anyway. - 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.22-rc2-mm1
Am 26.05.2007 18:01 schrieb Andrew Morton: On Sat, 26 May 2007 17:59:15 +0200 Tilman Schmidt [EMAIL PROTECTED] wrote: This breaks network initialization on my SuSE 10.0 box [...] Thanks. I think others have seen similar things and it was attributed to driver-core-check-return-code-of-sysfs_create_link.patch. That's it. After reverting that patch, the Ethernet interface comes up fine again. Thanks, Tilman -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: 2.6.22-rc2-mm1
On 5/28/07, Tilman Schmidt [EMAIL PROTECTED] wrote: Am 26.05.2007 18:01 schrieb Andrew Morton: On Sat, 26 May 2007 17:59:15 +0200 Tilman Schmidt [EMAIL PROTECTED] wrote: This breaks network initialization on my SuSE 10.0 box [...] Thanks. I think others have seen similar things and it was attributed to driver-core-check-return-code-of-sysfs_create_link.patch. That's it. After reverting that patch, the Ethernet interface comes up fine again. Cornelia, in the patch is: + if (dev-kobj.parent == dev-class-subsys.kobj) + return 0; which will skip the creation of the device-link, right? But still, I don't think the transaction-style of error handling is what we want, it's for some critical subsystems the equivalent of adding PANIC(), and this just for a failing symlink-creation. I think we just want to print the to the logs, and not let the whole core device registration fail entirely. Thanks, Kay - 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.22-rc2-mm1
On Sat, 26 May 2007 17:59:15 +0200 Tilman Schmidt <[EMAIL PROTECTED]> wrote: > Am 23.05.2007 09:42 schrieb Andrew Morton: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ > > This breaks network initialization on my SuSE 10.0 box once > again although I compiled with CONFIG_SYSFS_DEPRECATED=y. > Acquisition of the IP address via DHCP times out. > Manual start (rcnetwork restart) doesn't help either. > > I'll start bisecting as soon as the machine is free. Thanks. I think others have seen similar things and it was attributed to driver-core-check-return-code-of-sysfs_create_link.patch. - 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.22-rc2-mm1
Am 23.05.2007 09:42 schrieb Andrew Morton: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ This breaks network initialization on my SuSE 10.0 box once again although I compiled with CONFIG_SYSFS_DEPRECATED=y. Acquisition of the IP address via DHCP times out. Manual start (rcnetwork restart) doesn't help either. I'll start bisecting as soon as the machine is free. -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: 2.6.22-rc2-mm1
Am 23.05.2007 09:42 schrieb Andrew Morton: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ This breaks network initialization on my SuSE 10.0 box once again although I compiled with CONFIG_SYSFS_DEPRECATED=y. Acquisition of the IP address via DHCP times out. Manual start (rcnetwork restart) doesn't help either. I'll start bisecting as soon as the machine is free. -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: 2.6.22-rc2-mm1
On Sat, 26 May 2007 17:59:15 +0200 Tilman Schmidt [EMAIL PROTECTED] wrote: Am 23.05.2007 09:42 schrieb Andrew Morton: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ This breaks network initialization on my SuSE 10.0 box once again although I compiled with CONFIG_SYSFS_DEPRECATED=y. Acquisition of the IP address via DHCP times out. Manual start (rcnetwork restart) doesn't help either. I'll start bisecting as soon as the machine is free. Thanks. I think others have seen similar things and it was attributed to driver-core-check-return-code-of-sysfs_create_link.patch. - 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: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
On Fri, May 25, 2007 at 07:48:14PM -0400, Jeff Garzik wrote:
>
> Is this for -stable or upstream? I got confused with all the patches
> flying about.
>
> Send it to me, if it's for upstream.
It's for upstream. Once you take then I'll rediff it for stable.
[E1000]: Restore netif_poll_enable call but make sure IRQs are off
This restores the previously removed netif_poll_enable call in
e1000_open. It's needed on all but the first call to e1000_open
for a NIC as e1000_close always calls netif_poll_disable.
netif_poll_enable can only be called safely if no polls have been
scheduled. This should be the case as long as we don't enter our
IRQ handler.
In order to guarantee this we explicitly disable IRQs as early
as possible when we're probing the NIC.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index cbc7feb..9ec35b7 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1325,7 +1325,10 @@ e1000_sw_init(struct e1000_adapter *adapter)
spin_lock_init(>tx_queue_lock);
#endif
- atomic_set(>irq_sem, 1);
+ /* Explicitly disable IRQ since the NIC can be in any state. */
+ atomic_set(>irq_sem, 0);
+ e1000_irq_disable(adapter);
+
spin_lock_init(>stats_lock);
set_bit(__E1000_DOWN, >flags);
@@ -1431,6 +1434,10 @@ e1000_open(struct net_device *netdev)
/* From here on the code is the same as e1000_up() */
clear_bit(__E1000_DOWN, >flags);
+#ifdef CONFIG_E1000_NAPI
+ netif_poll_enable(netdev);
+#endif
+
e1000_irq_enable(adapter);
/* fire a link status change interrupt to start the watchdog */
-
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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, 25 May 2007 16:12:57 -0700 Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, May 25, 2007 at 06:01:09PM -0500, Matt Mackall wrote:
> > Bisect sequence went 56+ 84+ 98+ 105- 102- 100+ 101+. Looks like 102's
> > to blame:
> >
> > driver-core-check-return-code-of-sysfs_create_link.patch
> >
> > From: Cornelia Huck <[EMAIL PROTECTED]>
> >
> > Check for return value of sysfs_create_link() in device_add() and
> > device_rename(). Add helper functions device_add_class_symlinks() and
> > device_remove_class_symlinks() to make the code easier to read.
>
> {sigh}
>
> This wouldn't be the first time this patch has broken things :(
Why does checking these errors cause ipw2200 to fail?
> Andrew, can you drop this from your tree?
Would prefer that we debug things first. It could be that ipw2200 is
trying to create symlinks which already exist. This might indicate a
programming error in ipw2200, which is what the patch is *for*. If it
is indeed an ipw2200 bug then the lesson is that we should have been checking
for errors on day one - that way, we'd never have shipped a buggy ipw2200
driver.
I have an ipw2200 - I'll see if I can reproduce this and I'll add some
debugging code in there. Probably that debugging code should become
permanent.
> Cornelia, can you rework this to not break things?
Things might be already broken?
-
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: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
Kok, Auke wrote: Herbert Xu wrote: On Fri, May 25, 2007 at 11:04:04PM +1000, Herbert Xu wrote: [E1000]: Call netif_poll_enable in e1000_open Here is a better one. [E1000]: Restore netif_poll_enable call but make sure IRQs are off This restores the previously removed netif_poll_enable call in e1000_open. It's needed on all but the first call to e1000_open for a NIC as e1000_close always calls netif_poll_disable. netif_poll_enable can only be called safely if no polls have been scheduled. This should be the case as long as we don't enter our IRQ handler. In order to guarantee this we explicitly disable IRQs as early as possible when we're probing the NIC. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Ack! this also fixes all the issues we had seen ourselves. I took a bit of time to get our labs to test it. Who can pick this patch up for us? Jeff ? Is this for -stable or upstream? I got confused with all the patches flying about. Send it to me, if it's for upstream. Jeff - 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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, 2007-05-25 at 16:12 -0700, Greg KH wrote:
> On Fri, May 25, 2007 at 06:01:09PM -0500, Matt Mackall wrote:
> > Bisect sequence went 56+ 84+ 98+ 105- 102- 100+ 101+. Looks like 102's
> > to blame:
> >
> > driver-core-check-return-code-of-sysfs_create_link.patch
> >
> > From: Cornelia Huck <[EMAIL PROTECTED]>
> >
> > Check for return value of sysfs_create_link() in device_add() and
> > device_rename(). Add helper functions device_add_class_symlinks() and
> > device_remove_class_symlinks() to make the code easier to read.
>
> {sigh}
>
> This wouldn't be the first time this patch has broken things :(
>
> Andrew, can you drop this from your tree?
>
> Cornelia, can you rework this to not break things?
Before we continue that road, we should define the expected behavior for
the "cleanup" in error paths. Implementing that transaction-like model,
to rewind a the complete device-creation when something like a symlink
can't be created, may not always be the right thing to do.
I think in most cases, we just want to write something like that to the
error logs and continue, instead of letting a whole subsystem fail, or
in the worst case, prevent the box from booting up.
Thanks,
Kay
-
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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, May 25, 2007 at 06:01:09PM -0500, Matt Mackall wrote:
> Bisect sequence went 56+ 84+ 98+ 105- 102- 100+ 101+. Looks like 102's
> to blame:
>
> driver-core-check-return-code-of-sysfs_create_link.patch
>
> From: Cornelia Huck <[EMAIL PROTECTED]>
>
> Check for return value of sysfs_create_link() in device_add() and
> device_rename(). Add helper functions device_add_class_symlinks() and
> device_remove_class_symlinks() to make the code easier to read.
{sigh}
This wouldn't be the first time this patch has broken things :(
Andrew, can you drop this from your tree?
Cornelia, can you rework this to not break things?
thanks,
greg k-h
-
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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, May 25, 2007 at 04:01:52PM -0500, Matt Mackall wrote: > On Fri, May 25, 2007 at 12:53:19PM -0500, Matt Mackall wrote: > > On Fri, May 25, 2007 at 07:37:46PM +0200, Kay Sievers wrote: > > > On 5/25/07, Greg KH <[EMAIL PROTECTED]> wrote: > > > >On Fri, May 25, 2007 at 11:36:22AM -0500, Matt Mackall wrote: > > > >> 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't > > > >> matter. Bringing up the interface manually still works, so I suspect > > > >> this is sysfs or HAL related again. Again, Debian unstable so > > > >> userspace is quite up-to-date. > > > > > > > >I don't have any driver model changes that affect network devices in my > > > >tree. Could you go through and bisect the -mm tree to see if you can > > > >find the patch that causes this? > > > > > > Does it work, when you unload and load the kernel module? > > > > rmmod followed by insmod had no effect. > > > > > Does it work when you restart HAL and then NetworkManager? > > > > I restarted dbus, which stopped and restarted HAL and NM. No effect. > > > > > Can you compare the sections for the wireless card in the output of > > > "lshal"? > > > > The unhappy one looks like this: > > > > udi = '/org/freedesktop/Hal/devices/pci_8086_4220' > > info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) > > linux.subsystem = 'pci' (string) > > linux.hotplug_type = 1 (0x1) (int) > > pci.subsys_product = 'Unknown (0x2711)' (string) > > pci.subsys_vendor = 'Intel Corporation' (string) > > info.product = 'PRO/Wireless 2200BG Network Connection' (string) > > pci.product = 'PRO/Wireless 2200BG Network Connection' (string) > > info.vendor = 'Intel Corporation' (string) > > pci.vendor = 'Intel Corporation' (string) > > pci.device_protocol = 0 (0x0) (int) > > pci.device_subclass = 128 (0x80) (int) > > pci.device_class = 2 (0x2) (int) > > pci.subsys_vendor_id = 32902 (0x8086) (int) > > pci.subsys_product_id = 10001 (0x2711) (int) > > pci.vendor_id = 32902 (0x8086) (int) > > pci.product_id = 16928 (0x4220) (int) > > info.linux.driver = 'ipw2200' (string) > > pci.linux.sysfs_path = > > '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) > > info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) > > info.bus = 'pci' (string) > > linux.sysfs_path_device = > > '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) > > linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' > > (string) > > > > Will let you know when my bisecting finds a happy one. > > Here's a happy one: > > udi = '/org/freedesktop/Hal/devices/pci_8086_4220' > info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) > linux.subsystem = 'pci' (string) > linux.hotplug_type = 1 (0x1) (int) > pci.subsys_product = 'Unknown (0x2711)' (string) > pci.subsys_vendor = 'Intel Corporation' (string) > info.product = 'PRO/Wireless 2200BG Network Connection' (string) > pci.product = 'PRO/Wireless 2200BG Network Connection' (string) > info.vendor = 'Intel Corporation' (string) > pci.vendor = 'Intel Corporation' (string) > pci.device_protocol = 0 (0x0) (int) > pci.device_subclass = 128 (0x80) (int) > pci.device_class = 2 (0x2) (int) > pci.subsys_vendor_id = 32902 (0x8086) (int) > pci.subsys_product_id = 10001 (0x2711) (int) > pci.vendor_id = 32902 (0x8086) (int) > pci.product_id = 16928 (0x4220) (int) > info.linux.driver = 'ipw2200' (string) > pci.linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' > (string) > info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) > info.bus = 'pci' (string) > linux.sysfs_path_device = > '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) > linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' > (string) > > Look the same to me. > > So far I'm down to: > > patch 56: good > patch 113: bad > > 56 powerpc-ps3-use-__maybe_unused.patch > 57 do-not-select-macintosh-drivers-by-default.patch > 58 powerpc-promc-remove-undef-printk.patch > 59 powerpc-fix-kconfig-select-warning-with-ucc_fast.patch > 60 8xx-mpc885ads-pcmcia-support.patch > 61 8xx-mpc885ads-pcmcia-support-fix.patch > 62 8xx-fix-whitespace-and-indentation.patch > 63 dts-kill-hardcoded-phandles.patch > 64 gregkh-driver-debugfs-add-rename-for-debugfs-files.patch > 65 > gregkh-driver-update-documentation-driver-model-platformtxt.patch > 66 > gregkh-driver-driver-core-keep-physdev-for-old-struct-class_device.patch > 67 gregkh-driver-driver-core-kill-unused-code.patch > 68 gregkh-driver-howto-removing-duplicated-entry.patch > 69 gregkh-driver-dmi-based-module-autoloading.patch > 70 gregkh-driver-uio.patch > 71 gregkh-driver-uio-documentation.patch > 72 gregkh-driver-uio-hilscher-cif-card-driver.patch > 73
Re: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
Herbert Xu wrote: On Fri, May 25, 2007 at 11:04:04PM +1000, Herbert Xu wrote: [E1000]: Call netif_poll_enable in e1000_open Here is a better one. [E1000]: Restore netif_poll_enable call but make sure IRQs are off This restores the previously removed netif_poll_enable call in e1000_open. It's needed on all but the first call to e1000_open for a NIC as e1000_close always calls netif_poll_disable. netif_poll_enable can only be called safely if no polls have been scheduled. This should be the case as long as we don't enter our IRQ handler. In order to guarantee this we explicitly disable IRQs as early as possible when we're probing the NIC. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Ack! this also fixes all the issues we had seen ourselves. I took a bit of time to get our labs to test it. Who can pick this patch up for us? Jeff ? Auke - 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: idle=poll burns my box [was Re: 2.6.22-rc2-mm1]
On Fri, 25 May 2007 23:20:25 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > Is idle=poll a quick and dirty way to burn your box in flames ? yep ;) It makes the CPU(s) busy-wait when they have nothing else to do. It was originally added as a thing to maybe save a few cycles of latency in responding to interrupts. It's now useful as a trick to prevent oprofile from producing confusing numbers. I don't think it has any other uses. - 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/
idle=poll burns my box [was Re: 2.6.22-rc2-mm1]
On Wed, 23 May 2007 00:42:33 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ > Don't know if it's specific to this kernel, but as I have realized it now... I booted with idle=poll to check some issues (with nvidia driver, btw). And suddenly I noticed my box was running near 80ºC hot. I pulled out the lid, an try to see what happened. In short, idle=poll rises the temperature about 20ºC. I have an ASUS PC-DL mobo, with a couple Xeon Northwood with HypertThreading at 2.4 GHz, for a total of 4 threads. If I boot the box with idle=poll, and let it doing _nothing_ but staring at the gnome desktop, I get this temperatures: (Time,VRM,CPU0,CPU1) (wihtout the side cover, remember...) 15:46 64 56 54 15:55 70 60 56 16:02 71 62 57 If I reboot without idle=poll, the box colds quickly: 16:07 58 52 48 16:12 50 43 42 16:15 49 42 41 I I put the box to do some multithreaded render, so all four cores stay above 98% usage, the box warms again: 16:17 51 43 42 16:24 67 57 54 16:28 70 60 56 16:30 72 61 57 16:37 72 61 56 And as soon as I stop the work, it colds again: 16:41 71 60 56 16:42 64 56 52 16:43 60 54 50 16:45 55 48 46 16:46 53 46 44 Left alone for awhile, it stays at 46 39 39 (for VRM and both CPUs, as I said). Is idle=poll a quick and dirty way to burn your box in flames ? To warm your cpu doing nothing ? Summer is coming, but this... Any ideas ? -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam03 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - 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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, 25 May 2007 11:36:22 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote: > 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't > matter. Bringing up the interface manually still works, so I suspect > this is sysfs or HAL related again. Again, Debian unstable so > userspace is quite up-to-date. > Are you renaming network devices? Using /etc/iftab seems to confuse NM (maybe a HAL problem). -- Stephen Hemminger <[EMAIL PROTECTED]> - 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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, May 25, 2007 at 12:53:19PM -0500, Matt Mackall wrote: > On Fri, May 25, 2007 at 07:37:46PM +0200, Kay Sievers wrote: > > On 5/25/07, Greg KH <[EMAIL PROTECTED]> wrote: > > >On Fri, May 25, 2007 at 11:36:22AM -0500, Matt Mackall wrote: > > >> 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't > > >> matter. Bringing up the interface manually still works, so I suspect > > >> this is sysfs or HAL related again. Again, Debian unstable so > > >> userspace is quite up-to-date. > > > > > >I don't have any driver model changes that affect network devices in my > > >tree. Could you go through and bisect the -mm tree to see if you can > > >find the patch that causes this? > > > > Does it work, when you unload and load the kernel module? > > rmmod followed by insmod had no effect. > > > Does it work when you restart HAL and then NetworkManager? > > I restarted dbus, which stopped and restarted HAL and NM. No effect. > > > Can you compare the sections for the wireless card in the output of "lshal"? > > The unhappy one looks like this: > > udi = '/org/freedesktop/Hal/devices/pci_8086_4220' > info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) > linux.subsystem = 'pci' (string) > linux.hotplug_type = 1 (0x1) (int) > pci.subsys_product = 'Unknown (0x2711)' (string) > pci.subsys_vendor = 'Intel Corporation' (string) > info.product = 'PRO/Wireless 2200BG Network Connection' (string) > pci.product = 'PRO/Wireless 2200BG Network Connection' (string) > info.vendor = 'Intel Corporation' (string) > pci.vendor = 'Intel Corporation' (string) > pci.device_protocol = 0 (0x0) (int) > pci.device_subclass = 128 (0x80) (int) > pci.device_class = 2 (0x2) (int) > pci.subsys_vendor_id = 32902 (0x8086) (int) > pci.subsys_product_id = 10001 (0x2711) (int) > pci.vendor_id = 32902 (0x8086) (int) > pci.product_id = 16928 (0x4220) (int) > info.linux.driver = 'ipw2200' (string) > pci.linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' > (string) > info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) > info.bus = 'pci' (string) > linux.sysfs_path_device = > '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) > linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' > (string) > > Will let you know when my bisecting finds a happy one. Here's a happy one: udi = '/org/freedesktop/Hal/devices/pci_8086_4220' info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) linux.subsystem = 'pci' (string) linux.hotplug_type = 1 (0x1) (int) pci.subsys_product = 'Unknown (0x2711)' (string) pci.subsys_vendor = 'Intel Corporation' (string) info.product = 'PRO/Wireless 2200BG Network Connection' (string) pci.product = 'PRO/Wireless 2200BG Network Connection' (string) info.vendor = 'Intel Corporation' (string) pci.vendor = 'Intel Corporation' (string) pci.device_protocol = 0 (0x0) (int) pci.device_subclass = 128 (0x80) (int) pci.device_class = 2 (0x2) (int) pci.subsys_vendor_id = 32902 (0x8086) (int) pci.subsys_product_id = 10001 (0x2711) (int) pci.vendor_id = 32902 (0x8086) (int) pci.product_id = 16928 (0x4220) (int) info.linux.driver = 'ipw2200' (string) pci.linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) info.bus = 'pci' (string) linux.sysfs_path_device = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) Look the same to me. So far I'm down to: patch 56: good patch 113: bad 56 powerpc-ps3-use-__maybe_unused.patch 57 do-not-select-macintosh-drivers-by-default.patch 58 powerpc-promc-remove-undef-printk.patch 59 powerpc-fix-kconfig-select-warning-with-ucc_fast.patch 60 8xx-mpc885ads-pcmcia-support.patch 61 8xx-mpc885ads-pcmcia-support-fix.patch 62 8xx-fix-whitespace-and-indentation.patch 63 dts-kill-hardcoded-phandles.patch 64 gregkh-driver-debugfs-add-rename-for-debugfs-files.patch 65 gregkh-driver-update-documentation-driver-model-platformtxt.patch 66 gregkh-driver-driver-core-keep-physdev-for-old-struct-class_device.patch 67 gregkh-driver-driver-core-kill-unused-code.patch 68 gregkh-driver-howto-removing-duplicated-entry.patch 69 gregkh-driver-dmi-based-module-autoloading.patch 70 gregkh-driver-uio.patch 71 gregkh-driver-uio-documentation.patch 72 gregkh-driver-uio-hilscher-cif-card-driver.patch 73 gregkh-driver-idr-fix-obscure-bug-in-allocation-path.patch 74 gregkh-driver-idr-separate-out-idr_mark_full.patch 75 gregkh-driver-ida-implement-idr-based-id-allocator.patch 76 gregkh-driver-sysfs-move-release_sysfs_dirent-to-dirc.patch 77 gregkh-driver-sysfs-allocate-inode-number-using-ida.patch
Re: 2.6.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, May 25, 2007 at 07:37:46PM +0200, Kay Sievers wrote: > On 5/25/07, Greg KH <[EMAIL PROTECTED]> wrote: > >On Fri, May 25, 2007 at 11:36:22AM -0500, Matt Mackall wrote: > >> 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't > >> matter. Bringing up the interface manually still works, so I suspect > >> this is sysfs or HAL related again. Again, Debian unstable so > >> userspace is quite up-to-date. > > > >I don't have any driver model changes that affect network devices in my > >tree. Could you go through and bisect the -mm tree to see if you can > >find the patch that causes this? > > Does it work, when you unload and load the kernel module? rmmod followed by insmod had no effect. > Does it work when you restart HAL and then NetworkManager? I restarted dbus, which stopped and restarted HAL and NM. No effect. > Can you compare the sections for the wireless card in the output of "lshal"? The unhappy one looks like this: udi = '/org/freedesktop/Hal/devices/pci_8086_4220' info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) linux.subsystem = 'pci' (string) linux.hotplug_type = 1 (0x1) (int) pci.subsys_product = 'Unknown (0x2711)' (string) pci.subsys_vendor = 'Intel Corporation' (string) info.product = 'PRO/Wireless 2200BG Network Connection' (string) pci.product = 'PRO/Wireless 2200BG Network Connection' (string) info.vendor = 'Intel Corporation' (string) pci.vendor = 'Intel Corporation' (string) pci.device_protocol = 0 (0x0) (int) pci.device_subclass = 128 (0x80) (int) pci.device_class = 2 (0x2) (int) pci.subsys_vendor_id = 32902 (0x8086) (int) pci.subsys_product_id = 10001 (0x2711) (int) pci.vendor_id = 32902 (0x8086) (int) pci.product_id = 16928 (0x4220) (int) info.linux.driver = 'ipw2200' (string) pci.linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) info.bus = 'pci' (string) linux.sysfs_path_device = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) Will let you know when my bisecting finds a happy one. -- Mathematics is the supreme nostalgia of our time. - 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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On 5/25/07, Greg KH <[EMAIL PROTECTED]> wrote: On Fri, May 25, 2007 at 11:36:22AM -0500, Matt Mackall wrote: > 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't > matter. Bringing up the interface manually still works, so I suspect > this is sysfs or HAL related again. Again, Debian unstable so > userspace is quite up-to-date. I don't have any driver model changes that affect network devices in my tree. Could you go through and bisect the -mm tree to see if you can find the patch that causes this? Does it work, when you unload and load the kernel module? Does it work when you restart HAL and then NetworkManager? Can you compare the sections for the wireless card in the output of "lshal"? Kay - 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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, May 25, 2007 at 11:36:22AM -0500, Matt Mackall wrote: > 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't > matter. Bringing up the interface manually still works, so I suspect > this is sysfs or HAL related again. Again, Debian unstable so > userspace is quite up-to-date. I don't have any driver model changes that affect network devices in my tree. Could you go through and bisect the -mm tree to see if you can find the patch that causes this? thanks, greg k-h - 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: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
On Fri, May 25, 2007 at 11:04:04PM +1000, Herbert Xu wrote:
>
> [E1000]: Call netif_poll_enable in e1000_open
Here is a better one.
[E1000]: Restore netif_poll_enable call but make sure IRQs are off
This restores the previously removed netif_poll_enable call in
e1000_open. It's needed on all but the first call to e1000_open
for a NIC as e1000_close always calls netif_poll_disable.
netif_poll_enable can only be called safely if no polls have been
scheduled. This should be the case as long as we don't enter our
IRQ handler.
In order to guarantee this we explicitly disable IRQs as early
as possible when we're probing the NIC.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index cbc7feb..9ec35b7 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1325,7 +1325,10 @@ e1000_sw_init(struct e1000_adapter *adapter)
spin_lock_init(>tx_queue_lock);
#endif
- atomic_set(>irq_sem, 1);
+ /* Explicitly disable IRQ since the NIC can be in any state. */
+ atomic_set(>irq_sem, 0);
+ e1000_irq_disable(adapter);
+
spin_lock_init(>stats_lock);
set_bit(__E1000_DOWN, >flags);
@@ -1431,6 +1434,10 @@ e1000_open(struct net_device *netdev)
/* From here on the code is the same as e1000_up() */
clear_bit(__E1000_DOWN, >flags);
+#ifdef CONFIG_E1000_NAPI
+ netif_poll_enable(netdev);
+#endif
+
e1000_irq_enable(adapter);
/* fire a link status change interrupt to start the watchdog */
-
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: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
On Fri, May 25, 2007 at 10:54:13PM +1000, Herbert Xu wrote:
>
> So please revert my patch.
>
> We need to find out why we're getting IRQs before calling
> e1000_irq_enable in e1000_open.
In the mean time this should be a safe fix. This is against
the current mainline tree.
[E1000]: Call netif_poll_enable in e1000_open
This restores the previously removed netif_poll_enable call in
e1000_open. It's needed on all but the first call to e1000_open
for a NIC as e1000_close always calls netif_poll_disable.
netif_poll_enable can only be called safely if no polls have been
scheduled. This should be the case as long as we don't enter our
IRQ handler. Just in case someone has left IRQs enabled, we call
this before the IRQ handler is installed.
Of course we should really make sure that IRQs are disabled as
early as possible, i.e., when we're still in the probe routine.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index cbc7feb..d91a378 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1424,6 +1424,10 @@ e1000_open(struct net_device *netdev)
* clean_rx handler before we do so. */
e1000_configure(adapter);
+#ifdef CONFIG_E1000_NAPI
+ netif_poll_enable(netdev);
+#endif
+
err = e1000_request_irq(adapter);
if (err)
goto err_req_irq;
-
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: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
On Thu, May 24, 2007 at 07:44:29AM -0700, Kok, Auke wrote:
>
> I get the feeling that a recent change exposed us to this, our lab has been
> seeing similar OOPS's yesterday out of nothing.
Yep you're right. It was the change where we removed the
netif_poll_enable call from e1000_open. The problem is that
e1000_close calls e1000_down which in turn calls netif_poll_disable.
That means the next e1000_open won't reenable polling and the
dev_close (or in fact any call to netif_poll_disable) after that
will hang.
In fact my original premise is completely wrong since netif_poll_enable
can be safely called from dev_open *if* you can guarantee that no polls
have already been scheduled.
This should be the case as long as we keep IRQs disabled before
netif_poll_enable. So the problem is that somehow we're getting
into e1000_open with IRQs enabled on the NIC which then causes a
poll to be scheduled before the call to netif_poll_enable.
So please revert my patch.
We need to find out why we're getting IRQs before calling
e1000_irq_enable in e1000_open.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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.22-rc2-mm1
On Thu, 24 May 2007, Zan Lynx wrote: > [snip] > > Do you please have any indication which kernel versions were OK with the > > same .config, with respect to the USB mouse/keyboard hogs you are seeing > > with 2.6.22-rc2-mm1? > The last 2.6.21 -mm kernel worked well. [...] > drivers/hid/usbhid/hid-core.c: input irq status -75 received Zan, this has been reported also in bugzilla, so it's now handled in http://bugzilla.kernel.org/show_bug.cgi?id=8535 It's reported there that mainline is OK, and there are realy very few patches in the HID area which I can't imagine how they could be causing it, they are only a few simple quirks for a specific hardware. Could you please try the following things in this order: - disable CONFIG_HIDRAW and test whether it is still reproducible - revert git-hid.patch and test whether it is still reproducible - if so, I am afraid that it's some USB patch that is causing this, so bisecting would be needed I will meanwhile try to reproduce it myself here, but I have not been successful with it so far. Thanks, -- Jiri Kosina - 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.22-rc2-mm1 NTFS & SLUB related fix
On Fri, 25 May 2007 07:10:38 + "young dave" <[EMAIL PROTECTED]> wrote: > Hi, > I'm very sorry, andrew, you are right. > I directly modified the source and forgot remove the line ni->name[i] = 0; > Phew ;) Thanks for checking. - 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.22-rc2-mm1 NTFS & SLUB related fix
Hi, I'm very sorry, andrew, you are right. I directly modified the source and forgot remove the line ni->name[i] = 0; Regards dave - 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.22-rc2-mm1 NTFS & SLUB related fix
On Fri, 25 May 2007 06:48:34 + "young dave" <[EMAIL PROTECTED]> wrote: > Yes, I'm sure. but the patch in top post of mine works, the diffrence > is using kzalloc and remove the "ni->name[i] = 0;" line. > Let's walk through the existing code: i = na->name_len * sizeof(ntfschar); now, i = na->name_len * 2 ni->name = kmalloc(i + sizeof(ntfschar), GFP_ATOMIC); we allocated (na->name_len * 2 + 2) bytes if (!ni->name) return -ENOMEM; memcpy(ni->name, na->name, i); we copied (na->name_len * 2) bytes ni->name[i] = 0; here, we zero the two bytes at byte offsets ((na->name_len * 2) * 2) and ((na->name_len * 2) * 2 + 1), and that is the bug. We _want_ to zero the two bytes at byte offsets (na->name_len * 2) and (na->name_len * 2 + 1), which we can do in C via ni->name[na->name_len] = 0; because sizeof(*(ni->name)) == 2. So I'm still suspecting that you mistested that change. - 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.22-rc2-mm1 NTFS & SLUB related fix
Yes, I'm sure. but the patch in top post of mine works, the diffrence is using kzalloc and remove the "ni->name[i] = 0;" line. Regards dave - 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.22-rc2-mm1 NTFS & SLUB related fix
On Fri, 25 May 2007 06:27:51 + "young dave" <[EMAIL PROTECTED]> wrote: > Hi Andrew, > > > So I think this was meant: > > > > --- a/fs/ntfs/inode.c~a > > +++ a/fs/ntfs/inode.c > > @@ -140,7 +140,7 @@ static int ntfs_init_locked_inode(struct > > if (!ni->name) > > return -ENOMEM; > > memcpy(ni->name, na->name, i); > > - ni->name[i] = 0; > > + ni->name[na->name_len] = 0; > > } > > return 0; > > } > > _ > > > > I tested it , it doesn't work. Surprised. Are you really sure that you had the patch applied, and that you tested the right kernel, etc? - 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.22-rc2-mm1 NTFS & SLUB related fix
Hi Andrew, So I think this was meant: --- a/fs/ntfs/inode.c~a +++ a/fs/ntfs/inode.c @@ -140,7 +140,7 @@ static int ntfs_init_locked_inode(struct if (!ni->name) return -ENOMEM; memcpy(ni->name, na->name, i); - ni->name[i] = 0; + ni->name[na->name_len] = 0; } return 0; } _ I tested it , it doesn't work. - 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.22-rc2-mm1 NTFS SLUB related fix
Hi Andrew, So I think this was meant: --- a/fs/ntfs/inode.c~a +++ a/fs/ntfs/inode.c @@ -140,7 +140,7 @@ static int ntfs_init_locked_inode(struct if (!ni-name) return -ENOMEM; memcpy(ni-name, na-name, i); - ni-name[i] = 0; + ni-name[na-name_len] = 0; } return 0; } _ I tested it , it doesn't work. - 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.22-rc2-mm1 NTFS SLUB related fix
On Fri, 25 May 2007 06:27:51 + young dave [EMAIL PROTECTED] wrote: Hi Andrew, So I think this was meant: --- a/fs/ntfs/inode.c~a +++ a/fs/ntfs/inode.c @@ -140,7 +140,7 @@ static int ntfs_init_locked_inode(struct if (!ni-name) return -ENOMEM; memcpy(ni-name, na-name, i); - ni-name[i] = 0; + ni-name[na-name_len] = 0; } return 0; } _ I tested it , it doesn't work. Surprised. Are you really sure that you had the patch applied, and that you tested the right kernel, etc? - 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.22-rc2-mm1 NTFS SLUB related fix
Yes, I'm sure. but the patch in top post of mine works, the diffrence is using kzalloc and remove the ni-name[i] = 0; line. Regards dave - 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.22-rc2-mm1 NTFS SLUB related fix
On Fri, 25 May 2007 06:48:34 + young dave [EMAIL PROTECTED] wrote: Yes, I'm sure. but the patch in top post of mine works, the diffrence is using kzalloc and remove the ni-name[i] = 0; line. Let's walk through the existing code: i = na-name_len * sizeof(ntfschar); now, i = na-name_len * 2 ni-name = kmalloc(i + sizeof(ntfschar), GFP_ATOMIC); we allocated (na-name_len * 2 + 2) bytes if (!ni-name) return -ENOMEM; memcpy(ni-name, na-name, i); we copied (na-name_len * 2) bytes ni-name[i] = 0; here, we zero the two bytes at byte offsets ((na-name_len * 2) * 2) and ((na-name_len * 2) * 2 + 1), and that is the bug. We _want_ to zero the two bytes at byte offsets (na-name_len * 2) and (na-name_len * 2 + 1), which we can do in C via ni-name[na-name_len] = 0; because sizeof(*(ni-name)) == 2. So I'm still suspecting that you mistested that change. - 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.22-rc2-mm1 NTFS SLUB related fix
Hi, I'm very sorry, andrew, you are right. I directly modified the source and forgot remove the line ni-name[i] = 0; Regards dave - 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.22-rc2-mm1 NTFS SLUB related fix
On Fri, 25 May 2007 07:10:38 + young dave [EMAIL PROTECTED] wrote: Hi, I'm very sorry, andrew, you are right. I directly modified the source and forgot remove the line ni-name[i] = 0; Phew ;) Thanks for checking. - 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.22-rc2-mm1
On Thu, 24 May 2007, Zan Lynx wrote: [snip] Do you please have any indication which kernel versions were OK with the same .config, with respect to the USB mouse/keyboard hogs you are seeing with 2.6.22-rc2-mm1? The last 2.6.21 -mm kernel worked well. [...] drivers/hid/usbhid/hid-core.c: input irq status -75 received Zan, this has been reported also in bugzilla, so it's now handled in http://bugzilla.kernel.org/show_bug.cgi?id=8535 It's reported there that mainline is OK, and there are realy very few patches in the HID area which I can't imagine how they could be causing it, they are only a few simple quirks for a specific hardware. Could you please try the following things in this order: - disable CONFIG_HIDRAW and test whether it is still reproducible - revert git-hid.patch and test whether it is still reproducible - if so, I am afraid that it's some USB patch that is causing this, so bisecting would be needed I will meanwhile try to reproduce it myself here, but I have not been successful with it so far. Thanks, -- Jiri Kosina - 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: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
On Thu, May 24, 2007 at 07:44:29AM -0700, Kok, Auke wrote:
I get the feeling that a recent change exposed us to this, our lab has been
seeing similar OOPS's yesterday out of nothing.
Yep you're right. It was the change where we removed the
netif_poll_enable call from e1000_open. The problem is that
e1000_close calls e1000_down which in turn calls netif_poll_disable.
That means the next e1000_open won't reenable polling and the
dev_close (or in fact any call to netif_poll_disable) after that
will hang.
In fact my original premise is completely wrong since netif_poll_enable
can be safely called from dev_open *if* you can guarantee that no polls
have already been scheduled.
This should be the case as long as we keep IRQs disabled before
netif_poll_enable. So the problem is that somehow we're getting
into e1000_open with IRQs enabled on the NIC which then causes a
poll to be scheduled before the call to netif_poll_enable.
So please revert my patch.
We need to find out why we're getting IRQs before calling
e1000_irq_enable in e1000_open.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
On Fri, May 25, 2007 at 10:54:13PM +1000, Herbert Xu wrote:
So please revert my patch.
We need to find out why we're getting IRQs before calling
e1000_irq_enable in e1000_open.
In the mean time this should be a safe fix. This is against
the current mainline tree.
[E1000]: Call netif_poll_enable in e1000_open
This restores the previously removed netif_poll_enable call in
e1000_open. It's needed on all but the first call to e1000_open
for a NIC as e1000_close always calls netif_poll_disable.
netif_poll_enable can only be called safely if no polls have been
scheduled. This should be the case as long as we don't enter our
IRQ handler. Just in case someone has left IRQs enabled, we call
this before the IRQ handler is installed.
Of course we should really make sure that IRQs are disabled as
early as possible, i.e., when we're still in the probe routine.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index cbc7feb..d91a378 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1424,6 +1424,10 @@ e1000_open(struct net_device *netdev)
* clean_rx handler before we do so. */
e1000_configure(adapter);
+#ifdef CONFIG_E1000_NAPI
+ netif_poll_enable(netdev);
+#endif
+
err = e1000_request_irq(adapter);
if (err)
goto err_req_irq;
-
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: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
On Fri, May 25, 2007 at 11:04:04PM +1000, Herbert Xu wrote:
[E1000]: Call netif_poll_enable in e1000_open
Here is a better one.
[E1000]: Restore netif_poll_enable call but make sure IRQs are off
This restores the previously removed netif_poll_enable call in
e1000_open. It's needed on all but the first call to e1000_open
for a NIC as e1000_close always calls netif_poll_disable.
netif_poll_enable can only be called safely if no polls have been
scheduled. This should be the case as long as we don't enter our
IRQ handler.
In order to guarantee this we explicitly disable IRQs as early
as possible when we're probing the NIC.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index cbc7feb..9ec35b7 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1325,7 +1325,10 @@ e1000_sw_init(struct e1000_adapter *adapter)
spin_lock_init(adapter-tx_queue_lock);
#endif
- atomic_set(adapter-irq_sem, 1);
+ /* Explicitly disable IRQ since the NIC can be in any state. */
+ atomic_set(adapter-irq_sem, 0);
+ e1000_irq_disable(adapter);
+
spin_lock_init(adapter-stats_lock);
set_bit(__E1000_DOWN, adapter-flags);
@@ -1431,6 +1434,10 @@ e1000_open(struct net_device *netdev)
/* From here on the code is the same as e1000_up() */
clear_bit(__E1000_DOWN, adapter-flags);
+#ifdef CONFIG_E1000_NAPI
+ netif_poll_enable(netdev);
+#endif
+
e1000_irq_enable(adapter);
/* fire a link status change interrupt to start the watchdog */
-
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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, May 25, 2007 at 11:36:22AM -0500, Matt Mackall wrote: 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't matter. Bringing up the interface manually still works, so I suspect this is sysfs or HAL related again. Again, Debian unstable so userspace is quite up-to-date. I don't have any driver model changes that affect network devices in my tree. Could you go through and bisect the -mm tree to see if you can find the patch that causes this? thanks, greg k-h - 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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On 5/25/07, Greg KH [EMAIL PROTECTED] wrote: On Fri, May 25, 2007 at 11:36:22AM -0500, Matt Mackall wrote: 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't matter. Bringing up the interface manually still works, so I suspect this is sysfs or HAL related again. Again, Debian unstable so userspace is quite up-to-date. I don't have any driver model changes that affect network devices in my tree. Could you go through and bisect the -mm tree to see if you can find the patch that causes this? Does it work, when you unload and load the kernel module? Does it work when you restart HAL and then NetworkManager? Can you compare the sections for the wireless card in the output of lshal? Kay - 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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, May 25, 2007 at 07:37:46PM +0200, Kay Sievers wrote: On 5/25/07, Greg KH [EMAIL PROTECTED] wrote: On Fri, May 25, 2007 at 11:36:22AM -0500, Matt Mackall wrote: 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't matter. Bringing up the interface manually still works, so I suspect this is sysfs or HAL related again. Again, Debian unstable so userspace is quite up-to-date. I don't have any driver model changes that affect network devices in my tree. Could you go through and bisect the -mm tree to see if you can find the patch that causes this? Does it work, when you unload and load the kernel module? rmmod followed by insmod had no effect. Does it work when you restart HAL and then NetworkManager? I restarted dbus, which stopped and restarted HAL and NM. No effect. Can you compare the sections for the wireless card in the output of lshal? The unhappy one looks like this: udi = '/org/freedesktop/Hal/devices/pci_8086_4220' info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) linux.subsystem = 'pci' (string) linux.hotplug_type = 1 (0x1) (int) pci.subsys_product = 'Unknown (0x2711)' (string) pci.subsys_vendor = 'Intel Corporation' (string) info.product = 'PRO/Wireless 2200BG Network Connection' (string) pci.product = 'PRO/Wireless 2200BG Network Connection' (string) info.vendor = 'Intel Corporation' (string) pci.vendor = 'Intel Corporation' (string) pci.device_protocol = 0 (0x0) (int) pci.device_subclass = 128 (0x80) (int) pci.device_class = 2 (0x2) (int) pci.subsys_vendor_id = 32902 (0x8086) (int) pci.subsys_product_id = 10001 (0x2711) (int) pci.vendor_id = 32902 (0x8086) (int) pci.product_id = 16928 (0x4220) (int) info.linux.driver = 'ipw2200' (string) pci.linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) info.bus = 'pci' (string) linux.sysfs_path_device = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) Will let you know when my bisecting finds a happy one. -- Mathematics is the supreme nostalgia of our time. - 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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, May 25, 2007 at 12:53:19PM -0500, Matt Mackall wrote: On Fri, May 25, 2007 at 07:37:46PM +0200, Kay Sievers wrote: On 5/25/07, Greg KH [EMAIL PROTECTED] wrote: On Fri, May 25, 2007 at 11:36:22AM -0500, Matt Mackall wrote: 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't matter. Bringing up the interface manually still works, so I suspect this is sysfs or HAL related again. Again, Debian unstable so userspace is quite up-to-date. I don't have any driver model changes that affect network devices in my tree. Could you go through and bisect the -mm tree to see if you can find the patch that causes this? Does it work, when you unload and load the kernel module? rmmod followed by insmod had no effect. Does it work when you restart HAL and then NetworkManager? I restarted dbus, which stopped and restarted HAL and NM. No effect. Can you compare the sections for the wireless card in the output of lshal? The unhappy one looks like this: udi = '/org/freedesktop/Hal/devices/pci_8086_4220' info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) linux.subsystem = 'pci' (string) linux.hotplug_type = 1 (0x1) (int) pci.subsys_product = 'Unknown (0x2711)' (string) pci.subsys_vendor = 'Intel Corporation' (string) info.product = 'PRO/Wireless 2200BG Network Connection' (string) pci.product = 'PRO/Wireless 2200BG Network Connection' (string) info.vendor = 'Intel Corporation' (string) pci.vendor = 'Intel Corporation' (string) pci.device_protocol = 0 (0x0) (int) pci.device_subclass = 128 (0x80) (int) pci.device_class = 2 (0x2) (int) pci.subsys_vendor_id = 32902 (0x8086) (int) pci.subsys_product_id = 10001 (0x2711) (int) pci.vendor_id = 32902 (0x8086) (int) pci.product_id = 16928 (0x4220) (int) info.linux.driver = 'ipw2200' (string) pci.linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) info.bus = 'pci' (string) linux.sysfs_path_device = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) Will let you know when my bisecting finds a happy one. Here's a happy one: udi = '/org/freedesktop/Hal/devices/pci_8086_4220' info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) linux.subsystem = 'pci' (string) linux.hotplug_type = 1 (0x1) (int) pci.subsys_product = 'Unknown (0x2711)' (string) pci.subsys_vendor = 'Intel Corporation' (string) info.product = 'PRO/Wireless 2200BG Network Connection' (string) pci.product = 'PRO/Wireless 2200BG Network Connection' (string) info.vendor = 'Intel Corporation' (string) pci.vendor = 'Intel Corporation' (string) pci.device_protocol = 0 (0x0) (int) pci.device_subclass = 128 (0x80) (int) pci.device_class = 2 (0x2) (int) pci.subsys_vendor_id = 32902 (0x8086) (int) pci.subsys_product_id = 10001 (0x2711) (int) pci.vendor_id = 32902 (0x8086) (int) pci.product_id = 16928 (0x4220) (int) info.linux.driver = 'ipw2200' (string) pci.linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) info.bus = 'pci' (string) linux.sysfs_path_device = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) Look the same to me. So far I'm down to: patch 56: good patch 113: bad 56 powerpc-ps3-use-__maybe_unused.patch 57 do-not-select-macintosh-drivers-by-default.patch 58 powerpc-promc-remove-undef-printk.patch 59 powerpc-fix-kconfig-select-warning-with-ucc_fast.patch 60 8xx-mpc885ads-pcmcia-support.patch 61 8xx-mpc885ads-pcmcia-support-fix.patch 62 8xx-fix-whitespace-and-indentation.patch 63 dts-kill-hardcoded-phandles.patch 64 gregkh-driver-debugfs-add-rename-for-debugfs-files.patch 65 gregkh-driver-update-documentation-driver-model-platformtxt.patch 66 gregkh-driver-driver-core-keep-physdev-for-old-struct-class_device.patch 67 gregkh-driver-driver-core-kill-unused-code.patch 68 gregkh-driver-howto-removing-duplicated-entry.patch 69 gregkh-driver-dmi-based-module-autoloading.patch 70 gregkh-driver-uio.patch 71 gregkh-driver-uio-documentation.patch 72 gregkh-driver-uio-hilscher-cif-card-driver.patch 73 gregkh-driver-idr-fix-obscure-bug-in-allocation-path.patch 74 gregkh-driver-idr-separate-out-idr_mark_full.patch 75 gregkh-driver-ida-implement-idr-based-id-allocator.patch 76 gregkh-driver-sysfs-move-release_sysfs_dirent-to-dirc.patch 77 gregkh-driver-sysfs-allocate-inode-number-using-ida.patch 78 gregkh-driver-sysfs-make-sysfs_put-ignore-null-sd.patch 79
Re: 2.6.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, 25 May 2007 11:36:22 -0500 Matt Mackall [EMAIL PROTECTED] wrote: 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't matter. Bringing up the interface manually still works, so I suspect this is sysfs or HAL related again. Again, Debian unstable so userspace is quite up-to-date. Are you renaming network devices? Using /etc/iftab seems to confuse NM (maybe a HAL problem). -- Stephen Hemminger [EMAIL PROTECTED] - 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/
idle=poll burns my box [was Re: 2.6.22-rc2-mm1]
On Wed, 23 May 2007 00:42:33 -0700, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ Don't know if it's specific to this kernel, but as I have realized it now... I booted with idle=poll to check some issues (with nvidia driver, btw). And suddenly I noticed my box was running near 80ºC hot. I pulled out the lid, an try to see what happened. In short, idle=poll rises the temperature about 20ºC. I have an ASUS PC-DL mobo, with a couple Xeon Northwood with HypertThreading at 2.4 GHz, for a total of 4 threads. If I boot the box with idle=poll, and let it doing _nothing_ but staring at the gnome desktop, I get this temperatures: (Time,VRM,CPU0,CPU1) (wihtout the side cover, remember...) 15:46 64 56 54 15:55 70 60 56 16:02 71 62 57 If I reboot without idle=poll, the box colds quickly: 16:07 58 52 48 16:12 50 43 42 16:15 49 42 41 I I put the box to do some multithreaded render, so all four cores stay above 98% usage, the box warms again: 16:17 51 43 42 16:24 67 57 54 16:28 70 60 56 16:30 72 61 57 16:37 72 61 56 And as soon as I stop the work, it colds again: 16:41 71 60 56 16:42 64 56 52 16:43 60 54 50 16:45 55 48 46 16:46 53 46 44 Left alone for awhile, it stays at 46 39 39 (for VRM and both CPUs, as I said). Is idle=poll a quick and dirty way to burn your box in flames ? To warm your cpu doing nothing ? Summer is coming, but this... Any ideas ? -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam03 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - 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: idle=poll burns my box [was Re: 2.6.22-rc2-mm1]
On Fri, 25 May 2007 23:20:25 +0200 J.A. Magallón [EMAIL PROTECTED] wrote: Is idle=poll a quick and dirty way to burn your box in flames ? yep ;) It makes the CPU(s) busy-wait when they have nothing else to do. It was originally added as a thing to maybe save a few cycles of latency in responding to interrupts. It's now useful as a trick to prevent oprofile from producing confusing numbers. I don't think it has any other uses. - 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: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
Herbert Xu wrote: On Fri, May 25, 2007 at 11:04:04PM +1000, Herbert Xu wrote: [E1000]: Call netif_poll_enable in e1000_open Here is a better one. [E1000]: Restore netif_poll_enable call but make sure IRQs are off This restores the previously removed netif_poll_enable call in e1000_open. It's needed on all but the first call to e1000_open for a NIC as e1000_close always calls netif_poll_disable. netif_poll_enable can only be called safely if no polls have been scheduled. This should be the case as long as we don't enter our IRQ handler. In order to guarantee this we explicitly disable IRQs as early as possible when we're probing the NIC. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Ack! this also fixes all the issues we had seen ourselves. I took a bit of time to get our labs to test it. Who can pick this patch up for us? Jeff ? Auke - 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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, May 25, 2007 at 04:01:52PM -0500, Matt Mackall wrote: On Fri, May 25, 2007 at 12:53:19PM -0500, Matt Mackall wrote: On Fri, May 25, 2007 at 07:37:46PM +0200, Kay Sievers wrote: On 5/25/07, Greg KH [EMAIL PROTECTED] wrote: On Fri, May 25, 2007 at 11:36:22AM -0500, Matt Mackall wrote: 2.6.22-rc2 works. CONFIG_SYSFS_DEPRECATED = y, though that shouldn't matter. Bringing up the interface manually still works, so I suspect this is sysfs or HAL related again. Again, Debian unstable so userspace is quite up-to-date. I don't have any driver model changes that affect network devices in my tree. Could you go through and bisect the -mm tree to see if you can find the patch that causes this? Does it work, when you unload and load the kernel module? rmmod followed by insmod had no effect. Does it work when you restart HAL and then NetworkManager? I restarted dbus, which stopped and restarted HAL and NM. No effect. Can you compare the sections for the wireless card in the output of lshal? The unhappy one looks like this: udi = '/org/freedesktop/Hal/devices/pci_8086_4220' info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) linux.subsystem = 'pci' (string) linux.hotplug_type = 1 (0x1) (int) pci.subsys_product = 'Unknown (0x2711)' (string) pci.subsys_vendor = 'Intel Corporation' (string) info.product = 'PRO/Wireless 2200BG Network Connection' (string) pci.product = 'PRO/Wireless 2200BG Network Connection' (string) info.vendor = 'Intel Corporation' (string) pci.vendor = 'Intel Corporation' (string) pci.device_protocol = 0 (0x0) (int) pci.device_subclass = 128 (0x80) (int) pci.device_class = 2 (0x2) (int) pci.subsys_vendor_id = 32902 (0x8086) (int) pci.subsys_product_id = 10001 (0x2711) (int) pci.vendor_id = 32902 (0x8086) (int) pci.product_id = 16928 (0x4220) (int) info.linux.driver = 'ipw2200' (string) pci.linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) info.bus = 'pci' (string) linux.sysfs_path_device = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) Will let you know when my bisecting finds a happy one. Here's a happy one: udi = '/org/freedesktop/Hal/devices/pci_8086_4220' info.udi = '/org/freedesktop/Hal/devices/pci_8086_4220' (string) linux.subsystem = 'pci' (string) linux.hotplug_type = 1 (0x1) (int) pci.subsys_product = 'Unknown (0x2711)' (string) pci.subsys_vendor = 'Intel Corporation' (string) info.product = 'PRO/Wireless 2200BG Network Connection' (string) pci.product = 'PRO/Wireless 2200BG Network Connection' (string) info.vendor = 'Intel Corporation' (string) pci.vendor = 'Intel Corporation' (string) pci.device_protocol = 0 (0x0) (int) pci.device_subclass = 128 (0x80) (int) pci.device_class = 2 (0x2) (int) pci.subsys_vendor_id = 32902 (0x8086) (int) pci.subsys_product_id = 10001 (0x2711) (int) pci.vendor_id = 32902 (0x8086) (int) pci.product_id = 16928 (0x4220) (int) info.linux.driver = 'ipw2200' (string) pci.linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) info.bus = 'pci' (string) linux.sysfs_path_device = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) linux.sysfs_path = '/sys/devices/pci:00/:00:1e.0/:02:02.0' (string) Look the same to me. So far I'm down to: patch 56: good patch 113: bad 56 powerpc-ps3-use-__maybe_unused.patch 57 do-not-select-macintosh-drivers-by-default.patch 58 powerpc-promc-remove-undef-printk.patch 59 powerpc-fix-kconfig-select-warning-with-ucc_fast.patch 60 8xx-mpc885ads-pcmcia-support.patch 61 8xx-mpc885ads-pcmcia-support-fix.patch 62 8xx-fix-whitespace-and-indentation.patch 63 dts-kill-hardcoded-phandles.patch 64 gregkh-driver-debugfs-add-rename-for-debugfs-files.patch 65 gregkh-driver-update-documentation-driver-model-platformtxt.patch 66 gregkh-driver-driver-core-keep-physdev-for-old-struct-class_device.patch 67 gregkh-driver-driver-core-kill-unused-code.patch 68 gregkh-driver-howto-removing-duplicated-entry.patch 69 gregkh-driver-dmi-based-module-autoloading.patch 70 gregkh-driver-uio.patch 71 gregkh-driver-uio-documentation.patch 72 gregkh-driver-uio-hilscher-cif-card-driver.patch 73 gregkh-driver-idr-fix-obscure-bug-in-allocation-path.patch 74 gregkh-driver-idr-separate-out-idr_mark_full.patch 75 gregkh-driver-ida-implement-idr-based-id-allocator.patch 76
Re: 2.6.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, May 25, 2007 at 06:01:09PM -0500, Matt Mackall wrote:
Bisect sequence went 56+ 84+ 98+ 105- 102- 100+ 101+. Looks like 102's
to blame:
driver-core-check-return-code-of-sysfs_create_link.patch
From: Cornelia Huck [EMAIL PROTECTED]
Check for return value of sysfs_create_link() in device_add() and
device_rename(). Add helper functions device_add_class_symlinks() and
device_remove_class_symlinks() to make the code easier to read.
{sigh}
This wouldn't be the first time this patch has broken things :(
Andrew, can you drop this from your tree?
Cornelia, can you rework this to not break things?
thanks,
greg k-h
-
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.22-rc2-mm1: NetworkManager fails to find ipw2200 again
On Fri, 2007-05-25 at 16:12 -0700, Greg KH wrote:
On Fri, May 25, 2007 at 06:01:09PM -0500, Matt Mackall wrote:
Bisect sequence went 56+ 84+ 98+ 105- 102- 100+ 101+. Looks like 102's
to blame:
driver-core-check-return-code-of-sysfs_create_link.patch
From: Cornelia Huck [EMAIL PROTECTED]
Check for return value of sysfs_create_link() in device_add() and
device_rename(). Add helper functions device_add_class_symlinks() and
device_remove_class_symlinks() to make the code easier to read.
{sigh}
This wouldn't be the first time this patch has broken things :(
Andrew, can you drop this from your tree?
Cornelia, can you rework this to not break things?
Before we continue that road, we should define the expected behavior for
the cleanup in error paths. Implementing that transaction-like model,
to rewind a the complete device-creation when something like a symlink
can't be created, may not always be the right thing to do.
I think in most cases, we just want to write something like that to the
error logs and continue, instead of letting a whole subsystem fail, or
in the worst case, prevent the box from booting up.
Thanks,
Kay
-
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: rmmod e1000 hangs (Was Re: 2.6.22-rc2-mm1)
Kok, Auke wrote: Herbert Xu wrote: On Fri, May 25, 2007 at 11:04:04PM +1000, Herbert Xu wrote: [E1000]: Call netif_poll_enable in e1000_open Here is a better one. [E1000]: Restore netif_poll_enable call but make sure IRQs are off This restores the previously removed netif_poll_enable call in e1000_open. It's needed on all but the first call to e1000_open for a NIC as e1000_close always calls netif_poll_disable. netif_poll_enable can only be called safely if no polls have been scheduled. This should be the case as long as we don't enter our IRQ handler. In order to guarantee this we explicitly disable IRQs as early as possible when we're probing the NIC. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Ack! this also fixes all the issues we had seen ourselves. I took a bit of time to get our labs to test it. Who can pick this patch up for us? Jeff ? Is this for -stable or upstream? I got confused with all the patches flying about. Send it to me, if it's for upstream. Jeff - 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/
