Bug 6251 - S3 can't resume multiple times unless ec_intr=0 - ThinkPad X20
S3 can't resume multiple times unless ec_intr=0 - ThinkPad X20
Status: REJECTED DUPLICATE of bug 6749
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake
i386 Linux
: P2 normal
Assigned To: Luming Yu
Depends on:
  Show dependency treegraph
Reported: 2006-03-19 23:14 UTC by Vasilis Vasaitis
Modified: 2006-08-02 05:18 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.16-rc6
Tree: Mainline
Regression: ---

dmesg output with 2.6.16-rc6 (12.63 KB, text/plain)
2006-03-19 23:16 UTC, Vasilis Vasaitis
dmesg output with 2.6.15-suspend2 (12.39 KB, text/plain)
2006-03-19 23:16 UTC, Vasilis Vasaitis
dmesg output with 2.6.16-rc6 and ec_intr=0 (12.54 KB, text/plain)
2006-03-19 23:46 UTC, Vasilis Vasaitis

Description Vasilis Vasaitis 2006-03-19 23:14:29 UTC
Most recent kernel where this bug did not occur: 2.6.15
Distribution: Debian
Hardware Environment: IBM ThinkPad X20 (PIII/600, 440BX, 320MB)
Software Environment: hibernate script 1.12 used for suspending
Problem Description:

In all 2.6 kernels that I've used up to 2.6.15, suspend-to-ram works fine and
without hassles. In 2.6.16-rc6 however, when the computer enters and exits
suspend-to-ram it produces a series of annoying beeps, which also have the
effect of slowing down the whole process. Otherwise everything seems to work
equally well. The beep sequence is the same as the one produced by `echo 1 >
/proc/acpi/ibm/beep`. IIRC, the beep sequence is also produced when I suspend to
disk (using suspend2, mind you), where I've instructed the hibernate script to
enter S4 rathen than S5 (not that it appears to make much difference other than
the suspend led blinking on poweron).

I'm attaching the dmesg output that shows the kernel messages when this happens,
and also a dmesg output from 2.6.15-suspend2 (sorry, no vanilla, but I can
provide one if necessary; but suspend2 seems to be orthogonal to all this
anyway), where everything works fine.

If I had to guess, I'd say that the ACPI implementation has increased checks for
errors it was previously ignoring; in my case, those AE_TIME errors. Also, this
*might* be related to bug #6075.

Steps to reproduce:

Enter / exit suspend-to-ram mode on the mentioned computer.
Comment 1 Vasilis Vasaitis 2006-03-19 23:16:06 UTC
Created attachment 7613 [details]
dmesg output with 2.6.16-rc6
Comment 2 Vasilis Vasaitis 2006-03-19 23:16:58 UTC
Created attachment 7614 [details]
dmesg output with 2.6.15-suspend2
Comment 3 Vasilis Vasaitis 2006-03-19 23:46:47 UTC
Created attachment 7615 [details]
dmesg output with 2.6.16-rc6 and ec_intr=0

Hm, after a bit of digging around, I tried booting with ec_intr=0, and the
beeps have stopped. There's still a noticable delay of about one second
compared to previous kernels, both for entering and exiting suspend-to-ram,
which is a bit annoying. I'm attaching the dmesg output again, though the main
change seems to be the absence of these lines (two on sleep, two on wakeup):

ACPI: write EC, IB not empty
Comment 4 Luming Yu 2006-03-20 18:41:27 UTC
ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for 
[EmbeddedControl] [20060127]
ACPI Error (psparse-0517): Method parse/execution failed 
[\_SB_.PCI0.ISA_.EC__.SYSL] (Node c12ec820), AE_TIME
ACPI Error (psparse-0517): Method parse/execution failed [\_SI_._SST] (Node 
d3fc3300), AE_TIME
ACPI Exception (hwsleep-0203): AE_TIME, While executing method _SST [20060127]
pnp: Device 00:0c disabled.
With ec_intr=0, you have above error.
Please post dmesg with ec_intr=1.
Since this error is related to _SST
which is for system indicator, So,
I'm not wondering you will hear beeps. :-)
But, I need to understand how well _SST executed.


Comment 5 Vasilis Vasaitis 2006-03-21 02:46:12 UTC
Erm, isn't ec_intr=1 the default? If so, what you're asking for is the first
attachment of this patch. Otherwise, let me know and I'll upload a dmesg output
with ec_intr=1 explicitly defined in the command line.

Comment 6 Luming Yu 2006-03-21 04:44:24 UTC
    ACPI-0412: *** Error: Handler for [EmbeddedControl] returned AE_TIME
    ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.ISA_.EC__.SYSL] 
(Node c12ed820), AE_TIME
    ACPI-0508: *** Error: Method execution failed [\_SI_._SST] (Node 
d3fc1300), AE_TIME
    ACPI-0203: *** Error: Method _SST failed, AE_TIME
