Bug 4989

Summary:	S3 wakeup hangs w/ TP 600X
Product:	ACPI	Reporter:	Sanjoy Mahajan (sanjoy)
Component:	Power-Sleep-Wake	Assignee:	acpi_power-sleep-wake
Status:	REJECTED UNREPRODUCIBLE
Severity:	normal	CC:	acpi-bugzilla, akpm
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.13-rc2-git1	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	acpidmp output dmesg log dmidecode output patch that breaks S3 wakeup

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
sync
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
results.

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..\
           299de0343c7d18448a69c635378342e9214b14af

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
wakeup."  

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 2.6.11.4 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.