Bug 8228

Do you have either the acpi-cpufreq or speedstep-centrino module loaded ?
Can you attach the dmesg output ?

Created attachment 10839 [details]
dmesg output :)

If you need any more information please contact me. :)

I have loaded the following modules:

uwe@loopy2:~$ lsmod | grep cpufreq
cpufreq_stats           7360  0
cpufreq_ondemand        9228  0
cpufreq_userspace       5408  0
cpufreq_conservative     8200  0
freq_table              5792  2 cpufreq_stats,cpufreq_ondemand
cpufreq_powersave       2688  0

uwe@loopy2:~$ lsmod | grep acpi
sony_acpi               6284  0
pcc_acpi               13184  0
dev_acpi               12292  0
asus_acpi              17308  0
backlight               7040  1 asus_acpi

There are no modules matching "centrino" loaded.

please attach /proc/cpuinfo

Created attachment 10930 [details]
cat /proc/cpuinfo output

Someone of the Ubuntu Team has commited a patch but I don't want to recompile
my kernel so I need to wait until the patch gets merged into the standard
kernel. I'll report back as soon as this happens.

modprobe acpi-cpufreq should DTRT

FATAL: Error inserting acpi_cpufreq 
(/lib/modules/2.6.20-12-generic/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko): 
No such device

I don't know what DTRT means. :)

DTRT = "do the right thing" :-)

Please attach your /proc/acpi/dsdt
It appears your BIOS either lacks tables, or has broken ones.

Maybe the Intel folks can spot something that can be worked around, or failing
that, maybe there's a BIOS update available for your system.

The Ubuntu Kernel Team provided a fix. It was something about linux-phc 
tables.

merging linux-phc is not the right way to fix this.

I truly hope that Ubuntu haven't merged that stuff in their kernel.  Forking
whole subsystems (especially ones that are unlikely to ever get merged back)
isn't the way to get stuff fixed in the upstream kernel.

rather than just the DSDT, please attach the complete output from acpidump.
If the distro doesn't have it, you can get a copy of the acpidump
utility in the latest pmtools there:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

Created attachment 10944 [details]
dsdt.log

Created attachment 10945 [details]
acpidump log

i've attached the 2 output files.

DSDT shows no _PCT, _PSS, _PPC for P-state control,
but does show that an SSDT is supposed to be loaded
based on results of _PDC -- but dynamic SSDT is not
mentioned in the dmesg.

     Processor (CPU1, 0x01, 0x00000810, 0x06)
        {
            OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF)
            Name (NCPU, 0x00)
            Name (TYPE, 0x80000000)
            Name (HNDL, 0x80000000)
            Method (_PDC, 1, NotSerialized)
            {
                CreateDWordField (Arg0, 0x08, DAT0)
                Store (DAT0, TYPE)
                OperationRegion (PMRG, SystemIO, \PMBS, 0x50)
                Field (PMRG, ByteAcc, NoLock, Preserve)
                {
                            Offset (0x41),
                    DEV4,   1,
                    DEV5,   1,
                    DEV6,   1,
                    DEV7,   1,
                    STS4,   1,
                    STS5,   1,
                    STS6,   1,
                    STS7,   1
                }

                If (LAnd (LEqual (NCPU, 0x02), LEqual (And (TYPE, 0x0A),
                    0x0A)))
                {
                    Store (0x01, STS7)
                    Store (0x01, DEV7)
                    Load (SSDT, HNDL)
                }

                If (LAnd (LEqual (NCPU, 0x01), LEqual (And (TYPE, 0x01),
                    0x01)))
                {
                    If (LNot (And (TYPE, 0x10)))
                    {
                        Load (SSDT, HNDL)
                    }
                }
            }
        }

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

I'm unsure if Bug 8245 really is a duplicate as I'm was also using 6.10 Edgy 
and 6.06 Dapper and this bug was always present.
In Bug 8245 Daniel Swarbrick said:

> Under 2.6.17 (Ubuntu 6.10), speedstep-centrino loads successfully, and the
> frequency scales from 600MHz to 1.6GHz as it should. acpi-cpufreq fails to > 
> load
> with ENODEV.

