Bug 9558 (buggyasusbios) - AE_AML_PACKAGE_LIMIT, Evaluating _PSS - Frequency scaling not working after BIOS upgrade on Asus F3jc
Summary: AE_AML_PACKAGE_LIMIT, Evaluating _PSS - Frequency scaling not working after B...
Status: CLOSED CODE_FIX
Alias: buggyasusbios
Product: ACPI
Classification: Unclassified
Component: Power-Processor (show other bugs)
Hardware: All Linux
: P1 low
Assignee: Lin Ming
URL:
Keywords:
: 8298 10299 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-12-13 22:58 UTC by Giovanni Toraldo
Modified: 2008-05-21 17:18 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.23.1-custom
Tree: Mainline
Regression: ---


Attachments
dmesg log (22.73 KB, text/plain)
2007-12-13 23:00 UTC, Giovanni Toraldo
Details
dmidecode log (11.28 KB, text/x-log)
2007-12-13 23:00 UTC, Giovanni Toraldo
Details
lspci log (20.47 KB, text/x-log)
2007-12-13 23:01 UTC, Giovanni Toraldo
Details
acpidump of the buggy bios (166.19 KB, text/x-log)
2007-12-15 12:08 UTC, Giovanni Toraldo
Details
acpidump of the bios not raising any error (152.18 KB, text/x-log)
2007-12-15 12:09 UTC, Giovanni Toraldo
Details
acpidump as requested (1011 bytes, application/x-gzip)
2007-12-17 07:14 UTC, Giovanni Toraldo
Details
ASUS F3JC SSDT for BIOS version 305 (3.29 KB, application/octet-stream)
2007-12-19 06:49 UTC, Fabien Crespel
Details
dmesg with acpi/cpufreq debug enabled (24.44 KB, text/plain)
2007-12-28 03:56 UTC, Giovanni Toraldo
Details
acpidump (BIOS v305) (163.38 KB, text/plain)
2007-12-28 07:12 UTC, Fabien Crespel
Details
dmesg (BIOS v305, acpi and cpufreq debug enabled) (28.70 KB, text/plain)
2007-12-28 07:13 UTC, Fabien Crespel
Details
Try the customed DSDT (302.14 KB, text/x-dsl)
2008-01-04 00:22 UTC, ykzhao
Details
Try the customed DSDT (297.53 KB, text/x-dsl)
2008-01-04 00:31 UTC, ykzhao
Details
dmesg with custom DSDT for debugging (28.13 KB, text/plain)
2008-01-04 08:55 UTC, Fabien Crespel
Details
Try the customed DSDT (298.26 KB, text/x-dsl)
2008-01-06 17:59 UTC, ykzhao
Details
dmesg with more ACPI debugging (34.24 KB, text/plain)
2008-01-07 03:04 UTC, Fabien Crespel
Details
sizeof patch (795 bytes, patch)
2008-01-07 22:52 UTC, Lin Ming
Details | Diff
dmesg (4.54 KB, text/plain)
2008-04-07 06:41 UTC, Jiri Slaby
Details
patch included in linux-2.6.25-git16 (2.25 KB, text/x-diff)
2008-04-30 20:44 UTC, Len Brown
Details

Description Giovanni Toraldo 2007-12-13 22:58:44 UTC
Most recent kernel where this bug did not occur: n/a
Distribution: Debian GNU/Linux
Hardware Environment: Asus F3jc
Software Environment: n/a
Problem Description: Frequency scaling is not working after bios version 206 on my Asus f3jc laptop (and probably on many others Asus laptops)

Steps to reproduce:

BIOS images are located here -> ftp://dlsvr01.asus.com/pub/ASUS/nb/F3Jc/ (mostly down, at 5 o'clock is the right time to login :p)

/etc/init.d/powernowd: 156: cannot create /sys/devices/system/cpu/cpu0//cpufreq/scaling_governor: Directory nonexistent
 * CPU frequency scaling not supported
