PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
Nope. I tried nolapic_timer and pressing keys when the system stops. Neither works for me. Mark - 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/
PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
Nope. I tried nolapic_timer and pressing keys when the system stops. Neither works for me. Mark - 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: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
On 07/20/2007 10:37 PM, Mark Tiefenbruck wrote: > I'd appreciate any help on getting this report sent to the appropriate > list and, of course, getting this fixed. I don't know what's useful, > so you're getting everything. This will be a very long e-mail. > > My new laptop won't boot with kernel versions 2.6.21 or 2.6.22 . No > oops. No panic. It just stops printing messages. Maybe it would > eventually continue if I wait long enough, but it's unacceptable > either way. I include below the contents of dmesg for a working kernel > up to the point where it halts. I'm also including what it usually > does for a few lines after that point. > Does it continue booting if you keep pressing the Ctrl key repeatedly? I have one that does, with kernel 2.6.23-rc1-git9 -- otherwise it just sits there indefinitely. As soon as I press a key it continues. This is even with 'nohz=off highres=off'. Using 'nolapic_timer' (by itself) fixes it, though. - 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: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
On 07/20/2007 10:37 PM, Mark Tiefenbruck wrote: I'd appreciate any help on getting this report sent to the appropriate list and, of course, getting this fixed. I don't know what's useful, so you're getting everything. This will be a very long e-mail. My new laptop won't boot with kernel versions 2.6.21 or 2.6.22 . No oops. No panic. It just stops printing messages. Maybe it would eventually continue if I wait long enough, but it's unacceptable either way. I include below the contents of dmesg for a working kernel up to the point where it halts. I'm also including what it usually does for a few lines after that point. Does it continue booting if you keep pressing the Ctrl key repeatedly? I have one that does, with kernel 2.6.23-rc1-git9 -- otherwise it just sits there indefinitely. As soon as I press a key it continues. This is even with 'nohz=off highres=off'. Using 'nolapic_timer' (by itself) fixes it, though. - 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: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
Can you please try the following command line options in any combination: hpet=disable nohz=off highres=off nolapic_timer I've now tried running the kernel with all combinations of hpet=disable, nolapic_timer, and clocksource=pm_timer|acpi_pm. I feel like hpet=disable was probably unnecessary, since I have HPET disabled in my BIOS. I didn't bother with nohz and highres=off, since I don't believe those options are present in the version of the kernel I'm testing. None of these made any difference, but I can try the rest of the combinations, if you think I should. Just to make sure, I should be placing these after the kernel path in grub.conf, right? I noticed during these tests that the cursor still blinks when it reaches the point where it stops printing things. This seems like good evidence that, indeed, the kernel is still active but is waiting for a response. Or maybe the hardware does that itself. I checked on what happens when I enable HPET in my BIOS. In the working kernel, it gets to the boot scripts and stops doing anything useful when letting udev process events. With the newer kernels, it halts in the same place as before. So, what next? I am of course willing to give out reasonable information about my system and try out patches. Mark - 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: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
On Sat, 2007-07-21 at 13:59 +0200, Ingo Molnar wrote: > * Mark Tiefenbruck <[EMAIL PROTECTED]> wrote: > > > IO window: disabled. > > MEM window: c020-c02f > > PREFETCH window: disabled. > > PCI: Bridge: :00:14.4 > > IO window: disabled. > > MEM window: c030-c03f > > PREFETCH window: disabled. > > PCI: Setting latency timer of device :00:05.0 to 64 > > PCI: Setting latency timer of device :00:06.0 to 64 > > NET: Registered protocol family 2 > > > > The next few lines are usually as follows, but recent kernels never > > get to them: > > thanks for the detailed report and bisection test! The above hang > strongly implicates some sort of high-res timers, dynticks or > clocksource problem. Most likely timer interrupts do not come as > expected, and the above place is one of the first spots where the kernel > waits for a (short) timeout - so you see it hang indefinitely. > > Besides the options Thomas suggested, you could also try > clocksource=pm_timer? Do you mean "clocksource=acpi_pm" ? Daniel - 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: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
* Mark Tiefenbruck <[EMAIL PROTECTED]> wrote: > IO window: disabled. > MEM window: c020-c02f > PREFETCH window: disabled. > PCI: Bridge: :00:14.4 > IO window: disabled. > MEM window: c030-c03f > PREFETCH window: disabled. > PCI: Setting latency timer of device :00:05.0 to 64 > PCI: Setting latency timer of device :00:06.0 to 64 > NET: Registered protocol family 2 > > The next few lines are usually as follows, but recent kernels never > get to them: thanks for the detailed report and bisection test! The above hang strongly implicates some sort of high-res timers, dynticks or clocksource problem. Most likely timer interrupts do not come as expected, and the above place is one of the first spots where the kernel waits for a (short) timeout - so you see it hang indefinitely. Besides the options Thomas suggested, you could also try clocksource=pm_timer? Ingo - 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: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
On Fri, 2007-07-20 at 19:37 -0700, Mark Tiefenbruck wrote: > My new laptop won't boot with kernel versions 2.6.21 or 2.6.22 . No > oops. No panic. It just stops printing messages. Maybe it would > eventually continue if I wait long enough, but it's unacceptable > either way. I include below the contents of dmesg for a working kernel > up to the point where it halts. I'm also including what it usually > does for a few lines after that point. Can you please try the following command line options in any combination: hpet=disable nohz=off highres=off nolapic_timer Thanks, tglx - 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: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
On Fri, 2007-07-20 at 19:37 -0700, Mark Tiefenbruck wrote: My new laptop won't boot with kernel versions 2.6.21 or 2.6.22 . No oops. No panic. It just stops printing messages. Maybe it would eventually continue if I wait long enough, but it's unacceptable either way. I include below the contents of dmesg for a working kernel up to the point where it halts. I'm also including what it usually does for a few lines after that point. Can you please try the following command line options in any combination: hpet=disable nohz=off highres=off nolapic_timer Thanks, tglx - 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: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
* Mark Tiefenbruck [EMAIL PROTECTED] wrote: IO window: disabled. MEM window: c020-c02f PREFETCH window: disabled. PCI: Bridge: :00:14.4 IO window: disabled. MEM window: c030-c03f PREFETCH window: disabled. PCI: Setting latency timer of device :00:05.0 to 64 PCI: Setting latency timer of device :00:06.0 to 64 NET: Registered protocol family 2 The next few lines are usually as follows, but recent kernels never get to them: thanks for the detailed report and bisection test! The above hang strongly implicates some sort of high-res timers, dynticks or clocksource problem. Most likely timer interrupts do not come as expected, and the above place is one of the first spots where the kernel waits for a (short) timeout - so you see it hang indefinitely. Besides the options Thomas suggested, you could also try clocksource=pm_timer? Ingo - 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: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
On Sat, 2007-07-21 at 13:59 +0200, Ingo Molnar wrote: * Mark Tiefenbruck [EMAIL PROTECTED] wrote: IO window: disabled. MEM window: c020-c02f PREFETCH window: disabled. PCI: Bridge: :00:14.4 IO window: disabled. MEM window: c030-c03f PREFETCH window: disabled. PCI: Setting latency timer of device :00:05.0 to 64 PCI: Setting latency timer of device :00:06.0 to 64 NET: Registered protocol family 2 The next few lines are usually as follows, but recent kernels never get to them: thanks for the detailed report and bisection test! The above hang strongly implicates some sort of high-res timers, dynticks or clocksource problem. Most likely timer interrupts do not come as expected, and the above place is one of the first spots where the kernel waits for a (short) timeout - so you see it hang indefinitely. Besides the options Thomas suggested, you could also try clocksource=pm_timer? Do you mean clocksource=acpi_pm ? Daniel - 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: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
Can you please try the following command line options in any combination: hpet=disable nohz=off highres=off nolapic_timer I've now tried running the kernel with all combinations of hpet=disable, nolapic_timer, and clocksource=pm_timer|acpi_pm. I feel like hpet=disable was probably unnecessary, since I have HPET disabled in my BIOS. I didn't bother with nohz and highres=off, since I don't believe those options are present in the version of the kernel I'm testing. None of these made any difference, but I can try the rest of the combinations, if you think I should. Just to make sure, I should be placing these after the kernel path in grub.conf, right? I noticed during these tests that the cursor still blinks when it reaches the point where it stops printing things. This seems like good evidence that, indeed, the kernel is still active but is waiting for a response. Or maybe the hardware does that itself. I checked on what happens when I enable HPET in my BIOS. In the working kernel, it gets to the boot scripts and stops doing anything useful when letting udev process events. With the newer kernels, it halts in the same place as before. So, what next? I am of course willing to give out reasonable information about my system and try out patches. Mark - 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: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
On 7/20/07, Mark Tiefenbruck <[EMAIL PROTECTED]> wrote: I'd appreciate any help on getting this report sent to the appropriate list and, of course, getting this fixed. I don't know what's useful, so you're getting everything. This will be a very long e-mail. My new laptop won't boot with kernel versions 2.6.21 or 2.6.22 . No oops. No panic. It just stops printing messages. Maybe it would eventually continue if I wait long enough, but it's unacceptable either way. I include below the contents of dmesg for a working kernel up to the point where it halts. I'm also including what it usually does for a few lines after that point. I did git-bisect on the 2.6.21.y tree. I'm including the result of that as well. It mentions HPET, so I should mention my computer also fails to boot when I enable HPET in my BIOS. I don't have the details of this currently; I can reproduce it again if needed. I've also included my kernel configuration and ver_linux output. You'll notice that my gcc version is 4.2.0, but this also happens with 4.1.2. I'm including /proc/cpuinfo and lspci -vvv. I'm including /proc/ioports and /proc/iomem. I don't have a /proc/scsi. Thanks, Mark Here's the commit that causes the problem: e9e2cdb412412326c4827fc78ba27f410d837e6e is first bad commit commit e9e2cdb412412326c4827fc78ba27f410d837e6e Author: Thomas Gleixner <[EMAIL PROTECTED]> Date: Fri Feb 16 01:28:04 2007 -0800 [PATCH] clockevents: i386 drivers Add clockevent drivers for i386: lapic (local) and PIT/HPET (global). Update the timer IRQ to call into the PIT/HPET driver's event handler and the lapic-timer IRQ to call into the lapic clockevent driver. The assignement of timer functionality is delegated to the core framework code and replaces the compile and runtime evalution in do_timer_interrupt_hook() Use the clockevents broadcast support and implement the lapic_broadcast function for ACPI. No changes to existing functionality. [ kdump fix from Vivek Goyal <[EMAIL PROTECTED]> ] [ fixes based on review feedback from Arjan van de Ven <[EMAIL PROTECTED]> ] Cleanups-from: Adrian Bunk <[EMAIL PROTECTED]> Build-fixes-from: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> Cc: john stultz <[EMAIL PROTECTED]> Cc: Roman Zippel <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> As a wild guess, I'd bet that the rcu queues are failing to get called (probably some problem with the timer interrupt in the APs?), thus preventing the system to get into a quiescent state. It does seem timer related to me. Maybe one of the timer gurus have any other word on this? -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - 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: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
On 7/20/07, Mark Tiefenbruck [EMAIL PROTECTED] wrote: I'd appreciate any help on getting this report sent to the appropriate list and, of course, getting this fixed. I don't know what's useful, so you're getting everything. This will be a very long e-mail. My new laptop won't boot with kernel versions 2.6.21 or 2.6.22 . No oops. No panic. It just stops printing messages. Maybe it would eventually continue if I wait long enough, but it's unacceptable either way. I include below the contents of dmesg for a working kernel up to the point where it halts. I'm also including what it usually does for a few lines after that point. I did git-bisect on the 2.6.21.y tree. I'm including the result of that as well. It mentions HPET, so I should mention my computer also fails to boot when I enable HPET in my BIOS. I don't have the details of this currently; I can reproduce it again if needed. I've also included my kernel configuration and ver_linux output. You'll notice that my gcc version is 4.2.0, but this also happens with 4.1.2. I'm including /proc/cpuinfo and lspci -vvv. I'm including /proc/ioports and /proc/iomem. I don't have a /proc/scsi. Thanks, Mark Here's the commit that causes the problem: e9e2cdb412412326c4827fc78ba27f410d837e6e is first bad commit commit e9e2cdb412412326c4827fc78ba27f410d837e6e Author: Thomas Gleixner [EMAIL PROTECTED] Date: Fri Feb 16 01:28:04 2007 -0800 [PATCH] clockevents: i386 drivers Add clockevent drivers for i386: lapic (local) and PIT/HPET (global). Update the timer IRQ to call into the PIT/HPET driver's event handler and the lapic-timer IRQ to call into the lapic clockevent driver. The assignement of timer functionality is delegated to the core framework code and replaces the compile and runtime evalution in do_timer_interrupt_hook() Use the clockevents broadcast support and implement the lapic_broadcast function for ACPI. No changes to existing functionality. [ kdump fix from Vivek Goyal [EMAIL PROTECTED] ] [ fixes based on review feedback from Arjan van de Ven [EMAIL PROTECTED] ] Cleanups-from: Adrian Bunk [EMAIL PROTECTED] Build-fixes-from: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Thomas Gleixner [EMAIL PROTECTED] Signed-off-by: Ingo Molnar [EMAIL PROTECTED] Cc: john stultz [EMAIL PROTECTED] Cc: Roman Zippel [EMAIL PROTECTED] Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] As a wild guess, I'd bet that the rcu queues are failing to get called (probably some problem with the timer interrupt in the APs?), thus preventing the system to get into a quiescent state. It does seem timer related to me. Maybe one of the timer gurus have any other word on this? -- Glauber de Oliveira Costa. Free as in Freedom http://glommer.net The less confident you are, the more serious you have to act. - 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/
