Skip to contentSkip to conversation

longhaul in 2.6.9 hangs VIA EPIA MII12000 when switching frequencies

DISCUSSION Petr Konecny 3 participants 3 messages Dec 6, 2004 – Dec 8, 2004

lore
Share & tools
lore
#0 lore raw

Hi,

the following script hangs my EPIA MII12000 within 5 seconds:
echo userspace > /sys/devices/system/cpu/cpu0/scaling_governor while true
do
echo 532000 > /sys/devices/system/cpu/cpu0/cpufreq echo 1197000 > /sys/devices/system/cpu/cpu0/cpufreq
done

When I run powernowd the system also crashes, usually when the CPU/disk load changes often. Unfortunately this machine is headless so I have no oops. Even netconsole is silent.

scaling_available_frequencies:
532000 1197000 598000 731000 798000 931000 1064000 665000 864000 997000 1130000 1197000

The motherboard has 1.2 GHz VIA Nehemiah CPU, cpu family 6, stepping 9. Loading longhaul prints:
longhaul: VIA C3 'Nehemiah C' [C5N] CPU detected. Powersaver supported.

I can do more tests upon request. Would compiling with debugging reveal any secrets ?

Thanks, Petr

#1 lore raw
Quoted 18 lines · Petr Konecny

Hi,

the following script hangs my EPIA MII12000 within 5 seconds:
echo userspace > /sys/devices/system/cpu/cpu0/scaling_governor while true
do
echo 532000 > /sys/devices/system/cpu/cpu0/cpufreq echo 1197000 > /sys/devices/system/cpu/cpu0/cpufreq
done

When I run powernowd the system also crashes, usually when the CPU/disk load changes often. Unfortunately this machine is headless so I have no oops. Even netconsole is silent.

scaling_available_frequencies:
532000 1197000 598000 731000 798000 931000 1064000 665000 864000 997000 1130000 1197000

Quoted 6 lines

The motherboard has 1.2 GHz VIA Nehemiah CPU, cpu family 6, stepping 9. Loading longhaul prints:
longhaul: VIA C3 'Nehemiah C' [C5N] CPU detected. Powersaver supported.

I can do more tests upon request. Would compiling with debugging reveal any secrets ?

Yup, I've managed to repeat this on my own Nehemiah too.
(For me, if I don't disable 'cpuspeed', the box dies within 5 minutes
of use). The bad news is, I've no idea what the problem is right now :-/

I'll keep poking at it. It might be worth trying older versions of the longhaul.c from earlier kernels and seeing if it ever worked properly. A few months ago, I had a handful of bug reports from users of older C3s, but my Nehemiah worked fine iirc. As time has gone on, it seems more and more people have found it to be broken. Either the number of people using longhaul.c has increased over time, or the quality of the driver has got worse and worse..

Dave

#2 lore raw

try compiling with CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI enabled

Dave,
FYI, I just checked this trivial patch into the acpi tree.

-Len

diff -Nru a/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c b/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
--- a/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 2004-12-08
00:41:55 -05:00
+++ b/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 2004-12-08
00:41:55 -05:00
@@ -249,7 +249,7 @@
/* Matched a non-match */
printk(KERN_INFO PFX "no table support for CPU model \"%s\": \n",
cpu->x86_model_id);
-#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI
+#ifndef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI
printk(KERN_INFO PFX "try compiling with
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI enabled\n");
#endif
return -ENOENT;