+++ This bug was initially created as a clone of Bug #878265 +++ Description of problem: Fresh Install from Update Repository Additional info: kernel-3.7.9-201.fc18.x86_64 backtrace: https://retrace.fedoraproject.org/faf/reports/16909/ CPU Info: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 6 model name : AMD Opteron 22xx (Gen 2 Class Opteron) stepping : 1 microcode : 0x1000065 cpu MHz : 2400.000 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 5 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 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good nopl extd_apicid pni cx16 hypervisor cmp_legacy svm cr8_legacy 3dnowprefetch bogomips : 4800.00 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 6 model name : AMD Opteron 22xx (Gen 2 Class Opteron) stepping : 1 microcode : 0x1000065 cpu MHz : 2400.000 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 5 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 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good nopl extd_apicid pni cx16 hypervisor cmp_legacy svm cr8_legacy 3dnowprefetch bogomips : 4800.00 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management:
does this still happen on 3.8.x ?
Yes, just confirmed it still occurs on 3.8.1-201.fc18.x86_64. The abrt message is waiting for me when I log on. This only occurs inside kvm. It does not appear when running on bare metal.
Also appears here, not running any virtualization. cat /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 12 model name : AMD Athlon(tm) 64 Processor 3000+ stepping : 0 microcode : 0x3a cpu MHz : 2000.000 cache size : 512 KB 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 syscall nx mmxext lm 3dnowext 3dnow rep_good nopl bogomips : 4399.51 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
WARNING: at arch/x86/kernel/cpu/amd.c:28 init_amd+0x107/0x666() Hardware name: Bochs rdmsrl_amd_safe should only be used on K8! Is that what everyone is seeing in this bug? Gleb, any thoughts on this one?
(In reply to comment #4) > WARNING: at arch/x86/kernel/cpu/amd.c:28 init_amd+0x107/0x666() > Hardware name: Bochs > rdmsrl_amd_safe should only be used on K8! > > Is that what everyone is seeing in this bug? > > Gleb, any thoughts on this one? Since comment #3 says that the problem happens on bare metal I am not sure I am the person to ask for thoughts about it. Looks like a guest bug.
I was ignoring comment #3. There's no actual data and it isn't the original reporter. When you say guest bug, do you mean "bug in how QEMU is presenting the CPU" or..? I'd be happy to route it somewhere else, but a bit more detail on where you think that is.
(In reply to comment #6) > I was ignoring comment #3. There's no actual data and it isn't the original > reporter. What actual data is missing? I do not see any reason to ignore the data point. > > When you say guest bug, do you mean "bug in how QEMU is presenting the CPU" > or..? I'd be happy to route it somewhere else, but a bit more detail on > where you think that is. When I am saying guest bug it mean the bug has nothing to do with virtualization. "bug in how QEMU is presenting the CPU" is excect oposit of this. Looking at the upstream code the code looks like this: init_amd(struct cpuinfo_x86 *c) { if (c->x86 == 0xf) rdmsrl_amd_safe() } rdmsrl_amd_safe() { struct cpuinfo_x86 *c = &cpu_data(smp_processor_id()); WARN_ONCE((c->x86 != 0xf) } This looks like some basic assumptions do not hold here. Probably per cpu cpu_data is not yet initialized at this point but I haven't dig further.
What was the qemu command line to start the guest?
(In reply to comment #7) > (In reply to comment #6) > > I was ignoring comment #3. There's no actual data and it isn't the original > > reporter. > What actual data is missing? I do not see any reason to ignore the data > point. > In the original bug #878265 this one is clonned from the bug happens on a bare metal: Hardware name: MS-6702
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those.
I no longer have Fedora 18, so I can provide any additional information. Anyone else?
Received this email today: > The following is a list of requests people have made of you, > which have been outstanding more than 7 days. To avoid > disappointing others, please deal with them as quickly as > possible. > > needinfo > -------- > > Bug 916038: [abrt]: WARNING: at arch/x86/kernel/cpu/amd.c:28 > init_amd+0x107/0x621() (234 days old) > https://bugzilla.redhat.com/show_bug.cgi?id=916038 I think receiving this message on a CLOSED bug 234 days old is more disappointing than my lack of info.