But, 2.6.15-suspend2 has same EC issue like 2.6.16.
Do you have other problem such as hotkey, battery, thermal ...
Could you post /proc/interrupts?
Do you use latest BIOS? 
Comment 7 Vasilis Vasaitis 2006-03-21 05:34:10 UTC
With kernels up to 2.6.15, the kernel does print the various AE_TIME error
messages on suspend/resume (like the ones you highlighted), but apart from those
ACPI appears to work flawlessly. If I dig deep enough I might find minor things
not working (no battery events? can't remember), but nothing serious. And no
beeps. :^)

The laptop does have the latest BIOS and Embedded Controller Program, though
keep in mind that this is an old laptop, so these are dated 2003-05-29 and
2002-10-25 respectively (from what I can see at the IBM/Lenovo website). I can
confirm all these later today when I'll have access to it, and also post
/proc/interrupts, which is fairly boring mind you: ACPI and the first PCI device
to be probed get IRQ 9 (e100 for 2.6.15-suspend2 and 2.6.16-rc6 with ec_intr=0,
uhci_hcd for 2.6.16-rc6 with ec_intr=1), the other PCI devices get IRQ 11, and
the rest is at the usual places.

Comment 8 Len Brown 2006-03-22 19:05:55 UTC
Please verify that I understand this properly:
1. 2.6.15-suspend2 -- does this include the suspend2 patch?
2. 2.6.15-suspend2 already had a broken EC, and got:

> ACPI-0508: *** Error: Method execution failed [\_SI_._SST] (Node 
d3fc1300), AE_TIME

the default for 2.6.15 was ec_burst=0,
does this behaviour change with 2.6.15 if you use ec_burst=1
(expect beep to start happening, but maybe not)

3. 2.6.16
with default ec_intr=1 you get a beep
with ec_intr=0, beep goes away, but you get an additional delay.

So it looks like the EC may be broken in all 4 cases, just
that it was first noticed and reported when the failure caused noise.

Comment 9 Vasilis Vasaitis 2006-03-23 03:47:11 UTC
Hm, first of all, I performed some extra tests. Unfortunately, the beeps I
reported were only half the story, as the behaviour I described really applies
to the *first* time that 2.6.16-rc6 with ec_intr=1 suspends & resumes. The
second time around, what happens is that (a) it takes even more time to suspend
and (b) it does not resume cleanly; I do get back to the console and are able to
continue using the system, but the resume process seems to have hung (last thing
that is printed in dmesg is the "Restarting tasks... done" line), and ps shows
the `/bin/echo -n mem` process that caused the suspend in uninterruptible sleep.

On the other hand, 2.6.16-rc6 with ec_intr=0 and 2.6.15-suspend2 (which has the
suspend2 patch yes) are able to suspend & resume multiple times without
problems. I also just tried 2.6.15-suspend2 with ec_burst=1 as you suggested. It
doesn't beep, it doesn't even print AE_TIME error messages (!), but it does
print the "write EC, IB not empty" message and it hangs at the second resume,
leaving the system mostly unusable (unlike 2.6.16-rc6 which manages to get it to
a usable state).

So, to some up, and answer the questions directly, we have:

1. Yes (but I can test vanilla if you think it might have something to do with

2. The behaviour does change with ec_burst=1, no more AE_TIME error messages,
instead I get write EC messages and the second resume hangs.

3. The additional delay mentioned is WRT 2.6.15, not WRT ec_intr=1.

Comment 10 Evan Speltz 2006-04-13 20:41:11 UTC
I have a very similar problem on my ThinkPad T22, when resuming from
suspend-to-ram the shell I was using hangs in uninterruptible sleep and the
"sleep" LED blinks rapidly. It works fine with ec_intr=0 or with linux 2.6.15
and earlier.
Comment 11 Rudolf Marek 2006-05-14 05:17:05 UTC
Me too.

I have a very similar problem on my ThinkPad T20, when resuming from
suspend-to-ram the shell I was using hangs in uninterruptible sleep and the
"sleep" LED blinks rapidly. It works fine with ec_intr=0 or with linux 2.6.17rc4
and earlier.
Comment 12 Vasilis Vasaitis 2006-08-02 03:12:50 UTC
Just to confirm that this problem still persists as of 2.6.18-rc3. However, I
should note that the annoying delay during suspend/resume with ec_intr=0 has
gone away (I could try to pinpoint the exact release where this happened if
that's of any use), so at this point S3 is perfectly usable again for me, just
not with the default settings. This begs the question: isn't it possible to have
ec_intr=0 be the default? And if not, is it at least possible to make it the
default for computers that are known to be affected, if there's such a mechanism
in place?

Comment 13 Luming Yu 2006-08-02 05:18:28 UTC
Please try patch filed at 

*** This bug has been marked as a duplicate of 6749 ***

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