2006-03-13 02:02:37

by Luming Yu

[permalink] [raw]
Subject: RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

>width) Address=0000000023FDFFC0
>exregion-0290 [36] ex_system_io_space_han: system_iO 1 (8
>width) Address=00000000000000B2
>exregion-0185 [35] ex_system_memory_space: system_memory 0 (32
>width) Address=0000000023FDFFC0
>exregion-0185 [36] ex_system_memory_space: system_memory 0 (32
>width) Address=0000000023FDFFC0
>exregion-0185 [36] ex_system_memory_space: system_memory 1 (32
>width) Address=0000000023FDFFC0
>exregion-0290 [36] ex_system_io_space_han: system_iO 1 (8
>width) Address=00000000000000B2
>
>And then these above four lines (exregion-0185, -0185, -0185, -0290)
>repeat until I reboot.
>

If I understand correctly, it was due to LEqual(S_AH, 0xA6) awlays
true.
SMM bios code didn't respond , or respond correctly
to the request by "store 0x81, APMD" due to thermal module caused
issue?
I need the acpi trace log before _PTS to see what kind of thermal
related methods got called.

Method (SMPI, 1, NotSerialized)
{
Store (S_AX, Local0)
Store (0x81, APMD)
While (LEqual (S_AH, 0xA6))
{
Sleep (0x64)
Store (Local0, S_AX)
Store (0x81, APMD)
}
}


2006-03-13 04:38:48

by Sanjoy Mahajan

[permalink] [raw]
Subject: Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> I need the acpi trace log before _PTS to see what kind of thermal
> related methods got called.

Alas, I've included all the dmesg's.

Below is the script that I use to enter S3 sleep. It unloads rid of
troublesome modules and stop services that don't sleep well. Then
(for debugging) it sends the kernel version and boot parameters across
the serial console (the @@@@ SLEEP line), raises the debug level to
0x1F, does a sync (in case the sleep hangs, since this is my
production machine), and then enters mem sleep.

So nothing in it should trigger any thermal methods; except that I
usually have the THM2 trip point raised to 45C with a polling time of
100 seconds. So once in a while a thermal poll will happen sleep is
being set up. I am not sure whether it would be reported in the
dmesgs if it happened; but the S3 failure happens much more often than
such a thermal polling would happen, so I doubt the S3 failure
requires a thermal poll.

#!/bin/bash -x
# S3 (suspend to memory), with cleanups before and after
sync
ifdown eth0
remove='prism54 xircom_cb xircom_tulip_cb'
remove2='snd_pcm_oss snd_cs46xx'
modprobe -rv $remove
modprobe -rv $remove2
/etc/init.d/chrony stop > /dev/null

sleep 1

(echo "@@@@ SLEEP" ; date ; uname -a ; cat /proc/cmdline ) > /dev/tts/0
echo 0x0000001F > /proc/acpi/debug_level
sync
sleep 2
echo -n mem > /sys/power/state
[stuff for wakeup snipped]