Bug 8228 - acpi-cpufreq does not load - Fujitsu Siemens Amilo M1425, M1437G - Intel(R) Pentium(R) M
Summary: acpi-cpufreq does not load - Fujitsu Siemens Amilo M1425, M1437G - Intel(R) P...
Status: CLOSED INVALID
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Alexey Starikovskiy
URL:
Keywords:
: 8245 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-03-18 09:27 UTC by Uwe Pfeifer
Modified: 2007-08-07 16:04 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.20
Tree: Mainline
Regression: ---


Attachments
dmesg output :) (29.22 KB, text/x-log)
2007-03-19 10:48 UTC, Uwe Pfeifer
Details
cat /proc/cpuinfo output (457 bytes, text/x-log)
2007-03-24 05:16 UTC, Uwe Pfeifer
Details
dsdt.log (18.57 KB, text/x-log)
2007-03-25 21:26 UTC, Uwe Pfeifer
Details
acpidump log (88.76 KB, text/x-log)
2007-03-25 21:28 UTC, Uwe Pfeifer
Details
dmesg log with current kernel with linux-phc (26.10 KB, text/x-log)
2007-03-26 13:06 UTC, Uwe Pfeifer
Details
dmesg output from 2.6.21rc5 (59.12 KB, text/plain)
2007-03-26 18:12 UTC, Daniel Swarbrick
Details
FULL dmesg output from 2.6.21rc5 (71.00 KB, text/plain)
2007-03-26 18:16 UTC, Daniel Swarbrick
Details
Dmesg when wrong modules are loaded (18.91 KB, text/plain)
2007-04-30 07:09 UTC, Karsten König
Details
cpufreq-info with the wrong modules loaded (753 bytes, text/plain)
2007-04-30 07:09 UTC, Karsten König
Details
lsmod when wrong modules are loaded (2.45 KB, text/plain)
2007-04-30 07:10 UTC, Karsten König
Details
dmesg with the right modules loaded (18.71 KB, text/plain)
2007-04-30 07:11 UTC, Karsten König
Details
cpufreq-info with the right modules loaded (719 bytes, text/plain)
2007-04-30 07:12 UTC, Karsten König
Details
lsmod with the right modules loaded (2.42 KB, text/plain)
2007-04-30 07:12 UTC, Karsten König
Details
dmesg output from 2.6.22-rc3 (33.16 KB, text/plain)
2007-06-18 22:06 UTC, Daniel Swarbrick
Details
dmesg output from 2.6.17 (26.34 KB, text/plain)
2007-06-19 20:53 UTC, Daniel Swarbrick
Details
lsmod output from 2.6.17 (3.43 KB, text/plain)
2007-06-19 20:53 UTC, Daniel Swarbrick
Details
sysfs entries for cpufreq on 2.6.17 (1.14 KB, text/plain)
2007-06-19 20:53 UTC, Daniel Swarbrick
Details

Description Uwe Pfeifer 2007-03-18 09:27:54 UTC
Most recent kernel where this bug did *NOT* occur: none.
Distribution: Ubuntu & OpenSuSE
Hardware Environment: see link
Software Environment: see link
Problem Description: CPU Scaling isn't working.

I have opened a bugreport at launchpad (bugreporting system of ubuntu)
and one of them told me to file the bug here and give you a link:
https://launchpad.net/bugs/93331

Steps to reproduce:
root@loopy2:~# /etc/init.d/powernowd restart
 * Stopping powernowd:                                                                                                                  
[ OK ]
 * Starting 
powernowd...                                                                                                                       /etc/init.d/powernowd: 
156: cannot create /sys/devices/system/cpu/cpu0//cpufreq/scaling_governor: 
Directory nonexistent
 * CPU frequency scaling not supported
Comment 1 Dave Jones 2007-03-18 12:33:59 UTC
Do you have either the acpi-cpufreq or speedstep-centrino module loaded ?
Can you attach the dmesg output ?
Comment 2 Uwe Pfeifer 2007-03-19 10:48:48 UTC
Created attachment 10839 [details]
dmesg output :)

If you need any more information please contact me. :)
Comment 3 Uwe Pfeifer 2007-03-19 10:55:36 UTC
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.
Comment 4 Dave Jones 2007-03-20 08:16:27 UTC
please attach /proc/cpuinfo
Comment 5 Uwe Pfeifer 2007-03-24 05:16:28 UTC
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.
Comment 6 Dave Jones 2007-03-24 15:45:32 UTC
modprobe acpi-cpufreq should DTRT
Comment 7 Uwe Pfeifer 2007-03-25 00:42:11 UTC
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. :)
Comment 8 Dave Jones 2007-03-25 12:25:06 UTC
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.
Comment 9 Uwe Pfeifer 2007-03-25 15:04:47 UTC
The Ubuntu Kernel Team provided a fix. It was something about linux-phc 
tables.
Comment 10 Dave Jones 2007-03-25 17:52:52 UTC
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.
Comment 11 Len Brown 2007-03-25 20:12:09 UTC
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/
Comment 12 Uwe Pfeifer 2007-03-25 21:26:50 UTC
Created attachment 10944 [details]
dsdt.log
Comment 13 Uwe Pfeifer 2007-03-25 21:28:08 UTC
Created attachment 10945 [details]
acpidump log

