Bug 3534

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.