For me it was the same problem as no - no scaling at all.

If there's any information needed please tell me. I don't have anything to do 
with kernels and stuff I'm just a normal Linux user. ;)

Created attachment 10951 [details]
dmesg log with current kernel with linux-phc

Oh I forgot to mention - the Kernel I'm using now is another one than the one I
was using when I first reported this Bug. The one I'm using now is the one with
Ubuntu's fix (about the linux-phc tables).
The one I'm using now is: 
2.6.20-13-generic #2 SMP
and I was using 2.6.20-12.

What I want to say is, the dmesg.log and cpuinfo.log where from another kernel
without the phc stuff.

I've attached the new dmesg output as dmesg2.log - maybe that explains the
differences. But as you know I absolutely don't know anything about kernel
stuff and how all that stuff works.

Created attachment 10955 [details]
dmesg output from 2.6.21rc5

Len, hope this is sufficient info for you. Kernel compiled with cpufreq debug
enabled, and booted with cpufreq.debug=7

You can see towards the end that speedstep-centrino and acpi-cpufreq still fail
to load, as they did pre-linux-phc patches.

Created attachment 10956 [details]
FULL dmesg output from 2.6.21rc5

Sorry, previous attachment seemed to chop first few lines. Guess it's bigger
than 64000 bytes!

>Len, hope this is sufficient info for you. Kernel compiled with cpufreq debug
>enabled, and booted with cpufreq.debug=7
Please
#echo 0x1f >/sys/module/acpi/parameter/debug_level
and modprobe the cpufreq driver again.
Hope we can get more information from the _dmesg_ output.

speedstep_lib was still loaded as module for me and a module for pentium 4 
processors, guess that was the issue.

adding acpi-cpufreq to the modules array in rc.conf fixed the issue and the 
faulty speedstep_lib didn't got loaded anymore

(i have a amilo m1439g which is pretty much equal to the m1437g, but i think 
it's a general centrino issue)

Created attachment 11339 [details]
Dmesg when wrong modules are loaded

Created attachment 11340 [details]
cpufreq-info with the wrong modules loaded

Created attachment 11341 [details]
lsmod when wrong modules are loaded

Created attachment 11342 [details]
dmesg with the right modules loaded

Created attachment 11343 [details]
cpufreq-info with the right modules loaded

Created attachment 11344 [details]
lsmod with the right modules loaded

Uh, how embarrassing, this was supposed to end up on the archlinux bugtracker. 
Well now I can at least give you some more infos as I am not sure if this is 
archlinux specific.

System is a Amilo M1439g which is equal to the M1437g except it has an Nvidia 
card instead of an ATI card

Telling the kernel to load acpi-cpufreq right at the start fixes the issue and 
no wrong module gets loaded

I've attached the output of dmesg, cpufreq-info and lsmod in the good and bad 
state

This is all on the fresh released 2.6.21 Kernel.

If there are any other infos you need I can upload them too, 

>>>            OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF)
                                                    ^^^^^^^^^^^^^^^^^^
This means cpu freq changing is disabled in BIOS settings. Please look there.

