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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