Comment 1 Giovanni Toraldo 2007-12-13 23:00:17 UTC
Created attachment 14017 [details]
dmesg log
Comment 2 Giovanni Toraldo 2007-12-13 23:00:54 UTC
Created attachment 14018 [details]
dmidecode log
Comment 3 Giovanni Toraldo 2007-12-13 23:01:29 UTC
Created attachment 14019 [details]
lspci log
Comment 4 Dave Jones 2007-12-14 00:22:59 UTC
The errors in the dmesg log about incorrect checksums on ACPI tables don't really inspire confidence.

I don't see any signs in the log that you've loaded the acpi-cpufreq module at all. Do you have CONFIG_X86_ACPI_CPUFREQ set ?
Comment 5 Giovanni Toraldo 2007-12-14 01:44:29 UTC
I have done some tests, and a strange behavior occurs:

The first time the kernel try to load the acpi-cpufreq module:
ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0FFFFFFFC) is beyond end of object [20070126]
ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PSS] (Node df925cd8), AE_AML_PACKAGE_LIMIT
ACPI Exception (processor_perflib-0234): AE_AML_PACKAGE_LIMIT, Evaluating _PSS [20070126]
ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0FFFFFFFC) is beyond end of object [20070126]
ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU2._PSS] (Node df925ee8), AE_AML_PACKAGE_LIMIT
ACPI Exception (processor_perflib-0234): AE_AML_PACKAGE_LIMIT, Evaluating _PSS [20070126]
with consequent Cannot insert module (Device not found)

If I retry to load the module a second time, it works.
Could be something solvable or should I damn Asus for making clueless BIOSes?
Comment 6 Len Brown 2007-12-14 14:49:33 UTC
please attach the output from acpidump.
if possible, it would be great to get it when running
both the new broken BIOS, and again with the old working BIOS.
Comment 7 Giovanni Toraldo 2007-12-15 12:08:36 UTC
Created attachment 14055 [details]
acpidump of the buggy bios
Comment 8 Giovanni Toraldo 2007-12-15 12:09:15 UTC
Created attachment 14056 [details]
acpidump of the bios not raising any error
Comment 9 ykzhao 2007-12-16 21:17:42 UTC
Will you please attach the following outputs?
a. For new borken BIOS
   ./acpidump --addr 0x3ffb91b0 --length 0xd24 -o cpu0b
   ./acpidump --addr 0x3ffb9ee0 --length 0xd24 -o cpu1b
b. For the old working bios
   ./acpidump --addr 0x3ffc8590 --length 0x475 -o cpu0
   ./acpidump --addr 0x3ffc8a10 --length 0x475 -o cpu1
Thanks.
Comment 10 Giovanni Toraldo 2007-12-17 07:14:34 UTC
Created attachment 14079 [details]
acpidump as requested
Comment 11 Len Brown 2007-12-17 11:58:07 UTC
Looks like the cpu1 SSDT has a bad checksum
for both the old and the new BIOS.
Did you get checksum dmesg w/ the original BIOS too?

$ cat mysum.c
#include <stdio.h>
main() {
        int i;
        unsigned char sum = 0;

        while ((i = getchar()) != EOF)
                sum += i;

        printf("sum %d\n", sum);
        return 0;
}
$ ./mysum < cpu0
sum 0
$ ./mysum < cpu1
sum 135
$ ./mysum < cpu0b
sum 0
$ ./mysum < cpu1b
sum 189
Comment 12 Giovanni Toraldo 2007-12-17 12:04:55 UTC
This.

ACPI Warning (tbutils-0217): Incorrect checksum in table [SSDT] -  C0, should be 03 [20070126]
Comment 13 Fabien Crespel 2007-12-19 06:47:48 UTC
I have exactly the same problem with my ASUS F3JC, with BIOS version 305. The ACPI parse errors mention slightly different nodes addresses and indexes:

