http://bugzilla.kernel.org/show_bug.cgi?id=5989
------- Additional Comments From [EMAIL PROTECTED] 2006-02-14 17:08 -------
Here is the commit (I'll attach the diff) that makes the second S3
sleep go into the endless loop when the loaded modules are exactly
thermal, processor, intel_agp, and agpgart:
53f11d4ff8797bcceaf014e62bd39f16ce84baec is first bad commit
diff-tree 53f11d4ff8797bcceaf014e62bd39f16ce84baec (from 02b28a33aae93a3b53068e
0858d62f8bcaef60a3)
Author: Len Brown <[EMAIL PROTECTED]>
Date: Mon Dec 5 16:46:36 2005 -0500
[ACPI] Enable Embedded Controller (EC) interrupt mode by default
"ec_intr=0" reverts to polling
"ec_burst=" no longer exists.
Signed-off-by: Len Brown <[EMAIL PROTECTED]>
Acked-by: Luming Yu <[EMAIL PROTECTED]>
:040000 040000 9eec66712c68ebe372b2fb2c8d78bdc99df942ab e7e62cd09983730aee468ed
d4ba1cce50786b7e5 M Documentation
:040000 040000 6e7db46918f6124f64a11f6757560078a8a27519 aa8abb1023024902300cb2e
7a5bf74acd8c579e8 M drivers
If I boot with ec_intr=0, the second sleep works fine.
Here is the full story. First I tried a system with the minimal set of
modules to boot and run X (S3 sleep-wake wrecks the VGA consoles, but X
restores fine with 'chvt 1; sleep 0.5 ; chvt 7' on wakeup). So I
stopped every service and unloaded all modules possible, which left only
intel_agp and agpgart. Then, for each of the usual loaded modules
(except for sound modules, which often has sleep-wake problems anyway),
I tried:
1. Load the module
2. S3 sleep-wake-sleep-wake
3. Unload the module
to see whether the second sleep went into the infinite loop (visible
across the console). The one culprit I found was 'thermal' (which
brings in 'processor'). Other modules didn't trigger the problem.
Then I recompiled using a minimal config, with only networking (for X to
work) and the acpi modules, and maybe a few others that I couldn't
avoid, and retested to make sure 'thermal' still triggered the problem,
which it did. I used this config, or one just like it for 2.6.15, as a
base for all other kernels in the bisection search, using the nearest
ancestor's .config and then
yes '' | make oldconfig
to make the new .config
The attached test_s3.sh script gives the steps for testing the thermal
module. Eventually bisection converged to the commit above, and then
I retested that kernel with 'ec_intr=0'.
Is this a problem with the TP 600X hardware, in which case I'll just use
ec_intr=0 forever, or is there more software debugging (DSDT or related
to the diff)? I can turn on gobs of ACPI debugging and send the useful
parts of the log file.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
