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
dmesg and other information are attached to the kernel bug #35522
Anyideas anyone?
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.
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.
*** This bug has been marked as a duplicate of bug 690930 ***