Bug 125419 - CPUFreq causes C3 VIA Samuel 2 to lockup
CPUFreq causes C3 VIA Samuel 2 to lockup
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
:
: 136257 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-06 13:16 EDT by Ed K
Modified: 2015-01-04 17:06 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-24 00:44:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Computer Information (1.05 KB, text/plain)
2004-06-06 13:21 EDT, Ed K
no flags Details
output from test (2.01 KB, text/plain)
2004-06-07 10:59 EDT, Ed K
no flags Details
Files in /sys (30.96 KB, text/plain)
2004-06-07 15:16 EDT, Ed K
no flags Details

  None (edit)
Description Ed K 2004-06-06 13:16:17 EDT
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.
Comment 1 Ed K 2004-06-06 13:21:03 EDT
Created attachment 100907 [details]
Computer Information

Computer information from /proc
Comment 2 Dave Jones 2004-06-06 17:03:27 EDT
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.

Comment 3 Ed K 2004-06-06 20:39:16 EDT
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
Comment 4 Dave Jones 2004-06-07 05:58:08 EDT
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
Comment 5 Ed K 2004-06-07 10:59:25 EDT
Created attachment 100921 [details]
output from test
Comment 6 Ed K 2004-06-07 11:00:45 EDT
Well, it doesn't look like the longhaul module is available. now I
wonder why "service cpuspeed stop" worked.
Comment 7 Dave Jones 2004-06-07 13:23:56 EDT
[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  ?
Comment 8 Ed K 2004-06-07 13:26:46 EDT
Both of these commands return nothing:

[root@www root]# find /sys/ -name cpufreq   
[root@www root]# dmesg | grep longhaul
[root@www root]# 
Comment 9 Dave Jones 2004-06-07 15:08:36 EDT
Do you have anything at all in /sys ?

Try dmesg -n 128000 | grep longhaul
Comment 10 Ed K 2004-06-07 15:16:42 EDT
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
Comment 11 Dave Jones 2004-06-08 19:13:12 EDT
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.
Comment 12 Ed K 2004-06-08 22:47:24 EDT
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.
Comment 13 Dave Jones 2004-06-09 07:29:09 EDT
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.
Comment 14 Cordel 2004-07-18 05:17:10 EDT
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
Comment 15 Dave Jones 2004-11-19 23:52:31 EST
*** Bug 136257 has been marked as a duplicate of this bug. ***
Comment 16 Dave Jones 2004-11-19 23:53:43 EST
are things any better with the latest errata kernel ?
There were a number of longhaul fixes in 2.6.9.
Comment 17 Paul Coleman 2004-11-20 20:51:26 EST
As of the latest fc3 kernel things are the same... the system still
locks up at a random time after cpuspeed start.
Comment 18 andy leadbetter 2005-01-31 16:38:18 EST
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.
Comment 19 Dave Jones 2005-02-24 00:44:04 EST
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).

Note You need to log in before you can comment on or make changes to this bug.