Bug 468312 - Kernel stalls in boot without key presses until init is running
Kernel stalls in boot without key presses until init is running
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-10-23 21:54 EDT by Trever Adams
Modified: 2009-04-06 13:45 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-06 13:45:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/var/log/dmesg as requested (32.54 KB, text/plain)
2008-10-28 17:42 EDT, Trever Adams
no flags Details

  None (edit)
Description Trever Adams 2008-10-23 21:54:42 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):

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.
Comment 1 Trever Adams 2008-10-23 21:59:08 EDT

Sorry, I had the wrong ID.
Comment 2 Chuck Ebbert 2008-10-28 11:15:29 EDT
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.
Comment 3 Trever Adams 2008-10-28 15:53:16 EDT
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).
Comment 4 Trever Adams 2008-10-28 17:42:11 EDT
Created attachment 321728 [details]
/var/log/dmesg as requested
Comment 5 Trever Adams 2008-10-28 18:20:46 EDT
"nolapic_timer" does nothing helpful for my problem.
Comment 6 Chuck Ebbert 2008-11-02 00:26:44 EDT
nolapic_timer might not have any effect on a 2.6.27 kernel. Can you try nohz=off instead?
Comment 7 Trever Adams 2008-11-13 05:48:56 EST
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.
Comment 8 Trever Adams 2008-11-22 01:33:06 EST
Ok, status update. Not on the laptop. kernel-
 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.
Comment 9 Chuck Ebbert 2008-11-24 18:11:18 EST
Looks like it's using the hpet as a clocksource. Can you try the 'nohpet' boot option?
Comment 10 Trever Adams 2008-11-25 01:56:00 EST
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?
Comment 11 Bug Zapper 2008-11-25 23:10:49 EST
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:
Comment 12 Trever Adams 2009-04-06 13:45:27 EDT
This appears fixed in rawhide for F11. Marking fixed.

Note You need to log in before you can comment on or make changes to this bug.