Bug 468312

Summary: Kernel stalls in boot without key presses until init is running
Product: [Fedora] Fedora Reporter: Trever Adams <trever>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 10CC: kernel-maint, quintela
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-06 17:45:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/var/log/dmesg as requested none

Description Trever Adams 2008-10-24 01:54:42 UTC 
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.
Comment 1 Trever Adams 2008-10-24 01:59:08 UTC 
http://www.smolts.org/show?uuid=pub_208891d6-640d-4879-a7ae-d70c4a7d09ad

Sorry, I had the wrong ID.
Comment 2 Chuck Ebbert 2008-10-28 15:15:29 UTC 
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 19:53:16 UTC 
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 21:42:11 UTC 
Created attachment 321728 [details]
/var/log/dmesg as requested
Comment 5 Trever Adams 2008-10-28 22:20:46 UTC 
"nolapic_timer" does nothing helpful for my problem.
Comment 6 Chuck Ebbert 2008-11-02 04:26:44 UTC 
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 10:48:56 UTC 
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 06:33:06 UTC 
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.
Comment 9 Chuck Ebbert 2008-11-24 23:11:18 UTC 
Looks like it's using the hpet as a clocksource. Can you try the 'nohpet' boot option?
Comment 10 Trever Adams 2008-11-25 06:56:00 UTC 
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-26 04:10:49 UTC 
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
Comment 12 Trever Adams 2009-04-06 17:45:27 UTC 
This appears fixed in rawhide for F11. Marking fixed.