Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 561824

Summary: modprobe microcode takes ages
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: alanfyoung, anton, azelinka, dougsland, gansalmon, itamar, jcm, jlaska, jonathan, kernel-maint, mbreuer, pbrobinson, spoyarek
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: 2010-02-05 15:42:38 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:

Description Kamil Páral 2010-02-04 13:12:18 UTC
Description of problem:
I often use Rawhide in virt-manager using KVM. My host machine is Fedora
12. Recently I noticed that booting Rawhide takes ages. After more careful
examination I found out that "Applying Intel CPU microcode update" line
pauses the system exactly for 1 minute. Then the boot continues. I don't
know if it is a problem in Rawhide or in some update of libvirt.

Also Siddhesh Poyarekar confirmed that 'modprobe microcode' takes about a minute.

Version-Release number of selected component (if applicable):
Fedora 12 host:
virt-manager-0.8.2-1.fc12.noarch
libvirt-client-0.7.1-15.fc12.x86_64
libvirt-0.7.1-15.fc12.x86_64
kernel-2.6.31.12-174.2.3.fc12.x86_64

Rawhide guest:
kernel-2.6.33-0.23.rc5.git1.fc13.x86_64

How reproducible:
always

Steps to Reproduce:
1. Install Rawhide in virt-manager using KVM on F12 host.
2. Boot it.

Comment 1 Jon Masters 2010-02-04 13:31:03 UTC
Yup. I have a reproducing environment here. More when I get chance.

Comment 2 Ales Zelinka 2010-02-04 13:42:01 UTC
It takes ages to finish on bare metal too. 
I noticed this shortly before my
rawhide kicked the bucket and had to be reinstalled - can't provide package
versions or reproduce the problem. But it started around 2010-02-01.

Comment 3 James Laska 2010-02-04 15:29:29 UTC
Perhaps a duplicate of bug#561824 which seems to attribute the slow down to udev.

Comment 4 James Laska 2010-02-04 15:30:18 UTC
(In reply to comment #3)
> Perhaps a duplicate of bug#561824 which seems to attribute the slow down to
> udev.                  ^^^^^^^^^^^

Doh!  Pasted the wrong number ... let's try this again.

Perhaps a duplicate of bug#560031 which seems to attribute the slow down to udev.

Comment 5 Alan F Young 2010-02-04 17:41:18 UTC
I've just encountered this bug when trying to boot the i386 KDE nightly build LiveCDs for 2010-02-02 and now again for 2010-02-03 on my Intel MacBook Pro.

First thing I notice is that after the usual graphical countdown ("Automatic Boot in x seconds") the boot sequence switches itself from graphical to verbose text output.

It then hangs for 120s (*not* in my case 60s) at a line of output that reads "Applying Intel CPU microcode update: Applying Intel CPU microcode update:  (i.e. says the same thing twice).

Boot then proceeds before finally stopping again a few seconds later at the line "Starting abrt daemon", at which point the boot appears to fail.

How reproducible:
always

Steps to Reproduce:
1. Download kde-i386-20100202.16.iso or kde-i386-20100203.16.iso and burn to disc.
2. Place in optical drive and attempt to boot from this disk.

Comment 6 Michael Breuer 2010-02-04 19:20:47 UTC
FYI - I dug into this a bit today. Udev is spinning on ALL the rules many, many times for each request.

I enabled debugging on udevd and did modprobe microcode.

That generated 542930 lines of output for 8 cores. The lines basically show thousands of iterations through the whole ruleset for each core. Way more than I can follow - and no indication that I could tell as to what triggered each iteration.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 7 James Laska 2010-02-05 15:42:38 UTC

*** This bug has been marked as a duplicate of bug 560031 ***