BUG: soft lockup with 3.7.0 but not 3.6.10
Quoted 1 line · Borislav Petkov
What family is that? Can you give
/proc/cpuinfo?
processor : 0vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
stepping : 1
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yesfpu_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 : 2004.56
TLB size : 1024 4K pages
clflush size : 64cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps
processor : 1vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
stepping : 1
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yesfpu_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 : 2004.56
TLB size : 1024 4K pages
clflush size : 64cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps
Quoted 5 lines
Quoted 2 lines
Dec 11 16:02:15 pervalidus kernel: [11260.096015] BUG: soft lockup -CPU#1 stuck for 22s! [cc1:20906]
Hmm, this says that gcc gets stuck at some point. Is this always reproducible on 3.7?
It always happens when I compile MPlayer. It was always cc1, but yasm once.
Quoted 7 lines
Quoted 7 lines
What about using another version of gcc, can you repro it then too?
It would be interesting to know where all those cc1 processes get stuck.
Can you break into them with gdb and dump the code around RIP everytime those tasks gets stuck? Try doing a couple of them to see whether it is repeatable.
I'll see what I can do. I'm compiling with -j3, so it's hard to see before the kernel reports it.