Bug 468312 - Kernel stalls in boot without key presses until init is running
Summary: Kernel stalls in boot without key presses until init is running
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 10
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-24 01:54 UTC by Trever Adams
Modified: 2009-04-06 17:45 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-04-06 17:45:27 UTC
Type: ---
Embargoed:


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

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.


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