Bug 7578

Created attachment 9614 [details]
acpidump hex

Created attachment 9615 [details]
acpidump -b  (binary output)

Created attachment 9616 [details]
acpidump (hex output)

Created attachment 9617 [details]
kernel configuration

Created attachment 9618 [details]
dmesg output

Neither of the drivers can work on your computer, because your BIOS indeed 
does not have any ACPI objects to support P-states.
can you do this test:
dmesg -c
#echo 7 >/sys/module/cpufreq/parameters/debug
#echo 0x1f >/proc/acpi/debug_level
insmod the two drivers and attatch each _dmesg_ output?

Created attachment 9739 [details]
/proc/cpuinfo

Created attachment 9740 [details]
acpi-cpufreq_module

Created attachment 9741 [details]
speedstep-centrino_module

Thanks for having a look at my problem

Well, can you use the acpidump tool below and attatch your _acpidump_ again?
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils
Dmesgs show that maybe you have a totally different ACPI namespace from the 
one you attatched before. :)

Created attachment 9743 [details]
All the tests redone with a vanilla 2.6.19 kernel

By mistake I made those last tests with a gentoo kernel, there are no acpi
related patches in there
(http://dev.gentoo.org/~dsd/genpatches/patches-2.6.19-1.htm) though.
Sorry for that :-).

I've redone everything using a vanilla 2.6.19 kernel now.

Please
#acpidump --addr 0x7ffc8870 --length 0xcc3 >CPU1-STBL
#acpidump --addr 0x7ffc9540 --length 0x4a4 >CPU2-STBL
and attach these two STBLs, :)
I think they may contain some critical information for cpufreq support.

Created attachment 9753 [details]
CPU1-STBL  CPU2-STBL

buggy BIOS.
According to _PSS package shown in this BIOS, several P-states with the same 
control value( the value to be written to the Performance Control Register in 
order to initiate a transition to the performance state) are supported. This 
is a bug and causes the failure of speedstep-centrino driver.
Can you check if there are any BIOS updates?

Created attachment 9798 [details]
new bios

There actually was a new bios out, but it doesn't make speedstep work :-(.
I redid everything with the new bios applied...

Maybe you could have a look at it to see if anything has changed ?

I'll try to contact Asus if this is still a bios problem.

Thanks a lot.

the base addr and length of the STBLs are changed. :)
try this one:
#acpidump --addr 0x7ffc8960 --length 0xcc3 >CPU1-STBL
#acpidump --addr 0x7ffc9630 --length 0x4a4 >CPU2-STBL

From the dmesg, I think it's still a bios bug. :(
Anyway, let's check the STBLs first. :)

Created attachment 9801 [details]
STBLs

IMO, it's a BIOS problem, caused by the buggy _PSS package as I described 
before. :(. Please contact Asus.
If there are any breakthroughs, do remember to let me know. :)

Ah that's bad :-(.
I already contacted them also refering to this page.

Thank you very much for your help, and of course I'll let you know should I hear 
something from Asus :-).

Hello!

I hafe the same probem on my MAXDATA 8100IWS Notebook.

By loading acpi-cpufreq or speedstep-centrino I get only "No such device".

But I dont know if this bug is from BIOS or orthers?!

I attach my acpi for debugging.

Created attachment 9871 [details]
my acpidump

Please do the same tests in comment#6 and attach the dmesg output.

sorry, but when i execute "echo 7 >/sys/module/cpufreq/parameters/debug" i get
"/sys/module/cpufreq/parameters/debug: no such file or dir"

and the same on "echo 0x1f >/proc/acpi/debug_level"

My Distribution is SuSE 10.2 with standard kernel 2.6.18.2-34-default

I boot to my debian system and try again.

sorry.. on my debian box there is the same result with standard kernel from etch
(2.6.18-3-686)

Please tell me, what kernel options i hafe to set for recompiling? 