i've attached the 2 output files.
Comment 14 Len Brown 2007-03-26 09:46:35 UTC
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)
                    }
                }
            }
        }
Comment 15 Len Brown 2007-03-26 09:49:37 UTC
*** Bug 8245 has been marked as a duplicate of this bug. ***
Comment 16 Uwe Pfeifer 2007-03-26 12:52:17 UTC
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. ;)
Comment 17 Uwe Pfeifer 2007-03-26 13:06:57 UTC
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.
Comment 18 Daniel Swarbrick 2007-03-26 18:12:40 UTC
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.
Comment 19 Daniel Swarbrick 2007-03-26 18:16:15 UTC
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!
Comment 20 Zhang Rui 2007-04-12 02:08:24 UTC
>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.
Comment 21 Karsten König 2007-04-30 06:42:05 UTC
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)
Comment 22 Karsten König 2007-04-30 07:09:15 UTC
Created attachment 11339 [details]
Dmesg when wrong modules are loaded
Comment 23 Karsten König 2007-04-30 07:09:58 UTC
Created attachment 11340 [details]
cpufreq-info with the wrong modules loaded
Comment 24 Karsten König 2007-04-30 07:10:43 UTC
Created attachment 11341 [details]
lsmod when wrong modules are loaded
Comment 25 Karsten König 2007-04-30 07:11:26 UTC
Created attachment 11342 [details]
dmesg with the right modules loaded
Comment 26 Karsten König 2007-04-30 07:12:05 UTC
Created attachment 11343 [details]
cpufreq-info with the right modules loaded
Comment 27 Karsten König 2007-04-30 07:12:40 UTC
Created attachment 11344 [details]
lsmod with the right modules loaded
Comment 28 Karsten König 2007-04-30 07:14:35 UTC
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, 
Comment 29 Alexey Starikovskiy 2007-06-05 01:18:08 UTC
>>>            OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF)
                                                    ^^^^^^^^^^^^^^^^^^
This means cpu freq changing is disabled in BIOS settings. Please look there.
Comment 30 Daniel Swarbrick 2007-06-18 22:06:05 UTC
(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.
Comment 31 Daniel Swarbrick 2007-06-18 22:06:36 UTC
Created attachment 11790 [details]
dmesg output from 2.6.22-rc3
Comment 32 Alexey Starikovskiy 2007-06-18 23:15:50 UTC
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.
Comment 33 Daniel Swarbrick 2007-06-18 23:32:21 UTC
(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.
Comment 34 Alexey Starikovskiy 2007-06-19 01:20:09 UTC
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.
Comment 35 Daniel Swarbrick 2007-06-19 01:54:22 UTC
You mean this bug? http://bugzilla.kernel.org/show_bug.cgi?id=8245#c9
Comment 36 Alexey Starikovskiy 2007-06-19 02:05:01 UTC
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.
Comment 37 Daniel Swarbrick 2007-06-19 03:40:59 UTC
(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.
Comment 38 Alexey Starikovskiy 2007-06-19 03:44:14 UTC
Please post dmesg from 2.6.18, showing either acpi-cpufreq or speedstep-centrino working.
Comment 39 Daniel Swarbrick 2007-06-19 18:43:29 UTC
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.
Comment 40 Daniel Swarbrick 2007-06-19 20:52:29 UTC
(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.
Comment 41 Daniel Swarbrick 2007-06-19 20:53:12 UTC
Created attachment 11803 [details]
dmesg output from 2.6.17
Comment 42 Daniel Swarbrick 2007-06-19 20:53:37 UTC
Created attachment 11804 [details]
lsmod output from 2.6.17
Comment 43 Daniel Swarbrick 2007-06-19 20:53:58 UTC
Created attachment 11805 [details]
sysfs entries for cpufreq on 2.6.17
Comment 44 Alexey Starikovskiy 2007-06-20 02:06:57 UTC
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/* ?
Comment 45 Daniel Swarbrick 2007-07-05 04:28:03 UTC
(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...
Comment 46 Daniel Swarbrick 2007-07-05 16:55:54 UTC
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.... >:(
Comment 47 Alexey Starikovskiy 2007-07-08 23:52:12 UTC
ok, thanks for information. Closing it now.
Comment 48 Len Brown 2007-08-07 16:04:46 UTC
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.

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