Bug 140873 - Speed changing problems with VIA C3
Speed changing problems with VIA C3
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
: 146690 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-11-25 18:15 EST by Alan Cox
Modified: 2015-01-04 17:13 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-26 18:11:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alan Cox 2004-11-25 18:15:45 EST
I have a Saint Song pocket PC (walkman sized desktop PC) which has the
funky combination of an i810 motherboard and a VIA C3 Processor
(CPU family 6, Model 7,Step 8).  If I leave the speed daemon stuff
running then the box keeps hanging.

Comment 1 Dave Jones 2004-11-26 22:15:40 EST
this isn't the first I've heard of problems like this.
Something is very very wrong with the longhaul driver on pre-nehemiah systems.
I think for the time being, the safest thing is going to be to disable
it on the samuel/ezra era C3s until I/someone has found the time to dig
into it.

One thing we *should* be doing, but aren't -- the longhaul spec mandates that we
must disable pci bus mastering around the speed transitions.  I did have some
code to disable mastering in the root bridge, which might be enough to satisfy this,
but the whole spec needs rereading to find out what went wrong.

The bad reports all starting happening circa 2.6.6 iirc.
Comment 2 Dave Jones 2004-11-28 14:31:06 EST
update: I've managed to reproduce this on a Nehemiah now as well, which could
highlight a broader problem with the longhaul driver, as it now seems to affect
every stepping.
Comment 3 Adrian Reber 2004-12-23 15:16:15 EST
I also have a problem with my C3. It crashes every third or fourth
day. As I have no monitor connected I have no idea what the reason for
the crashes are but I have now disabled the cpuspeed daemon and see if
it gets better.

processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 7
model name      : VIA Samuel 2
stepping        : 3
cpu MHz         : 601.576
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        : 1183.74
Comment 4 Dave Jones 2005-02-01 23:00:12 EST
*** Bug 146690 has been marked as a duplicate of this bug. ***
Comment 5 Lennert Buytenhek 2005-03-13 06:12:27 EST
"Me too."  Random hang every few days, which seems fixed by disabling
cpuspeed.  Switching the CPU frequency 100 times per second while
pinging the box or running hdparm -T -t results in an almost certain
hang within seconds.

This happens on three different VIA PD10000 boards, 1.0GHz VIA Nehemiah.

% cat /proc/cpuinfo
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 9
model name      : VIA Nehemiah
stepping        : 5
cpu MHz         : 1002.457
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 pse tsc msr cx8 mtrr pge cmov mmx fxsr sse
rng rng_en
bogomips        : 1982.46

Comment 6 Dave Jones 2005-03-13 15:46:11 EST
the latest errata kernels have this driver disabled.
I'll leave it disabled until I (or someone else) gets time to fix the
driver upstream.
Comment 7 David Tonhofer 2005-04-08 20:43:06 EDT
I guess I figured out what this is about...

The way to reproduce is to change CPU frequency quickly, then copy
large files around. But prepare to run fsck as a powercycle will be necessary.
This on a VIA Nehemiah, stepping 8 using a recompiled kernel based on
2.6.10-1.770_FC3. For a couple of weeks I thought that recompilation with
CONFIG_MVIAC3_2=y had gotten rid of the hangs, but no. 

Change frequencies:

cd /sys/devices/system/cpu/cpu0/cpufreq/
while true; do
for freq in `cat scaling_available_frequencies`; do
   echo $freq > scaling_setspeed

Comment 8 Dave Jones 2005-07-15 16:15:39 EDT
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.
Comment 9 Dave Jones 2005-09-26 18:11:14 EDT
My current theory is that this is a gcc problem. The mass failures started to
appear around the time I converted longhaul.c to use bitfields.
At some point I'll convert upstream to using less funky C, and maybe this will
just resolve itself.  Until then, this driver is staying off in Fedora.

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