Red Hat Bugzilla – Bug 125419
CPUFreq causes C3 VIA Samuel 2 to lockup
Last modified: 2015-01-04 17:06:52 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Description of problem: System halts 5 or 6 minutes after bootup. Error is: Unknown interrupt or fault at EIP 00000246 00000073 080a9649 Unknown interrupt or fault at EIP 00000297 00000073 080a5ad3 This is not the same as this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120685 Version-Release number of selected component (if applicable): kernel-2.6.6-1.422.i686 How reproducible: Always Steps to Reproduce: Using a newly install FC2: 1. Boot computer 2. Wait 5-6 minutes 3. System Halts Actual Results: Unknown interrupt or fault at EIP 00000246 00000073 080a9649 Unknown interrupt or fault at EIP 00000297 00000073 080a5ad3 Expected Results: Working System Additional info: I have been able to create a working kernel. Using these steps: 1) linux-2.6.6 2) 2.6.6-mm5 3) 'make allmodconfig' 4) set the cpu to: CONFIG_MCYRIXIII=y 5) diable cpufreq: # CONFIG_CPU_FREQ is not set 6) raid1 enabled: CONFIG_MD_RAID1=y 7) ext3 enabled: CONFIG_EXT3_FS=y But I loose cpufreq.
Created attachment 100907 [details] Computer Information Computer information from /proc
just to be certain it is cpufreq (self-compiled kernels may inadvertantly change something else), can you run the FC2 kernel, but disable the cpuspeed daemon ? "service cpuspeed stop" after booting.
I installed FC2, just to make sure. My test computer is a stock FC2 with the kernel from: http://people.redhat.com/arjanv/2.6/RPMS.kernel/kernel-2.6.6-1.422.i586.rpm I've issued the following commands after the 'firstboot' was done: service cpuspeed stop chkconfig cpuspeed off chkconfig sendmail off chkconfig kudzu off All is good. The system would have locked up in 2 minutes, but now i'm at 10 minutes. CPUSpeed have a bug for C3 Samuel 2? ed
more likely the longhaul driver is unstable on some boards. I just did a test here on my samuel 2, and it seems to survive and do the right thing. It could be that the board just doesn't like having the speed changed as much as cpuspeed does. try this (as root).. modprobe longhaul debug=1 cd /sys/devices/system/cpu/cpu0/cpufreq echo powersave > scaling_governor grep MHz /proc/cpuinfo echo performance > scaling_governor grep MHz /proc/cpuinfo dmesg | tail -n15
Created attachment 100921 [details] output from test
Well, it doesn't look like the longhaul module is available. now I wonder why "service cpuspeed stop" worked.
[root@www root]# cd /sys/devices/system/cpu/cpu0/cpufreq -bash: cd: /sys/devices/system/cpu/cpu0/cpufreq: No such file or directory Whoops. fell at the first hurdle. That is odd. Hmm, I forgot longhaul is compiled into the fc2 kernel, which is why it didn't work when modprobe'd. Puzzling why you don't have that dir above though. Does find /sys/ -name cpufreq show up anything at all ? dmesg | grep longhaul ?
Both of these commands return nothing: [root@www root]# find /sys/ -name cpufreq [root@www root]# dmesg | grep longhaul [root@www root]#
Do you have anything at all in /sys ? Try dmesg -n 128000 | grep longhaul
Created attachment 100939 [details] Files in /sys I've issued the following statements, and here are the outputs. [root@www log]# dmesg -n 128000 | grep longhaul klogctl: Invalid argument [root@www log]# grep -i longhaul /var/log/messages [root@www log]# note, i've rebooted that box a few times, so the entire bootlog in still in /var/log/messages my mounted filesystems are: # mount /dev/md1 on / type ext3 (rw) none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) usbdevfs on /proc/bus/usb type usbdevfs (rw) /dev/md0 on /boot type ext3 (rw) none on /dev/shm type tmpfs (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) and, you can see the files in /sys in this attachment
I'm totally puzzled why cpufreq bits aren't showing up in sysfs for you. I'll look into that as a seperate item for my TODO list. The good news is that talking about this with the folks from VIA has thrown up a few ideas, so I'll make some changes soon to the driver. Hopefully they'll fix this problem, but no promises. In other good news, I am able to actually reproduce this locally now, so I'll dig into some more.
I'm glad you are able to reproduce the problem. I was beginning to think it was the motherboard: http://www.syntaxgroups.com/catalog/product_info.php?products_id=108 Are you also not showing anything in sysfs? FYI: While you are talking to VIA, let them know that I appreciate their efforts on low power computers, I have this motherboard with two 7200rpm drives, and the total load is 68 watts.
I've not managed to reproduce the 'doesnt show up in sysfs' bug yet, but the crash after 10 minutes or so seems to be pretty easy to reproduce now. It seems that during the speed transition I need to prevent bus mastering, or there's a potential for corrupting random bits of memory.
I as well have the same Syntax main board with the same issue. I had also found http://people.redhat.com/arjanv/c3boot-2.iso to be able to load FC2 in the first place as the normal boot disk does not work. $ cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 796.459 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips : 1589.24
*** Bug 136257 has been marked as a duplicate of this bug. ***
are things any better with the latest errata kernel ? There were a number of longhaul fixes in 2.6.9.
As of the latest fc3 kernel things are the same... the system still locks up at a random time after cpuspeed start.
Still occuring in 2.6.11-rc2-mm If longhaul is inserted there is no problem. But if the CPU speed is adjusted even only infrequently ( perhaps only 1 or two times ) then a lock up immediately occurs.
I've just disabled this in the red hat kernels until I find such time to work on it (or someone else upstream figures out what is up).