Please set CONFIG_ACPI_DEBUG and CONFIG_CPU_FREQ_DEBUG if they are not set.
Or you can attach the your kconfig file first. :)

Ok.. i found the options:

* Power Management Debug Support 
* Enable CPUfreq debugging
* ACPI > Debug Statements

Kernel 2.6.19 is building

OK.. now I hafe made the files from dmesg output.

Created attachment 9887 [details]
dmesg output speedstep-centrino-MAXDATA-8100IWS-BIOS-1.11

Created attachment 9888 [details]
dmesg output acpi-cpufreq-MAXDATA-8100IWS-BIOS-1.11

Well, buggy BIOS again.
Methods for P-state support can not be found in this BIOS.
>OperationRegion (STBL, SystemMemory, 0xFFFF0000, 0xFFFF)
wrong base_addr and length for dynamic loaded tables.

>Methods for P-state support can not be found in this BIOS.

OK thanks, my company are Maxdata-Service-Partner. I contact Maxdata and tell
this bug.

Created attachment 9923 [details]
dmesg from speedstep-centrino modul after bios reset

Hi,

i found the solution for my Problem. After BIOS Reset i can load the
speedstep-centrino driver. I show on BIOS Settings, but there is no Option to
activate/deactivate some CPU Options.

I think by experimenting with the suspend-states or so that the BIOS become
some buggy settings?!

Thanks for your help,

Thomas

I just did a reset to manufacturer defaults in the bios, but unfortunately that didn't 
change anything for me :-(.

Btw, I tried to contact ASUS.
Of course there was just a support guy who tried to run his checklist down and when 
I repeatedly asked him to forward my mail to their tech-department, he finaly told me 
that he spoke to someone and that if there was something wrong they would have 
already corrected it.

Nice answer :-/

to Thomas Creutz :
Can you attach your acpidump again with the right BIOS setting?
to Georges Toth:
Maybe you can check your BIOS setting, escepially the options related to ACPI 
or CPU.
You can describe them here if you are not sure about some of the BIOS options.

to zhang rui:
There are only very limited settings available in this bios (AMI bios).
Here's a list:
Main
    date & time

Advanced
    IDE Configurations
    IR port
    Easy Flash
    Internal pointing device
    Internal num pad

Security
    ....

Power
    LCD power saving
    Start battery calibration

Boot
    ->  set boot sequence

Exit
    ...

Nothing related to acpi or apic or pnp or cpu etc...

What I'm wondering is if those power and frequency states aren't always the same 
for the same model of cpu's ?

In case they are, wouldn't it be possible to hack a patch to support my system by the 
linux cpu-freq modules even though the bios is buggy ?

I know that is not really how it should be done, but that might be the only solution for 
me to get cpu-freq to work on my laptop as I'm not really sure whether asus will ever 
release a working bios.

OK, I'll have a try.
But that may take some time as I'm a little busy recently.

to zhang rui:
That's no problem.
Thanks a lot for trying !!! :-)

Created attachment 9937 [details]
my acpidump after reset

Hi,

sorry for delay, but I had to much to do...

Merry X-Mas !

Thomas

one hint to Georges Toth:

try to plug off the power and the battery for ~ 5 - 10 minutes.

And than go the bios defaults and try again.

Thomas

I have ASUS A8Jp too. And have same problem.
New bios is out:

BIOS 208
Support Vista, include SLP2.0, ASUS RCD, TPM.
Support T5500, T5600 L2 stepping CPU.

but CPUfreq still not working:# modprobe speedstep-centrino
FATAL: Error inserting speedstep_centrino 
(/lib/modules/2.6.18.2-34-default/kernel/arch/x86_64/kernel/cpufreq/speedstep-centrino.ko): 
No such device
# modprobe acpi-cpufreq
FATAL: Error inserting acpi_cpufreq 
(/lib/modules/2.6.18.2-34-default/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko): 
No such device

OS OpenSUSE 10.2 x86-64 with default kernel.

