Bug 140873

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.

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.

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

*** Bug 146690 has been marked as a duplicate of this bug. ***

"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

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.

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
done
done

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.

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.