Dec 18 17:35:08 FABP kernel: ACPI Exception (exoparg2-0442):
AE_AML_PACKAGE_LIMIT, Index (0FFFFFFFD) is beyond end of object [20070126]
Dec 18 17:35:08 FABP kernel: ACPI Error (psparse-0537): Method parse/execution
failed [\_PR_.CPU1._PSS] (Node dffdcdc4), AE_AML_PACKAGE_LIMIT
Dec 18 17:35:08 FABP kernel: ACPI Exception (processor_perflib-0234):
AE_AML_PACKAGE_LIMIT, Evaluating _PSS [20070126]
Dec 18 17:35:08 FABP kernel: ACPI Exception (exoparg2-0442):
AE_AML_PACKAGE_LIMIT, Index (0FFFFFFFD) is beyond end of object [20070126]
Dec 18 17:35:08 FABP kernel: ACPI Error (psparse-0537): Method parse/execution
failed [\_PR_.CPU2._PSS] (Node dfd43720), AE_AML_PACKAGE_LIMIT
Dec 18 17:35:08 FABP kernel: ACPI Exception (processor_perflib-0234):
AE_AML_PACKAGE_LIMIT, Evaluating _PSS [20070126]


My checksum error is the following:

ACPI Warning (tbutils-0217): Incorrect checksum in table [SSDT] -  D7, should be 1A [20070126]


On Novell's Bugzilla (I first reported it there because I'm using openSUSE 10.3) I was asked to extract the SSDT with acpidump too, I'll attach it here too in case it could help you. The bug report is here for more information: https://bugzilla.novell.com/show_bug.cgi?id=349569

The strange thing about this bug is that it only happens the first time. Like Giovanni, when I reload acpi_cpufreq it works fine...
Comment 14 Fabien Crespel 2007-12-19 06:49:47 UTC
Created attachment 14125 [details]
ASUS F3JC SSDT for BIOS version 305
Comment 15 Fu Michael 2007-12-24 17:53:48 UTC
sounds like a bios bug. Giovanni, Fabien, Is rolling back to old bios an acceptable solution to you?
Comment 16 Giovanni Toraldo 2007-12-25 00:38:07 UTC
For me it's indifferent, with old releases i have no any other problems, but Fabien have problem booting the crap OS (Vista).

Now i am using the new version, i modified the powernowd init script: it loads acpi-cpufreq a second time (first load in /etc/modules) before launching powernowd app.
Comment 17 Fabien Crespel 2007-12-26 04:28:22 UTC
Indeed I need a recent BIOS version for Vista :(

Bah, I suppose I will do like Giovanni and modify an init script to load acpi_cpufreq twice.
Comment 18 ykzhao 2007-12-27 21:16:53 UTC
Hi, Giovanmi
Will you please boot with the option of acpi.debug_layer=0x01000000 acpi.debug_level=0x1f cpufreq.debug=7 and attach the output of dmesg? 
Please try it on the broken bios and it is noted that the debug function of acpi and cpufreq should be enabled in kernel configuration.
Thanks.
Comment 19 ykzhao 2007-12-27 21:20:39 UTC
Hi, Fabien
Will you please attach the output of acpidump ? 
It will be great if you can do the test in comment #18.
Thanks.
Comment 20 Giovanni Toraldo 2007-12-28 03:56:20 UTC
Created attachment 14216 [details]
dmesg with acpi/cpufreq debug enabled
Comment 21 Fabien Crespel 2007-12-28 07:12:26 UTC
Created attachment 14217 [details]
acpidump (BIOS v305)
Comment 22 Fabien Crespel 2007-12-28 07:13:42 UTC
Created attachment 14218 [details]
dmesg (BIOS v305, acpi and cpufreq debug enabled)
Comment 23 ykzhao 2008-01-04 00:22:21 UTC
Created attachment 14275 [details]
Try the customed DSDT

Hi, Giovanni
Will you please try the customed DSDT on the broken bios?
How to use customed DSDT can be found on the following website:
http://www.lesswatts.org/projects/acpi/faq.php
Thanks.
Comment 24 ykzhao 2008-01-04 00:31:51 UTC
Created attachment 14276 [details]
Try the customed DSDT

Hi, Fabien
   Will you please try the customed DSDT on the broken bios?
How to use customed DSDT can be found on the following website:
http://www.lesswatts.org/projects/acpi/faq.php
Thanks.
Comment 25 ykzhao 2008-01-04 00:56:56 UTC
Hi, Givoanni & Fabien
Will you please try the customed DSDT for your notebooks? 
Please enable the acpi debug and add the boot option of acpi.debug_level=0x0f.

Thanks.
Comment 26 Giovanni Toraldo 2008-01-04 04:20:30 UTC
I am lost about using a custom DSDT.
I am on Debian testing with vanilla 2.6.23.12.

My steps:
- Compiled DSDT with iasl -tc
- Patched vanilla with http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.8.4-2.6.21.patch
- Enabled new function on config (CONFIG_ACPI_CUSTOM_DSDT_INITRD=y) and maked new deb
- Placed dsdt.aml in /etc/initramfs-tools/DSDT.aml, which is automagically includend in initramfs by mkinitramfs (i checked it with verbose option for update-initramfs).

After these steps, my dmesg don't show any "Looking for DSDT in initrd", so i think the patch don't worked well or isn't enabled correctly. I should pass some special parameter to grub command-line?
Comment 27 Fabien Crespel 2008-01-04 08:55:57 UTC
Created attachment 14281 [details]
dmesg with custom DSDT for debugging

Ok it took me some time but here is the result and the steps I used.


First, the DSDT you attached for me didn't compile with iasl DSDT.dsl:

DSDT-debug.dsl   793:                         Load (buf0, HNDL)
Error    4044 -                           Invalid type ^  ([Integer|String|Buffer|Reference] found, Load operator requires [FieldUnit|Region])

I tried to understand why, and it turned out it wasn't important at all, so I eventually compiled with iasl -f DSDT.dsl


But as I'm curious, I extracted the SSDT you were storing in the buf0 buffer to an AML file, then disassembled it. Then I realized I had attached the SSDT for CPU2, and you were using it when loading the CPU1 SSDT in the DSDT...

I don't know if it's important or not, but I think it would have caused the SSDT for CPU1 not to be loaded at all. Bah, I didn't want to take any risk, so I basically did everything again like you had done (including the debug messages), but with the SSDT of CPU1. If you need it for other tests, please tell me and I'll attach it.

Also please note that I'm using openSUSE 10.3, and they include a more advanced patch to load the custom DSDT (it supports SSDT too, I tried it but it didn't work as there were no "ACPI Debug" messages in dmesg). So instead of the "Looking for DSDT in initrd" message, it's "ACPI: successfully read 36644 bytes from file /DSDT.aml" and "ACPI: Override [DSDT-F3J00001] from initramfs - tainting kernel" (lines 104/105)

