Distribution: Gentoo Hardware Environment: Thinkpad 600x Software Environment: Kernel 2.6.9-rc3, gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6). Problem Description: Using 2.6.9-rc3 I get the following error on boot: ACPI: (supports S0 S1 hwregs-0169: *** Error: Missing Sleep State object hwregs-0208 [46] acpi_get_sleep_type_da: While evaluating sleep_state [\_S3_], bad Sleep object 00000000 type [NULL Object Descriptor] S4 S5) I applied acpi-20040816-26-latest-release.diff.gz With the same results except that I no longer get the debug output, even though CONFIG_ACPI_DEBUG=y acpidmp, dmesg and config from 2.6.9.-rc3 plus acpi patch are attached Thanks Jesse Steps to reproduce:
Created attachment 3793 [details] dmesg
Created attachment 3794 [details] kernel config
Created attachment 3795 [details] output of acpidmp
The root cause of failure is that linux is using element in const char *acpi_gbl_sleep_state_names[ACPI_S_STATE_COUNT] = { "\_S0_", "\_S1_", "\_S2_", "\_S3_", "\_S4_", "\_S5_" }; to call acpi_get_sleep_type_data, but your box define _S3 under the device PNP0A03. So, the evaluating \_S3 will fail. The workaround in DSDT is to change _S3 to \_S3_ . We can fix it in acpi driver soon.
looks like the DSDT has a method rather than a name. Bob, can ACPICA grok this?
It should not matter whether it is a static name or a method. What counts is the object that comes back.
_S3_ appears at the root of the namespace, so evaluating \_S3_ should work. It happens to be a method, but it returns a package, so this is ok also. It's unclear what is going on, an execution trace is probably necessary. 1376 [1] _S0_ - Package [Initial Length 0x04 elements] 1377 [1] _S1_ - Package [Initial Length 0x04 elements] 1378 [1] _S3_ - Method [Code Length 0x001F bytes] 1379 [1] _S4_ - Package [Initial Length 0x04 elements] 1380 [1] _S5_ - Package [Initial Length 0x04 elements] Executing \_S3_ Execution of \_S3_ returned object 00326E38 Buflen 50 [Package] Contains 4 Elements: [Integer] = 0000000000000001 [Integer] = 0000000000000001 [Integer] = 0000000000000000 [Integer] = 0000000000000000 Method (_S3, 0, NotSerialized) { If (BXPT) { Return (Package (0x04) { 0x06, 0x06, 0x00, 0x00 }) } Else { Return (Package (0x04) { 0x01, 0x01, 0x00, 0x00 }) } }
I have the same missing-sleep-state problem on my Thinkpad 600X (PIII 650 MHz) with the latest IBM BIOS (1.11) [*] I disassembled the DSDT w/ iasl, fixed a bunch of warnings and errors (hopefully without causing other, more subtle errors); changed the _S3 to \_S3_ (I also tried \_S3), as suggested in Additional Comment #4; then reinstalled the .hex file as the DSDT into the kernel using the custom DSDT config option. I still get the same message on bootup: ACPI: (supports S0 S1 hwregs-0170: *** Error: Missing Sleep State object hwregs-0209 [04] acpi_get_sleep_type_da: While evaluating sleep_state [\_S3_], bad Sleep object 00000000 type [NULL Object Descriptor] S4 S5) I'm using 2.6.11.4 patched with acpi-20050309-2.6.11.diff.bz2 and I boot with "pci=noacpi acpi_sleep=s3_bios". Can I help debug this problem, run tests? Do you want any other log files or other output? It's a great laptop and will be perfect once ACPI sleeping works as smoothly as APM did. [*] The BIOS claims to be from 1999, but that date is almost surely wrong. The readme/changelog with the BIOS update diskette is dated Sept 20, 2001 and contains this note about the 1.01 update: - (Fix) If Windows 98 Second Edition is installed as APM mode and an updated BIOS is installed with a BIOS date 12/02/99 or later, Windows 98SE will change the mode from APM to ACPI whenever a New hardware profile is created. So this BIOS set the date to 11-30-99. Probably they've marked all the dates as 11-30-99 in order to keep working around this W98SE misfeature. My guess is that BIOS 1.11 is really from Sept 2001.
Bob, if the method is Method (_S3, 0, NotSerialized) { Return (Package (0x04) { 0x01, 0x01, 0x00, 0x00 }) } } you will find the error. if it's Name(\_S3, Package(0x04)) { 0x01, 0x01, 0x00, 0x00 }) you will not find the error. This issue can be easily reproduced (just use an overrided DSDT with above change in any laptop)
I changed my DSDT using the suggestion from Additional Comment #9. It helps. Now the boot goes fine, with no complaints about missing sleep objects. When I do 'echo 3 > /proc/acpi/sleep', it goes to sleep like in the old days of APM suspend. However, waking it up (by pressing the Fn key) produces steadily growing patterns on the screen and a completely hung machine (kernel 2.6.11.4 w/ latest ACPI patches), only the power button works.
I'm not able to reproduce the problem using acpiexec on the original DSDT: - find _s3_ \_S3_ (00472648) - Method - ex _s3 Executing \_S3 Execution of \_S3 returned object 00326E38 Buflen 50 [Package] Contains 4 Elements: [Integer] = 0000000000000001 [Integer] = 0000000000000001 [Integer] = 0000000000000000 [Integer] = 0000000000000000 or: - sleep 3 **** Prepare to sleep **** **** Going to sleep **** hwsleep-0403 [01] AcpiEnterSleepState : Entering sleep state [S3] **** returning from sleep **** **** Received a Notify on Device [IDSM] 0046B108 value 0x1 Another interesting issue is the package definition: Return (Package (0x04) { 0x06, 0x06, 0x00, 0x00 }) However, the ACPI spec defines the _Sx packages to be a single DWORD.
I received a copy of the amended and compiled dsdt from Sanjoy. echo mem > /sys/power/state causes the machine to stop tasks and enter S3, but when woken up with 'Fn' I see the contents of the display for a second, then it returns to black and the machine hangs. Kernel 2.6.11-ck2
Using my updated DSDT I am now able to get S3 mostly working. I boot 2.6.11.4 + current ACPI w/ these options: acpi=force pci=noacpi acpi_sleep=s3_bios Before I put it to sleep, I do cardctl eject (probably my wireless driver will oops otherwise) modprobe -r uhci_hcd (since that module often hangs upon waking) /etc/init.d/hotplug stop (to be really safe) Then echo mem > /sys/power/state Fn wakes it up, but to a jittering console screen. ctrl-alt-F7 switches it back to the X display, and then all is mostly fine. The consoles (e.g. ctrl-alt-F1) still jitter and are mostly unusable, but X is working, so it's plenty of progress. Let me know if I should post the syslog messages after enabling ACPI debug_layer and debug_level options (and which bits in the mask to enable).
I think this can be closed
I agree. It's a TP600X bios problem, and the hacked DSDT that I use fixes the problem.
> ACPICA-Core -> BIOS Fair enough. Though the ACPI code now handles (and has done so for months I would estimate) this particular BIOS breakage. So I no longer need a hacked DSDT. Many thanks, by the way. Apologies for not testing more recent ACPI changes on the 600X. The screen died completely -- for a while it had only half died -- and I haven't replaced it yet or set up serial-console login.