Created attachment 387606 [details]
Output of 'dmesg'
Description of problem:
I noticed booting was hanging at the "apply Intel microcode" step for a few minutes.
Instrumenting /etc/init.d/microcode_ctl a bit, it seems to hang at the '/sbin/modprobe microcode' step.
If I run that command from a terminal, I see:
[root@tlondon ~]# time modprobe -v microcode
A 2 minute hang.....
Examining /var/log/messages, looks like it is taking 1 minute per core:
Jan 29 09:28:06 tlondon kernel: microcode: CPU0 sig=0x10676, pf=0x80, revision=0x60c
Jan 29 09:28:06 tlondon kernel: platform microcode: firmware: requesting intel-ucode/06-17-06
Jan 29 09:29:06 tlondon kernel: microcode: CPU1 sig=0x10676, pf=0x80, revision=0x60c
Jan 29 09:29:06 tlondon kernel: platform microcode: firmware: requesting intel-ucode/06-17-06
Jan 29 09:30:06 tlondon kernel: microcode: Microcode Update Driver: v2.00 <firstname.lastname@example.org>, Peter Oruba
Jan 29 09:30:07 tlondon kernel: microcode: Microcode Update Driver: v2.00 removed.
[I ran the rmmod right after the modprobe to get a time in /var/log/messages.]
Not sure what else to provide, but am attaching output of 'dmesg'.
Version-Release number of selected component (if applicable):
Every boot, every 'modprobe microcode'
Steps to Reproduce:
1. Boot; hangs at microcode update
2. Or, "time modprobe microcode"
2 minute hang.... (one minute per CPU?)
Strange...experienced same thing, but reverted udev et al to 147-2.fc13.x86_64 fixed it for me.
Thanks. I can confirm that downgrading to udev-147-2.fc13.x86_64 "makes it work for me".
Doesn't work with either udev-151-1.fc13.x86_64.rpm or with udev-151-2.fc13.x86_64.rpm.
Reassigning to udev......
Hmm, the firmware loading code changed from a shell script (firmware.sh) to a binary.
Can you put udev in debug mode?
# udevadm control --log-priority=debug
# modprobe microcode
and post the messages in /var/log/messages
Created attachment 388054 [details]
/var/log/messages output with 'udevadm control --log-priority=debug'
firmware --firmware=intel-ucode/06-17-06 --devpath=/devices/platform/microcode/firmware/microcode
seems like the firmware is expected to be in
Either this is a bug for the microcode_ctl package or the kernel module.
'did not find firmware file 'intel-ucode/06-17-06''
see also bug #248307
*** Bug 561824 has been marked as a duplicate of this bug. ***
Sounds like this problem my be more than 2 minutes on some systems. Adding keyword CommonBugs so this is noted if still present during Alpha release.
At least on my system, it is 1 minute per core/CPU (2 cores).
Thanks, reproduced. Trying to figure this out.
Sigh, looks like udev is polling waiting for something to happen, but intel microcode is shipped as a compilation loaded by microcode_ctl instead of request_firmware. (This avoids us having to create a pile of intel-ucode/%x-%x-%x files.)
I can't figure out what exactly udev is polling on, but it probably shouldn't do that.
Anyway, as a fix, I'll neuter that out of the request_firmware code, as I don't know of a place to get the firmware aside from as the microcode.dat file. (Nor do I particularly care.)
Sorry Harald, just noticed while debugging the hang that it's fixed in udev HEAD.
Author: Thomas Bächler <email@example.com>
Date: Sun Jan 31 13:49:02 2010 +0100
firmware: fix error reporting on missing firmware files
The new firmware loader does not report an error to the kernel if a firmware
is missing. This results in modprobe stalling for 60 seconds for each firmwa
a module tries to load.
Tom, can you test: http://koji.fedoraproject.org/koji/taskinfo?taskID=1967183
Harald, patch to udev is: http://bombadil.infradead.org/~kyle/udev-151-3.patch
Yes, http://koji.fedoraproject.org/koji/taskinfo?taskID=1967183 boots "properly" with kernel-2.6.33-0.27.rc6.git1.fc13.x86_64 (that is, no 60 second stall per CPU).
I had to use "rpm -Uvh --force" to install these udev packages, since the 'version' was udev-151-2 (the same as the currently installed packages).
Thanks for tracking this down!
Great, thanks for testing! It'll be 'fixed' by the next kernel too.
Boots "fast" with both kernel-2.6.33-0.36.rc7.git0.fc13.x86_64 and kernel-2.6.33-0.40.rc7.git0.fc13.x86_64.
I can confirm the fix with 2.6.33-0.40.rc7.git0.fc13.x86_64.
Updated udev has hit rawhide.
This is fixed in F-13-Alpha, removing CommonBugs keyword