Linux fails to boot first time after a cold boot and after /sbin/reboot. I was able to capture the output via serial console. Both successful and failed logs are included. This happens with stock Slackware64 kernel as well as recently released 2.6.32. Booting with 'nolapic' parameter works every time. http://lkml.org/lkml/2009/12/4/309
Created attachment 24046 [details] Boot log in failure case
Created attachment 24047 [details] Boot log in case of success
please add the boot option "initcall_debug printk.time=1" and re-catch the boot log. :)
Created attachment 24068 [details] Failed boot log (with initcall_debug and printk.time=1)
Created attachment 24069 [details] Successful boot log (with initcall_debug and printk.time=1)
Hmm, it seems that you attached the failure boot log twice.
Created attachment 24090 [details] Failed boot log (with initcall_debug and printk.time=1) [for real this time]
(In reply to comment #7) > Created an attachment (id=24090) [details] > Failed boot log (with initcall_debug and printk.time=1) [for real this time] I think you mean the successful boot log, right? but it's truncated, please attach the FULL dmesg output.
Please help me doing it properly this time. Since capturing those logs are not as easy as i would have liked, involves physically moving a box from one room to the next fooling around with network settings and KVM switch. a. http://bugzilla.kernel.org/attachment.cgi?id=24090 is indeed the log of successful boot b. http://bugzilla.kernel.org/attachment.cgi?id=24090 is intentionally truncated by me, since nothing particularly stellar goes on there c. http://bugzilla.kernel.org/attachment.cgi?id=24068 (the failed one) is truncated because the box just resets, without an oops or any indication of the reset cause Regarding item (b), one of the reasons why i've truncated it is the fact that the box has a video acquisition board with 4 saa7134 chips and v4l is printing a lot of useless "your board is missing EEPROM" messages with long and tedious enumeration of all saa7134 derived grabbers it supports. So, if _really_ needed, i can remove the board (since the problem is always there regardless of the boards presence) and try to recapture the logs, this time attaching the whole, regardless how big, successful log. Is that what i should do? Thanks.
> So, if _really_ needed, i can remove the board (since the problem is > always there regardless of the boards presence) and try to recapture > the logs, this time attaching the whole, regardless how big, > successful log. Is that what i should do? > yes, this is what i want. thanks!
Created attachment 24113 [details] Failed log
Created attachment 24114 [details] Successful log Probably worth noting that it took 3 resets for kernel to finally boot successfully this time.
Another data point. I have a KVM switch and in all cases when boot was unsuccessful the machine was powered up when KVM was active for the other box. Just tried to perform a full cycle with KVM pointing to this box before powering the box up and everything was fine. Some more observations: a. Also Linux on that keeps trying to boot failing if the KWM is not pointing to it. b. Switching KVM after POST but before boot loader (GRUB) even tries to start the kernel also leads to an unsuccessful boot attempt c. Windows has no problems.
does the problem happens on this machine only? i.e. if you connect another Linux machine to the KVM, does Linux boot successfully if the machine is not pointed by the KVM?
Only on this machine.
would you please try the latest upstream kernel,s ay 2.6.32 or 2.6.32-rc4 and attach the failure boot log?
Created attachment 24869 [details] Failure log for kernel v2.6.32
Now it seems that the kernel failure is related to the KVM switch. and the "nolapic" boot option no longer works, right?
No, nolapic boot option does work.
What does this have to do with ACPI? Does the machine boot with "acpi=off"? If yes, can the failure be reproduced with "acpi=off"?
bug closed as there is no response from the bug reporter. please re-open it if the problem still exists in the latest upstream kernel.