I am having the same problems on an Asus A8Js.

to Ildar Nurislamov and Nicholas Doyle :
If you have the similar problem, open another bug report and attach your 
acpidump, full dmesg output, kernel config and do the test in comment #6. :)

to Thomas Creutz :
Thanks. And can you help me to do this test:
#acpidump --addr 0x7ffc5400 --length 0x448 >TC-CPU1-STBL
#acpidump --addr 0x7ffc5850 --length 0x43f >TC-CPU2-STBL
This will show me what makes your laptop works well.
And I want to make a comparison between the two BIOS. Thanks.

to Thomas Creutz :
I tried that but it didn't help.

I actually got an Asus A8js, not A8jp .... I always confuse those two :-)
Asus has released another 2 new bios's, unfortunately the latest one still doesn't 
solve this problem.

Created attachment 9945 [details]
workaround duplicated P-state gotten from _PSS package

to Georges Toth:
Can you try this patch?
#echo 7 >/sys/module/cpufreq/parameters/debug
insert speedup-centrino driver and attach the dmesg output.
Ideally it will make your cpufreq driver work.
If it fails, at least we can get some interesting messages. :)
Others please don't try this patch, as it only workarounds Georges Toth's
problem.

Created attachment 9946 [details]
dmesg ouput after applying the path

AWESOME!!! :-)
Thank you so much, cpufreq works great now :-)

Created attachment 9948 [details]
TC-CPU1+2-STBL

Hello Zhang Rui,

thats my output from acpidump.

Thomas

Patch from #46 worked for me on my Asus A8Js. CPUFreq works great now.

Asus A8JP have only one diff from A8Js - NVidia Video adapter instead of ATI.
I have same CPU Core2Duo 7200

I've compiled 2.6.18.5 kernel with your path and now CPUfreq works for me too 
:)
Lot of thanks!
Waiting for fixes in main tree.

ACPI: (supports S0 S1 S3 S4 S5)
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [   AMI] OemTableId [  CPU1PM] 
[20060707]
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU1] (supports 8 throttling states)
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [   AMI] OemTableId [  CPU2PM] 
[20060707]
ACPI: CPU1 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU2] (supports 8 throttling states)

Why only 2 power states detected? Afaik Core 2 Duo supports C3, C4

Hello guys,
Excited about getting so much good news this morning. :)
This patch only workarounds the problem on Asus A8Js which offers an incorrect 
_PSS package in the BIOS.
So this is not a software bug and it won't come into the main tree.

Created attachment 9950 [details]
the same function but more clean

Last patch doesn't print the information I want.
Fixed in this one.

Thomas, that's exactly what I want, thanks for your help.

