Bug 715118

Summary: udev tries indefinitely to load the microcode module
Product: [Fedora] Fedora Reporter: Joshua Covington <joshuacov>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: awilliam, harald, jonathan, robatino
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-29 17:16:18 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:
Bug Depends On:    
Bug Blocks: 713560, 718266, 718269    

Description Joshua Covington 2011-06-21 22:03:10 UTC
Description of problem:
Since kernel-2.6.39.x I cannot boot the kernel because I'm flooded with the message:

microcode: microcode: CPU0: AMD CPU family 0xf not supported

I filed a bug against the kernel and it turned out that udev actually tries indefinitely to load the microcode module. https://bugzilla.kernel.org/show_bug.cgi?id=35522

The offensive code is in /lib/udev/rules.d/89-microcode.rules and after blacklisting the module everything is fine. When I try to manually load it (after booting with it being disabled) I get:

[root@localhost ~]# modprobe -v microcode
insmod /lib/modules/2.6.39-0.fc16.x86_64/kernel/arch/x86/kernel/microcode.ko 
FATAL: Error inserting microcode
(/lib/modules/2.6.39-0.fc16.x86_64/kernel/arch/x86/kernel/microcode.ko):
Invalid argument

and after this I got the following into dmesg:

[  170.459160] microcode: CPU0: family 15 not supported

Version-Release number of selected component (if applicable):
kernel-3.0-0.rc3.git5.1.fc16.x64_86
udev-171-2.fc16.x64_86

How reproducible:
Boot the pc

Expected results:
udev gives up if the module doesn't want to load.

Additional info:
My processor is:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 104
model name      : AMD Turion(tm) 64 X2 Mobile Technology TL-60
stepping        : 1
cpu MHz         : 2000.000
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm
3dnowext 3dnow rep_good nopl extd_apicid pni cx16 lahf_lm cmp_legacy svm
extapic cr8_legacy 3dnowprefetch lbrv
bogomips        : 1999.99
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 104
model name      : AMD Turion(tm) 64 X2 Mobile Technology TL-60
stepping        : 1
cpu MHz         : 2000.000
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 1
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm
3dnowext 3dnow rep_good nopl extd_apicid pni cx16 lahf_lm cmp_legacy svm
extapic cr8_legacy 3dnowprefetch lbrv
bogomips        : 1999.99
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps

Comment 1 Joshua Covington 2011-06-21 22:06:29 UTC
dmesg and other information are attached to the kernel bug #35522

Comment 2 Joshua Covington 2011-06-26 18:53:33 UTC
Anyideas anyone?

Comment 3 Adam Williamson 2011-06-29 02:01:52 UTC
Looks like this is a general problem with any non-supported CPU - see http://lists.fedoraproject.org/pipermail/test/2011-June/101087.html . Proposing as F16 Alpha blocker. Microcode updating not being supported should not be fatal to boot, boot should simply continue.

Comment 4 Joshua Covington 2011-06-29 08:15:25 UTC
Yes, this is a blocker for me, too. It actually prevents us from testing the latest kernel-3.0. I hope this is fixed asap.

Comment 5 Adam Williamson 2011-06-29 17:16:18 UTC

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