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