Just a bit of info: on my installation (Debian, kernel 2.6.18-3-686, Asus A8Jp) the 
#modprobe speedstep_centrino
works OK without any patch. The BIOS version is relatively old (I didn't upgrade it)

That's interesting. :)
Kirill, can you attach your acpidump output please?

new bios released for A8Jp BIOS 209. But bug not fixed.
Is it real that something wrong in BIOS?
 zhang rui, can you fully describe technical info about error in the BIOS 
without usage word "Linux" (ASUS officially don't support Linux in notebooks)
only info about how ACPI doesn't meet standards.
I'll post this info to ASUS support.

Hello, IOK, in fact, the problem we talked about is that the DSDT offered by 
BIOS has something conflicts with ACPI specification.

First, processor performance control(P-state) is implemented through three 
optional objects(_PCT,_PSS and _PPC) whose presence indicates to OSPM that the 
platform and CPU are capable of supporting multiple performance states. 

Here is the description of _PSS in ACPI spec:
This optional object indicates to OSPM the number of supported processor 
performance states that any given system can support. This object evaluates to 
a packaged list of information about available performance states.
And each elements of this package contain six parameters.

Thanks. I've posted this text to forum and support.

Hi again,

i see also, that my Debian runns without the C3 and C4 states.

ACPI (exconfig-0455): Dynamic SSDT Load - OemId [   AMI] OemTableId [  CPU1PM]
[20060707]
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI (exconfig-0455): Dynamic SSDT Load - OemId [   AMI] OemTableId [  CPU2PM]
[20060707]
ACPI: CPU1 (power states: C1[C1] C2[C2])

Also i hafe the problem, thats the Notbook Fan run and run and run... and this
makes me not so happy.

I found on the Internet a Howto [1], who describes how whe can fix the DSDT.
But i cant fix the error. Is it right, that when this Errors are be fixed, that
linux can detect the rigth powerstates?

I see, that my BIOS also was compiled with the Windows Compilier.

nbtxc:/root# dmesg | grep '@ 0x'
ACPI: RSDP (v002 ACPIAM                                ) @ 0x000f8c10
ACPI: XSDT (v001 A M I  OEMXSDT  0x09000627 MSFT 0x00000097) @ 0x7ffc0100
ACPI: FADT (v003 A M I  OEMFACP  0x09000627 MSFT 0x00000097) @ 0x7ffc0290
ACPI: MADT (v001 A M I  OEMAPIC  0x09000627 MSFT 0x00000097) @ 0x7ffc0390
ACPI: MCFG (v001 A M I  OEMMCFG  0x09000627 MSFT 0x00000097) @ 0x7ffc03f0
ACPI: OEMB (v001 A M I  AMI_OEM  0x09000627 MSFT 0x00000097) @ 0x7ffce040
ACPI: TCPA (v001 A M I  TBLOEMID 0x00000001 MSFT 0x00000097) @ 0x7ffc53c0
ACPI: DSDT (v001  X51IA X51IA001 0x00000001 INTL 0x02002026) @ 0x00000000

But not the DSDT?! Nevertheless the iasl reports me 3 errors and 9 warnings.

Can someone help to fix the errors? And a other question: I use my distribion
kernel 2.6.18 (Debian Etch). Are some changes for powersaving/acpi on the 2.6.20
or 2.6.21 who get me better support for my PC?

Thanks for help,
I attach my decompiled DSDT to this Bug Report.

Thomas

[1] http://forums.gentoo.org/viewtopic.php?t=122145

Created attachment 11158 [details]
my DSDT

Hi, Thomas,
New cpuidle driver is created for processor c-state control recently.
So why not try 2.6.21-rc7?

Created attachment 11257 [details]
patch-1 : add sysfs for acpi tables

Created attachment 11258 [details]
patch-2 : add sysfs for acpi tables

Please apply these two patches.
Then attach all the SSDT tables shown in /sys/firmware/acpi/tables.

ok.. let me see..

i do the follow thinks:

get linux-2.6.20.tar.bz2
get patch-2.6.21-rc7.bz2
unpack linux-2.6.20 and patch with patch-2.6.21-rc7 and your 2 patches and then
build the kernel?

Some extra options I have to set?

No. :)

Created attachment 11333 [details]
my tables

Hi.. sorry for longe time away.. but i had not mutch time any 3 times i
compile, the notebook shut down, while it was to hot.

Now the kernel 2.6.21-rc7-686 is ready with your patches.

hmm.. back again...

i look a bit in dmesg and see this...

CPU: After generic identify, caps: bfebfbff 20100000 00000000 00000000 0000e3bd
00000000 00000001
monitor/mwait feature present.
using mwait in idle threads.
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU: After all inits, caps: bfebfbff 20100000 00000000 00003940 0000e3bd
00000000 00000001
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
CPU0: Intel(R) Core(TM)2 CPU         T7200  @ 2.00GHz stepping 06
SMP alternatives: switching to SMP code
Booting processor 1/1 eip 3000
Initializing CPU#1
Calibrating delay using timer specific routine.. 3990.31 BogoMIPS (lpj=7980622)
CPU: After generic identify, caps: bfebfbff 20100000 00000000 00000000 0000e3bd
00000000 00000001
monitor/mwait feature present.
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU: After all inits, caps: bfebfbff 20100000 00000000 00003940 0000e3bd
00000000 00000001
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel(R) Core(TM)2 CPU         T7200  @ 2.00GHz stepping 06
Total of 2 processors activated (7983.65 BogoMIPS).
[..]
ACPI Warning (tbutils-0158): Incorrect checksum in table [SSDT] -  16, should be
7F [20070126]
ACPI: SSDT 7FFC5400, 0448 (r1    AMI   CPU1PM        1 INTL 20050930)
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI Warning (tbutils-0158): Incorrect checksum in table [SSDT] -  0D, should be
1D [20070126]
ACPI: SSDT 7FFC5850, 043F (r1    AMI   CPU2PM        1 INTL 20050930)
ACPI: CPU1 (power states: C1[C1] C2[C2])
ACPI: Thermal Zone [THRM] (50 C)
Time: acpi_pm clocksource has been installed.

New P-States are not activated..

nbtxc:/usr/src/linux# grep -i cpu .config
CONFIG_CPUSETS=y
CONFIG_NR_CPUS=8
CONFIG_X86_CPUID=m
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_HOTPLUG_CPU=y
CONFIG_ACPI_HOTPLUG_CPU=y
# CONFIG_APM_CPU_IDLE is not set
# CPU Frequency scaling
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=m
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=m
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
# CPUFreq processor drivers
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_CPUFREQ_NFORCE2=m
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_CPU5_WDT=m


Now i compile 2.6.21.1 and try again...

sorry... i mean C-States not P-States :-/

>i see also, that my Debian runns without the C3 and C4 states.
please unplug the AC power and cat /proc/acpi/processor/*/*
Are there more C-states available then?

>but i had not mutch time any 3 times i compile,
>the notebook shut down, while it was to hot.
This seems to be the real problem.
Did you config the ACPI thermal and fan driver as well?
If so, I'd like to get the dmesg output when you laptop get hot.

>>i see also, that my Debian runns without the C3 and C4 states.
>please unplug the AC power and cat /proc/acpi/processor/*/*
>Are there more C-states available then?
On 2.6.21.1-686 there change nothing. Should I test also with the 2.6.21-rc7-686?

nbtxc:~# cat /proc/acpi/processor/*/*
processor id:            0
acpi id:                 1
bus mastering control:   no
power management:        yes
throttling control:      no
limit interface:         no
<not supported>
active state:            C2
max_cstate:              C8
bus master activity:     00000002
maximum allowed latency: 2000 usec
states:
    C1:                  type[C1] promotion[C2] demotion[--] latency[001]
usage[00000010] duration[00000000000000000000]
   *C2:                  type[C2] promotion[--] demotion[C1] latency[001]
usage[00173569] duration[00000000001444225642]
<not supported>
processor id:            1
acpi id:                 2
bus mastering control:   no
power management:        yes
throttling control:      no
limit interface:         no
<not supported>
active state:            C2
max_cstate:              C8
bus master activity:     00040001
maximum allowed latency: 2000 usec
states:
    C1:                  type[C1] promotion[C2] demotion[--] latency[001]
usage[00000010] duration[00000000000000000000]
   *C2:                  type[C2] promotion[--] demotion[C1] latency[001]
usage[00184664] duration[00000000001640280102]
<not supported>


>>but i had not mutch time any 3 times i compile,
>>the notebook shut down, while it was to hot.
>This seems to be the real problem.
>Did you config the ACPI thermal and fan driver as well?

i dont think... it was ondemand or performance. but my thermal information from
/proc/acpi/thermal_zone/THRM/temperature says all the time 50 C and nothing
change... But i think, in Windows was this the same with NHC (Notebook Hardware
Control)

At the moment with powersave profil the noteook fan is not very loud, so i think
the thermal is good.. :-)

