Bug 561824 - modprobe microcode takes ages
modprobe microcode takes ages
Status: CLOSED DUPLICATE of bug 560031
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-04 08:12 EST by Kamil Páral
Modified: 2010-02-05 10:42 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-05 10:42:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Kamil Páral 2010-02-04 08:12:18 EST
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 08:31:03 EST
Yup. I have a reproducing environment here. More when I get chance.
Comment 2 Ales Zelinka 2010-02-04 08:42:01 EST
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 10:29:29 EST
Perhaps a duplicate of bug#561824 which seems to attribute the slow down to udev.
Comment 4 James Laska 2010-02-04 10:30:18 EST
(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 12:41:18 EST
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 14:20:47 EST
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 10:42:38 EST

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

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