The interesting stuff starts at line 515 I think:
[ACPI Debug]  String: [0x14] "XPSS value :00000003"
[ACPI Debug]  String: [0x16] "Local0 index :00000000"
[ACPI Debug]  String: [0x16] "Local3 index :FFFFFFFD"
Comment 28 Fabien Crespel 2008-01-04 09:13:04 UTC
Another thing that might be interesting: the following debug messages are printed when loading the acpi_cpufreq module the second time (i.e. when it works).

Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x14] "XPSS value :00000003"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local0 index :00000000"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local3 index :00000007"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000000"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000001"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000002"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000003"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000004"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000005"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local0 index :00000001"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local3 index :00000008"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000000"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000001"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000002"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000003"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000004"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000005"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local0 index :00000002"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local3 index :00000009"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000000"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000001"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000002"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000003"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000004"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Local1 index :00000005"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x1E] "Result: Local0 index :00000003"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x1E] "Result: Local3 index :0000000A"
Jan  4 18:09:07 FABP kernel: [ACPI Debug]  String: [0x16] "Result: XPSS :00000003"
Comment 29 ykzhao 2008-01-06 17:17:38 UTC
Hi, Giovanni
Only to use the customed DSDT is enough. It is unnecessary to apply the http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.8.4-2.6.21.patch

Thanks.
Comment 30 ykzhao 2008-01-06 17:32:55 UTC
Hi, Fabien
Thanks for you log.
What you have done is perfect and the log is very helpful.
The following info is what I wanted.
  >[ACPI Debug]  String: [0x14] "XPSS value :00000003"
  >[ACPI Debug]  String: [0x16] "Local0 index :00000000"
  >[ACPI Debug]  String: [0x16] "Local3 index :FFFFFFFD"