>If so, I'd like to get the dmesg output when you laptop get hot.
hmm.. there is no output so see.. i think the "shutdown" was interuptet from cpu
or bios.. ok it was not an shutdown... it was an stop/poweroff.

Same here, with a twist ... (E6600 on ASUS P5B-VM DO, Debian kernel 2.6.18-4)

I have an option to set the 'ACPI version' in BIOS to either of 1.0, 2.0 or 3.0.
With the first one speedstep-centrino loads, even if there's strange stuff going
on with the freq of the second core either not being changed or not being
displayed correctly.

I have Asus G1 with newest BIOS and I have the same error.
"the same function but more clean" patch helps, and cpufreq-info shows multiple
frequencies:
available frequency steps: 1.99 GHz, 1.99 GHz, 1.99 GHz, 1.99 GHz, 1.99 GHz,
1.99 GHz, 1.99 GHz, 1.66 GHz, 1.33 GHz, 996 MHz

Is there a way to deal with this issue by correcting DSDT file? I have modified
DSDT anyway, because of other bugs in it...

Is this patch planned to be submitted? or some other one or based on the input on Asus boards?
Thanks -
--N.

Hello,
Are there any bios updates from Asus for this issue?
If not, I'll send a patch to check the dmi code of these platforms.
Can you guys attach the dmidecode of Asus A8Jp/A8Js/G1 please?

