Bug 4989 - S3 wakeup hangs w/ TP 600X
Summary: S3 wakeup hangs w/ TP 600X
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: acpi_power-sleep-wake
Depends on:
Reported: 2005-08-03 00:42 UTC by Sanjoy Mahajan
Modified: 2005-08-14 21:44 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.13-rc2-git1
Regression: ---
Bisected commit-id:

acpidmp output (206.32 KB, text/x-log)
2005-08-03 09:06 UTC, Sanjoy Mahajan
dmesg log (10.16 KB, text/x-log)
2005-08-03 09:23 UTC, Sanjoy Mahajan
dmidecode output (12.51 KB, application/octet-stream)
2005-08-03 09:24 UTC, Sanjoy Mahajan
patch that breaks S3 wakeup (1.81 KB, patch)
2005-08-04 21:14 UTC, Sanjoy Mahajan
Details | Diff

Description Sanjoy Mahajan 2005-08-03 00:42:55 UTC
Distribution: Debian testing
Hardware Environment: TP 600X
Software Environment: modified DSDT (see acpidmp output attached), XFree86 4.3
Problem Description:  The laptop will go into S3 sleep but it won't wake up even
once -- the screen stays blank, but the disk light goes on (although the disk
does not spin).  

I binary searched -git* versions between 2.6.13-rc1 (wakes up fine) and
2.6.13-rc2-git1 (fails), except for vanilla 2.6.13-rc2 which didn't compile. 
2.6.13-rc1-git7 is the last one that works.  The problem remains with -rc3 (see
Bug #4926).

Steps to reproduce:  Log into X and run this script, waking it up by pressing
the 'Fn' key:

#!/bin/bash -x

# suspend to memory, with cleanups before and after

ifdown eth0 ; modprobe -r prism54
/etc/init.d/hotplug stop > /dev/null
/etc/init.d/chrony stop  > /dev/null
# to reload acpi modules and clear out the semaphore error if there
/etc/init.d/acpid restart > /dev/null

echo 0 > /proc/acpi/thermal_zone/THM0/polling_frequency
echo 0 > /proc/acpi/thermal_zone/THM2/polling_frequency
sleep 0.5
echo 0x1F > /proc/acpi/debug_level
logger -t "suspend.sh" sleeping
sleep 2

echo -n mem > /sys/power/state

logger -t "suspend.sh" waking up
# setserial might help restore state if waking messed it up
setserial -a /dev/ttyS0
chvt 1
sleep 1
chvt 7

echo 0xF > /proc/acpi/debug_level

/etc/init.d/chrony start  > /dev/null
/etc/init.d/hotplug start > /dev/null
Comment 1 Sanjoy Mahajan 2005-08-03 00:53:51 UTC
Sorry, attaching files is not working for me (hangs mozilla and galeon
and lynx gets back from bugzilla that I forgot the attachment number,
whatever that is).  So I'll try again in a bit.
Comment 2 Sanjoy Mahajan 2005-08-03 09:06:36 UTC
Created attachment 5493 [details]
acpidmp output
Comment 3 Sanjoy Mahajan 2005-08-03 09:23:18 UTC
Created attachment 5494 [details]
dmesg log
Comment 4 Sanjoy Mahajan 2005-08-03 09:24:05 UTC
Created attachment 5495 [details]
dmidecode output
Comment 5 Andrew Morton 2005-08-04 17:34:11 UTC
Thanks for doing the bsearch - that really helps.

I bunch of power management fixes are going into 2.6.13-rc6.  Fingers crossed,
we'll fix this up.  PLease retest it promptly and update us with the
Comment 6 Sanjoy Mahajan 2005-08-04 21:13:37 UTC
> bsearch...really helps

I got 'git bisect' working reliably (maybe overkill) by using cg-export to make
a pristine tree and then compiling the kernel from scratch (rather than just
checking out new files in the same directory and running make), so I narrowed it
down to one commit.  After several bisection steps, 'git bisect' says:

  299de0343c7d18448a69c635378342e9214b14af is first bad commit

90b54929b626c80056262d9d99b3f48522e404d0 was the last good one, and
75865858971add95809c5c9cd35dc4cfba08e33b is the last bad one, which is how
bisect came up with the conclusion above.  To test it, I applied the result of
  git diff 90b54929b626c80056262d9d99b3f48522e404d0..\

to a copy of the just-compiled-and-installed
90b54929b626c80056262d9d99b3f48522e404d0 directory tree, then recompiled and
tested.  Voila, it didn't work, as bisect predicted.

I'll attach that diff in case any lines jump out as "Oh, here's why it breaks on

The latest releases are well beyond this patch, but if this patch causes the
problem (rather than merely exposes a different problem), then it's worth
knowing about because it is in the kernel.  Here's a test against my -rc5 tree
(where /usr/src/bisect/s3-culprit.diff is the diff in question):

$ patch --dry-run -R -p1 < /usr/src/bisect/s3-culprit.diff
patching file arch/i386/pci/common.c
patching file arch/i386/pci/i386.c
patching file drivers/pci/setup-bus.c
Hunk #1 succeeded at 268 (offset -5 lines).
Comment 7 Sanjoy Mahajan 2005-08-04 21:14:40 UTC
Created attachment 5509 [details]
patch that breaks S3 wakeup
Comment 8 Andrew Morton 2005-08-04 23:17:11 UTC
Yeah, we had a ton of trouble with that code.

As I say, I think 2.6.13-rc6 or even 2.6.13-rc5-git3
should fix this.
Comment 9 Sanjoy Mahajan 2005-08-04 23:29:05 UTC
2.6.13-rc5-git2 sleeps and wakes up!  Pushing my luck, I even tried a 2nd
sleep/wake cycle, and that worked too (on a few of the -mm kernels, the first
sleep/wake would work but not the second).

And hibernation (swsusp) is mostly working (the fan no longer is controllable on
wake, I'll file a report...).  So I finally have a single kernel version that
can sleep and mostly hibernate (before would sleep but not hibernate,
and various 2.6.13 kernels would hibernate but not sleep).  Almost like with APM
(the main regression since APM days: waking up is slower with ACPI, plus the vga
adapter is always hosed upon wake, no matter what video_post or fake x server
tricks I try).

I'll try -git3 to make sure there's no regression, and -rc6 when it arrives.
Comment 10 Len Brown 2005-08-14 21:44:46 UTC
> 2.6.13-rc5-git2 sleeps and wakes up!

thanks for testing.  Please re-open if you have any
problems with 2.6.13-rc6, or 2.6.13.

Note You need to log in before you can comment on or make changes to this bug.