Bug 10062

It's still there (CONFIG_X86_LONGHAUL).  From the version number it looks like you're running a vendor kernel ?
Vendor kernels typically disable this module because it isn't very stable on some systems.  It works fine for some people, but for others they see lockups after a while.

Dave, thank you for your comment.  I have been enduring this problem for quite some time, trying out all kinds of different things in the process.  While you are right that normally I run a vendor-supplied kernel, I did test this with a couple of self-compiled kernels, too.  I'll try to do this again as soon as possible, but I don't expect any changes.

# grep -i longhaul /boot/config-2.6.22-14-386 
CONFIG_X86_LONGHAUL=m
# modprobe longhaul
FATAL: Error inserting longhaul (/lib/modules/2.6.22-14-386/kernel/arch/i386/kernel/cpu/cpufreq/longhaul.ko): No such device
# grep -i longhaul /var/log/syslog
Mar  7 12:30:51 Rie kernel: [3705563.931789] longhaul: VIA C3 'Samuel' [C5A] CPU detected.  Longhaul v1 supported.
Mar  7 12:30:51 Rie kernel: [3705563.931925] longhaul: No ACPI support. Unsupported northbridge.

So, it looks like the module is there, but it does not work as expected.

https://bugs.launchpad.net/bugs/50431 has some more information.

There was a commit that tried to deal with longhaul erratas:
commit 52a2638bff063acb28ba3355891c49cc240cc98b
Author: Rafal Bilski <rafalbilski@interia.pl>
Date:   Sun Oct 7 00:24:32 2007 -0700

    Longhaul: add auto enabled "revid_errata" option
    
    VIA C3 Ezra-T has RevisionID equal to 1, but it needs RevisionKey to be 0
    or CPU will ignore new frequency and will continue to work at old
    frequency.  New "revid_errata" option will force RevisionKey to be set to
    0, whatever RevisionID is.
    
    Additionaly "Longhaul" will not silently ignore unsuccessful transition.
    It will try to check if "revid_errata" or "disable_acpi_c3" options need to
    be enabled for this processor/system.
    
    Same for Longhaul ver.  2 support.  It will be disabled if none of above
    options will work.
    
     Best case scenario (with patch apllied and v2 enabled):
     longhaul: VIA C3 'Ezra' [C5C] CPU detected.  Longhaul v2 supported.
     longhaul: Using northbridge support.
     longhaul: VRM 8.5
     longhaul: Max VID=1.350  Min VID=1.050, 13 possible voltage scales
     longhaul: f: 300000 kHz, index: 0, vid: 1050 mV
     [...]
     longhaul: Voltage scaling enabled.
     Worst case scenario:
     longhaul: VIA C3 'Ezra-T' [C5M] CPU detected.  Powersaver supported.
     longhaul: Using northbridge support.
     longhaul: Using ACPI support.
     longhaul: VRM 8.5
     longhaul: Claims to support voltage scaling but min & max are both 1.250. Voltage scaling disabled
     longhaul: Failed to set requested frequency!
     longhaul: Enabling "Ignore Revision ID" option.
     longhaul: Failed to set requested frequency!
     longhaul: Disabling ACPI C3 support.
     longhaul: Disabling "Ignore Revision ID" option.
     longhaul: Failed to set requested frequency!
     longhaul: Enabling "Ignore Revision ID" option.

You can enable CPU_FREQ_DEBUG and place cpufreq.debug=2 for driver debug on the boot command line.

Closing as no response

Reopening.

What response are you looking for?  What's the open question even?

You have SiS northbridge. It probably doesn't have "stop BMDMA" bit. I can't be sure as the documentation for SiS chips isn't freely avalilable. I have docs for one and it doesn't have any useful bits.
Your BIOS doesn't support ACPI C3 state which could be used instead.
Sorry.

(In reply to comment #0)
> It seems the scaling for cpu scaling for VIA C3 CPUs has been missing from
> the
> Kernel for 2.6 kernels.  I am not exactly sure when this stopped working

Rafal, thank you for your comment.  This used to work, so it cannot be a hardware problem.

Alan, if you close the bug it would be common courtesy I think to at least leave a comment explaining things.

It was already mostly explained in comment #6

The early VIA C3 CPU scaling is extremely tricky and problematic at hardware level so was dropped from the kernel for the problem cases rather than risk causing corruption.