Re: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+

From: Glauber de Oliveira Costa
Date: Fri Jul 20 2007 - 22:53:20 EST


On 7/20/07, Mark Tiefenbruck <mark@xxxxxxxxxxx> 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 <tglx@xxxxxxxxxxxxx>
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 <vgoyal@xxxxxxxxxx> ]
[ fixes based on review feedback from Arjan van de Ven
<arjan@xxxxxxxxxxxxx> ]
Cleanups-from: Adrian Bunk <bunk@xxxxxxxxx>
Build-fixes-from: Andrew Morton <akpm@xxxxxxxx>
Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
Cc: john stultz <johnstul@xxxxxxxxxx>
Cc: Roman Zippel <zippel@xxxxxxxxxxxxxx>
Cc: Andi Kleen <ak@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/