Red Hat Bugzilla – Bug 468312
Kernel stalls in boot without key presses until init is running
Last modified: 2009-04-06 13:45:27 EDT
Description of problem: On this machine (Smolt ID: aadb172c-da20-417c-b3d6-909b515b48ae), whether or not I have 'escaped' from plymouth, there is not progress or activity unless I press keys (shift or control are my favorites to provide such activity) repeatedly. This was true of the entire Beta installer. It is true of the kernels. It is also true on a machine that should be identical (Smolt ID is not readily available). Version-Release number of selected component (if applicable): kernel-2.6.27.3-39.fc10.x86_64 How reproducible: Every time Steps to Reproduce: 1. Boot 2. Stall 3. Press keys repeatedly 4. Watch it boot Expected results: It should boot without having to provide keyboard activity.
http://www.smolts.org/show?uuid=pub_208891d6-640d-4879-a7ae-d70c4a7d09ad Sorry, I had the wrong ID.
nVidia MCP67, AMD processor Can you attach the file /var/log/dmesg after booting the system? Then try adding 'nolapic_timer' to the kernel boot options in /etc/grub.conf and reboot to see if that helps.
I will be happy to do this. Unless the .27/.28 kernels require this when the .25/.26 kernels do not, then this isn't the problem. This is a regression vs. F9, as F9 works fine. I will provide the log and do the test sometime today (may be late USA time).
Created attachment 321728 [details] /var/log/dmesg as requested
"nolapic_timer" does nothing helpful for my problem.
nolapic_timer might not have any effect on a 2.6.27 kernel. Can you try nohz=off instead?
On the latest kernel, this does not solve the problem. It still hangs until udev gives the green [ok] unless you hold down/press keys repeatedly.
Ok, status update. Not on the laptop. kernel-2.6.27.5-117.fc10.x86_64 is the kernel after the .92 one (sorry don't have exact version) that I used. .92 worked as described above. .117 requires the key press trick until GDM comes up (that is, it is MUCH worse). This may be plymouth and not kernel problem, however I do not know.
Looks like it's using the hpet as a clocksource. Can you try the 'nohpet' boot option?
Okay, on the .92 kernel it works (haven't tried it on the newer one). Any reason the F9 kernels worked? I tried disabling this in the BIOS, didn't fix the problem. 'nohpet' works. Any thing that is being given up by this?
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This appears fixed in rawhide for F11. Marking fixed.