[SOLVED] Troubleshooting kernel panics since 3.4

Question

All kernel versions since 3.4 have been absolutely unstable on my machine. A panic might happen right during bootup, or if it boots up, there will be random segfaults all over the place, followed by a panic no later than 20 minutes or so from bootup. I have been forced to use kernel 3.3.7-1-ck, which runs perfectly fine. I haven't done any particularly rigorous diagnostics of the problem because watching the system fail repeatedly is not very fun when I can just revert to a working setup. However, these are the observations I've come up with over the months:
- a typical panic dump looks like this (although the "spurious ACK" like is new - in the few other screenshots I've got there is nothing prior to the hardware errors, or the first line is no longer on screen);
- it happens with the same symptoms on LiveCDs - I've tried Arch 2012.10.06, Ubuntu 12.10 and Mint 14.1 disks, all panicking during bootup or shortly afterwards (Arch 2010.05 loads fine);
- I've run Memtest overnight since the problems started and it came up clean;
- as mentioned, kernel 3.3.7 works fine, as does Windows 7 that I double-boot with;
- it is not GPU related - I previously had other problems with Radeon HD4850 and suspected it might be involved here, but the problem persists after a recent upgrade to GTX 650Ti;
- going by my pacman.log, I've definitely tried using (and then reverted to 3.3.7) kernels 3.4.2-1, 3.4.3-1, 3.4.4-2, 3.5.2-1, 3.6.3-1, 3.7.1-3, 3.7.4-1 from repo-ck, as well as other versions from core repo that I can't reliably keep track of;
- system info:
Motherboard: Asus P5Q-E
CPU: Intel Core2Duo E8400
RAM: 5GB in 3 sticks (2+2+1)
GPU: GTX 650Ti (Radeon HD4850 until a few weeks ago)
Storage: 2 SATA HDDs, 1 SATA SSD
IDE optical drive
Sound card: Creatve Audigy LS
External devices: PS/2 keyboard, USB mouse, USB Wacom Bamboo tablet, USB external HDD
Any suggestions how to further investigate and/or solve this problem are welcome. I'll be happy to provide any other information that might be useful.
EDIT: blacklisting acpi-cpufreq module did the trick.
Last edited by bucaneer (2013-01-28 13:48:16)

Answer 1

@the sad clown: all hardware that is normally connected to the PC is listed in the first post. Keyboard and mouse are both very generic and unremarkable, and disconnecting the tablet and external HDD has no effect.
/proc/cpuinfo when running 3.3.7-1-ck:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
stepping : 10
microcode : 0xa07
cpu MHz : 2999.564
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dts tpr_shadow vnmi flexpriority
bogomips : 6001.22
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
stepping : 10
microcode : 0xa07
cpu MHz : 2999.564
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dts tpr_shadow vnmi flexpriority
bogomips : 6001.22
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
/proc/cpuinfo when running 3.7.4-1:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
stepping : 10
microcode : 0xa07
cpu MHz : 670.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority
bogomips : 6002.82
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
stepping : 10
microcode : 0xa07
cpu MHz : 670.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority
bogomips : 6002.82
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
First of all, it appears that 3.7.4 doesn't recognize CPU frequency right, showing 670 MHz instead of 3 GHz. Also, 3.7.4 has a "dtherm" flag instead of "dts". No idea what to make of it.
@mich41: thanks for the suggestion. I may try that later, when I have a bigger block of time to spare.