(In reply to comment #20)
> >Len, hope this is sufficient info for you. Kernel compiled with cpufreq
> debug
> >enabled, and booted with cpufreq.debug=7
> Please
> #echo 0x1f >/sys/module/acpi/parameter/debug_level
> and modprobe the cpufreq driver again.
> Hope we can get more information from the _dmesg_ output.

With 2.6.22-rc3, I'm unable to modprobe acpi or acpi-cpufreq ("No such device") and thus unable to echo the 0x1f debug flag. lsmod shows asus-acpi already loaded however.

Attaching an updated dmesg output.

Created attachment 11790 [details]
dmesg output from 2.6.22-rc3

Daniel,
Did you look at comment #29 or ignored it?
And yes, you can not "modprobe acpi", as it is compiled statically into kernel.
modprobe acpi-cpufreq will fail until you enable frequency scaling in BIOS, as per #29.
Regards,
Alex.

(In reply to comment #32)
> Daniel,
> Did you look at comment #29 or ignored it?
> And yes, you can not "modprobe acpi", as it is compiled statically into
> kernel.
> modprobe acpi-cpufreq will fail until you enable frequency scaling in BIOS,
> as
> per #29.
> Regards,
> Alex.
> 

I did not ignore comment #29, but there is no option in the BIOS of these laptops to enable frequency scaling. In the past it has always just worked, until speedstep-centrino was gutted sometime around 2.6.19.

I guess I may just have to resort to linux-phc patches again.

Then your issue is different from the one reported here. Open new bug and attach output of acpidump there. It is not possible to help you otherwise.

You mean this bug? http://bugzilla.kernel.org/show_bug.cgi?id=8245#c9

yes.
and you have same string in your DSDT:
"OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF)"

So, the only chance for you to get frequency control is to enable it in BIOS.

(In reply to comment #36)
> yes.
> and you have same string in your DSDT:
> "OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF)"
> 
> So, the only chance for you to get frequency control is to enable it in BIOS.
> 

...which as I've said, is not possible. There is no option whatsoever to enable/disable frequency scaling in these BIOSes. It's a pity that this is now broken, because up until 2.6.18, it worked fine.

<sigh> back to linux-phc... that's progress for ya.

Please post dmesg from 2.6.18, showing either acpi-cpufreq or speedstep-centrino working.

It does not work in 2.6.18. I said that it worked _up until_ 2.6.18 (ie, 2.6.17 and earlier). I've never seen acpi-cpufreq work on this hardware regardless, but speedstep-centrino used to work until it had its entrails ripped out in 2.6.18.

I will try to boot up a 2.6.17 livecd distro and get the evidence you ask for.

(In reply to comment #38)
> Please post dmesg from 2.6.18, showing either acpi-cpufreq or
> speedstep-centrino working.
> 

The dmesg output I'm about to attach does not show the speedstep_centrino driver loading (not verbose enough), but I will also attach an 'lsmod' output, and the output of the various cpufreq sysfs files.

I used Ubuntu 6.10 Desktop (livecd), which is a 2.6.17 kernel.

Created attachment 11803 [details]
dmesg output from 2.6.17

Created attachment 11804 [details]
lsmod output from 2.6.17

Created attachment 11805 [details]
sysfs entries for cpufreq on 2.6.17

ok, this looks promising, but Ubuntu kernel is known to be highly modified.
I think you still need to _compile_ 2.6.17 with cpufreq debug and acpi debug info. Could you also attach /proc/acpi/processor/* ?

(In reply to comment #44)
> ok, this looks promising, but Ubuntu kernel is known to be highly modified.
> I think you still need to _compile_ 2.6.17 with cpufreq debug and acpi debug
> info. Could you also attach /proc/acpi/processor/* ?
> 

Ok, I think the mystery is solved. Rather than compiling 2.6.17, I compared speedstep-centrino.c from Ubuntu's 2.6.17 kernel package, against the upstream source. Ubuntu have obviously patched it, adding freq/voltage tables for Pentium M Dothan cores (upstream only supports Banias). They've also done this in their 2.6.20 package for Feisty.

So I guess my notebook has broken ACPI BIOS, and the frequency scaling has only ever worked because of the linux-phc patches that Ubuntu were applying :(

Hopefully they'll at least keep doing that, to save me from having to patch it myself each time. I still don't understand why these patches for the Dothan cores have never made it into mainline...

There is a later BIOS for my notebook, released about two weeks after the version I was previously running (dated December 2004). There is nothing in the release notes about ACPI, but I thought I'd give it a crack anyway.

Wouldn't you know it... acpi-cpufreq loads fine, detects the frequencies available, and scales the clock speed. Even Windows no longer needs the Notebook Hardware Control app to scale the clock speed.

Well done Fujitsu-Siemens.... >:(

ok, thanks for information. Closing it now.

Thanks for following-up Daniel.
Curious that speedstep-centrino tables for Dothan
was what made this work for you in Ubuntu-2.6.17
and that upgrading the BIOS make acpi-cpufreq start working.
It makes one wonder what Windows would do with the old BIOS
on that machine.

As we haven't heard from Uwe, the original poster, in months,
we'll assume he's somehow magically happy with the upstream kernel
and we'll file this one into the broken BIOS bucket.