At the same time If the acpi_cpufreq module can be loaded successfully, the message in comment #28 should be printed. It means that _PSS method is executed correctly.
Thanks.
Comment 31 ykzhao 2008-01-06 17:59:35 UTC
Created attachment 14316 [details]
Try the customed DSDT

Hi, Fabien
Will you please try the customed DSDT ?
Thanks.
Comment 32 Fabien Crespel 2008-01-07 03:04:01 UTC
Created attachment 14323 [details]
dmesg with more ACPI debugging

Hello,

here is the requested log. This time it works the first time.. it looks like SizeOf(NPSS) works here because the NPSS is displayed, but it didn't work previously, as Local3 was SizeOf(NPSS) - XPSS = 0x00 - 0x03 = 0xFFFFFFFD. Weird.
Comment 33 Lin Ming 2008-01-07 22:52:07 UTC
Created attachment 14351 [details]
sizeof patch

Hi, Fabien,

We have tracked this bug down to a bug in SizeOf operator.
Would you please try this patch?

When executing SizeOf operator, Package maybe still invalid due to defered evaluation.
If so we need to call AcpiDsGetPackageArguments to evaluate the package.
Comment 34 Fabien Crespel 2008-01-08 02:19:21 UTC
Hi,

it works perfectly now, thanks a lot!
Comment 35 Lin Ming 2008-01-14 19:32:23 UTC
*** Bug 8298 has been marked as a duplicate of this bug. ***
Comment 36 Jiri Slaby 2008-01-15 02:04:10 UTC
Will try later, thanks.
Comment 37 Lin Ming 2008-01-24 17:36:19 UTC
The patch has been integrated into ACPICA release 20080123
Comment 38 Jiri Slaby 2008-01-25 03:02:31 UTC
Seems fixed.
Comment 39 Chuck Ebbert 2008-03-19 19:12:02 UTC
The sizeof patch from comment #33 causes acpi-cpufreq to fail when it's applied to 2.6.24.3
Comment 40 Lin Ming 2008-03-19 19:19:02 UTC
Chunk, 

Please attach dmesg & acpidump
Comment 41 Lin Ming 2008-03-24 00:31:00 UTC
Chunk, 

please have a try the patch at Bug 10299 #7

http://bugzilla.kernel.org/attachment.cgi?id=15411&action=view
Comment 42 Len Brown 2008-03-24 21:24:35 UTC
*** Bug 10299 has been marked as a duplicate of this bug. ***
Comment 43 Jiri Slaby 2008-04-07 06:37:35 UTC
Should this be fixed in 2.6.25-rc8-mm1?
Comment 44 Jiri Slaby 2008-04-07 06:41:59 UTC
Created attachment 15656 [details]
dmesg

Seeing these messages again -- it was fixed, but appeared again. Even 2.6.25-rc5-mm1 according to logs has this issue. 2.6.24.2 is OK.
Comment 45 ykzhao 2008-04-07 18:20:35 UTC
It seems that the patch in comment #33 is not included in 2.6.25-rc1-mm1.
Will you please confirm whether the patch is included in 2.6.24.2?
Thanks.
Comment 46 Loic Nageleisen 2008-04-24 09:28:37 UTC
I went straight from 2.6.24.1 to 2.6.25 (so I never saw it fixed) which gives me:

ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0FFFFFFFC) is beyond end of object [20070126]
ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PSS] (Node ffff81003f83fd20), AE_AML_PACKAGE_LIMIT
ACPI Exception (processor_perflib-0255): AE_AML_PACKAGE_LIMIT, Evaluating _PSS [20070126]
Comment 47 Len Brown 2008-04-30 20:44:24 UTC
Created attachment 15994 [details]
patch included in linux-2.6.25-git16

the attached patch shipped in linux-2.6.25-git16
8246934b7cf99d1f0c053d57890775e5d0df9c33
ACPICA: Fix for SizeOf when used with Buffers and Packages
Comment 48 Jiri Slaby 2008-05-01 02:17:35 UTC
Could you send it to -stable for 2.6.25?
Comment 49 Chuck Ebbert 2008-05-21 17:18:52 UTC
also needs commit 24a3157a90ddf851a0880c0b8963bc43481cd85b if it's going to -stable

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