Message-ID: <5d6222a80707201953s11b2c5ceh427a5e345726a6b1@mail.gmail.com>
Date:	Fri, 20 Jul 2007 23:53:00 -0300
From:	"Glauber de Oliveira Costa" <glommer@...il.com>
To:	"Mark Tiefenbruck" <mark@...xbox.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+

On 7/20/07, Mark Tiefenbruck <mark@...xbox.org> 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@...utronix.de>
> 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@...ibm.com> ]
>     [ fixes based on review feedback from Arjan van de Ven
> <arjan@...radead.org> ]
>     Cleanups-from: Adrian Bunk <bunk@...sta.de>
>     Build-fixes-from: Andrew Morton <akpm@...l.org>
>     Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
>     Signed-off-by: Ingo Molnar <mingo@...e.hu>
>     Cc: john stultz <johnstul@...ibm.com>
>     Cc: Roman Zippel <zippel@...ux-m68k.org>
>     Cc: Andi Kleen <ak@...e.de>
>     Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
>     Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
>
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists