Bug 6251

Created attachment 7613 [details]
dmesg output with 2.6.16-rc6

Created attachment 7614 [details]
dmesg output with 2.6.15-suspend2

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

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

Thanks,
Luming

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.

Thanks,
Vasilis

<------------
    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? 

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.

Thanks,
Vasilis

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.

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
anything).

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.

Thanks,
Vasilis

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.

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.

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?

Thanks,
Vasilis

Please try patch filed at 
http://bugzilla.kernel.org/show_bug.cgi?id=6749#c8

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