Hi,
No, unfortunately there is no bios update or any kind of support from asus on this matter.
Please find attached my dmidecode for the Asus A8JS.

Thanks for helping us ! :-)

ps: when could we expect that patch to be included ? is it possible (if not too time consuming) to have it backported to 2.6.22 (or 23) ?

Created attachment 12724 [details]
dmidecode for the Asus A8JS

>when could we expect that patch to be included ?
I'm not sure. :(. Need some test first. :)
> is it possible (if not too time consuming) to have it backported to 2.6.22
> (or 23) ?
That's not difficult. we can do this after it's merged.

Hello,

I suspect those asus platforms aren't the only ones with the problem. I have a Z62J with the same issue. Is it possible to also include a fix for it?

Thanks!

Created attachment 12732 [details]
dmidecode for the asus Z62J

Here's my dmidecode for the asus Z62J.

Created attachment 12751 [details]
Patch-override-invalid-_PSS-package

Hi, Georges,
Please verify if this patch works for you. :)

Renato,
In order to verify if Z62J has the same problem, please do the following test:
#dmesg -c
#echo 7 >/sys/module/cpufreq/parameters/debug
#echo 0x1f >/proc/acpi/debug_level
modprobe the acpi-cpufreq driver and attatch _dmesg_ output.

>I suspect those asus platforms aren't the only ones with the problem.
Yes, but I'm not sure how to distinguish ASUS laptops with this problem,
So I use the DMI_BOARD_VENDOR and DMI_BOARD_NAME for now.
We need to collect the dmidecode with the same problem first. :)

Created attachment 12752 [details]
Asus Z62J modprobe dmesg output

Hi Rui,

Thanks!, that was fast :-)
Should I also apply that older patch (the one I've been using so far for getting cpufreq to work) ?

Hi, Renato,
This seems to be another problem.
can you attach the acpidump output please?

Georges,
Pleas revert the older patch and apply this one. :)

(In reply to comment #85)
> Hi, Renato,
> This seems to be another problem.
Oh.. Sorry..

> can you attach the acpidump output please?
Sure. If I redirect the output to a file I get this:

$ acpidump > acpi.dump
Wrong checksum for generic table!

Created attachment 12753 [details]
Asus Z62J acpidump output

I got a "Wrong checksum for generic table!" message from acpidump. Probably that's the issue..

Hi Rui,

Your patch works great :-)
I'm not sure, but it seems my laptop is much more quiet now, cpufreq works and throttling as well! (throttling hasn't been working before).

