Bug 561824 - modprobe microcode takes ages
Summary: modprobe microcode takes ages
Keywords:
Status: CLOSED DUPLICATE of bug 560031
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-02-04 13:12 UTC by Kamil Páral
Modified: 2010-02-05 15:42 UTC (History)
13 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-02-05 15:42:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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 ***


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