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
Created attachment 14017 [details] dmesg log
Created attachment 14018 [details] dmidecode log
Created attachment 14019 [details] lspci log
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 ?
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?
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.
Created attachment 14055 [details] acpidump of the buggy bios
Created attachment 14056 [details] acpidump of the bios not raising any error
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.
Created attachment 14079 [details] acpidump as requested
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
This. ACPI Warning (tbutils-0217): Incorrect checksum in table [SSDT] - C0, should be 03 [20070126]
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...
Created attachment 14125 [details] ASUS F3JC SSDT for BIOS version 305
sounds like a bios bug. Giovanni, Fabien, Is rolling back to old bios an acceptable solution to you?
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.
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.
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.
Hi, Fabien Will you please attach the output of acpidump ? It will be great if you can do the test in comment #18. Thanks.
Created attachment 14216 [details] dmesg with acpi/cpufreq debug enabled
Created attachment 14217 [details] acpidump (BIOS v305)
Created attachment 14218 [details] dmesg (BIOS v305, acpi and cpufreq debug enabled)
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.
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.
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.
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?
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"
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"
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.
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.
Created attachment 14316 [details] Try the customed DSDT Hi, Fabien Will you please try the customed DSDT ? Thanks.
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.
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.
Hi, it works perfectly now, thanks a lot!
*** Bug 8298 has been marked as a duplicate of this bug. ***
Will try later, thanks.
The patch has been integrated into ACPICA release 20080123
Seems fixed.
The sizeof patch from comment #33 causes acpi-cpufreq to fail when it's applied to 2.6.24.3
Chunk, Please attach dmesg & acpidump
Chunk, please have a try the patch at Bug 10299 #7 http://bugzilla.kernel.org/attachment.cgi?id=15411&action=view
*** Bug 10299 has been marked as a duplicate of this bug. ***
Should this be fixed in 2.6.25-rc8-mm1?
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.
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.
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]
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
Could you send it to -stable for 2.6.25?
also needs commit 24a3157a90ddf851a0880c0b8963bc43481cd85b if it's going to -stable