Here are 2 warnings I get in dmesg:
ACPI Warning (tbutils-0158): Incorrect checksum in table [SSDT] -  83, should be 26 [20070126]
ACPI Warning (tbutils-0158): Incorrect checksum in table [SSDT] -  F3, should be B9 [20070126]


Thanks again

Georges,
Please make sure the latest bios still doesn't work
for you without patch in comment #81 applied.

Sorry for the late reply.
There hasn't been a new bios release for many months.
I've tested a 2.6.21.7 vanilla kernel today, and *very* strangely cpufreq works and throttling as well.
I still get those warnings mentioned in my previous post.

Any idea how that's possible ? :-)
(No I haven't changed anything in the bios since, and there isn't much to change anyway...in case you would ask :-) )

That's interesting.
Can you attach the mainline kernel dmesg output after boot please?
and the vanilla kernel dmesg output after cpufreq driver is loaded as well,
with the boot option "cpufreq.debug=7". :)

Created attachment 13178 [details]
acpi-cpufreq.ko not loaded, vanilla kernel

This is the output I get on a 2.6.23.1 vanilla kernel
(acpi-cpufreq.ko is not loaded)

Created attachment 13179 [details]
acpi-cpufreq.ko loaded and debug set to 7

Again the dmesg output of an unpatched 2.6.23.1 kernel, this time with the "cpufreq.debug=7" boot option.

(In reply to comment #81)
> Created an attachment (id=12751) [details]
> Patch-override-invalid-_PSS-package
> 
> Hi, Georges,
> Please verify if this patch works for you. :)
> 

Just pitching in that that patch (while adding the follow block to it) solves a similar problem for the Asus F3Jv laptop:

        {
         .callback = asus_get_performance_status,
         .ident = "Asus F3JV",
         .matches = {
                DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer Inc."),
                DMI_MATCH(DMI_BOARD_NAME, "F3JV"),
                },
        },

The background for the F3Jv is that in version 201 (and potentially 202, I never managed to get that) of it's BIOS, there were just duplicate P-states (as with the original bug), so the "same function but more clean" patch worked - however, starting with either version 202 or 203, that was no longer the problem - until finding this patch, I've been unable to work around it.

You're a lifesaver, Zhang - unfortunately, I have some programs which I need Windows for, and Windows Vista is only supported with BIOS 203+. Having to re-flash my BIOS every time I wanted to switch OS was meaning I was spending more and more time away from Linux.

Hi,Georges,

>acpi-cpufreq:      *P0: 1998 MHz, 31000 mW, 10 uS
>acpi-cpufreq:       P1: 1997 MHz, 31000 mW, 10 uS
>acpi-cpufreq:       P2: 1996 MHz, 31000 mW, 10 uS
>acpi-cpufreq:       P3: 1995 MHz, 31000 mW, 10 uS
>acpi-cpufreq:       P4: 1994 MHz, 31000 mW, 10 uS
>acpi-cpufreq:       P5: 1993 MHz, 31000 mW, 10 uS
>acpi-cpufreq:       P6: 1992 MHz, 31000 mW, 10 uS
First, they're duplicate because they use the same value to write to the Performance Control Register.
Second, the current acpi-freq driver seems to recognise them as differenct P-states.
Anyway, the acpi-cpufreq driver can work on your laptop after all, right?
The cpu freq driver may not work perfectly on your laptop. Eg. it may switch the P-state from P0 to P1 although they are actually the same.
As this is a BIOS bug and we don't get a generic way to fix the problem, I'll close this bug and mark it as WILL_NOT_FIX.

Hi Rui,

You're right, on recent kernels the acpi module works without any patch.
There are no more kernel errors as it was the case with older kernels and the frequency switching seems to work according to the kpowersave.

I'm not really sure why it suddenly works, but well it does :-) (_no_ bios update or something..).

Thanks for the time you put into this... You can close this bug.