Most recent kernel where this bug did not occur: vanilla 2.6.17 Distribution: Debian SID Hardware Environment: Thinkpad A21m Software Environment: debian SID Problem Description: After second supend to ram comp freeze Steps to reproduce: press Lid switch two times
Created attachment 8414 [details] required output of acpidump
Created attachment 8415 [details] required output of dmidecode
Created attachment 8416 [details] required output of dmesg
Created attachment 8417 [details] required output of lspci
Created attachment 8418 [details] required output of interrupts
If I load only processor and fan acpi modules sleep works. If I load ac battery thermal or video after second or first suspend system freeze.
New details, freeze after 2 or 3 ssuspend to RAM on all kernels that I test 2.6.12-2.6.17 whet ac or battery or thermal module loaded Dan
Created attachment 8481 [details] release global lock in acpi_ec_wait Please help test this patch.
*** Bug 5989 has been marked as a duplicate of this bug. ***
With patch http://bugzilla.kernel.org/attachment.cgi?id=8481&action=view you posted problem goes out. I test sleep and wake 10 times and no freeze !!! Thanks. I was on low battery and after I plug ac in dmesg found this: ACPI: read EC, OB not full ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127] ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.PCI0.ISA_.EC__.CHKS] (Node cbfcd4c8), AE_TIME ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.PCI0.ISA_.EC__.I2RB] (Node cbfcd548), AE_TIME ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.PCI0.ISA_.EC__.BAT0._BIF] (Node cbfcc8c8), AE_TIME acpi_battery-0144 [96] battery_get_info : Error evaluating _BIF But sleep works OK. Thanks again.
>[\_SB_.PCI0.ISA_.EC__.BAT0._BIF] (Node cbfcc8c8), AE_TIME >acpi_battery-0144 [96] battery_get_info : Error evaluating _BIF Does this error relate to the patch - release_global_lock_in_acpi_ec_wait?
I mean that no. But I am not 100% sure. How can I test it ? May I compile kernel without this patch and plug and unplug AC power ? I try it. Thanks.
Sorry I cannot reproduce this message. I test with and without patch and message never occur.
The patch in http://bugzilla.kernel.org/attachment.cgi?id=8481 and vanilla 2.6.17, my TP 600X (see #5989) suspends and resumes with no hangs. Much cleaner than the long acpi_in_suspend hack I had posted to #5989!
need to use acpi_acquire_global_lock() and acpi_release_global_lock() rather than using the internal macros and throwing away the return value because they will sleep properly. However, need to make sure in the ec driver that we NEVER acquire the global lock recursively by checking acpi_gbl_global_lock_thread_count <= 1.
Bob Moore pointed out a problem with the above statement -- AML can acquire the global lock on behalf of a mutex or operation region, and that can conflict with the ability of the ec driver to release the lock to hardware.
*** Bug 6251 has been marked as a duplicate of this bug. ***
Coming from bug #6251 (which has now been marked a duplicate of this one), I can confirm that this patch fixes part of the problem I reported, i.e. it allows my ThinkPad X20 to suspend/resume more than once. However, on both suspend and resume I still get a series of annoying beeps, which seem to accompany messages such as the following in dmesg: ACPI: write EC, IB not empty ACPI: write EC, IB not empty ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for [EmbeddedControl] [20060707] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.ISA_.EC__.SYSL] (Node c12efd4c), AE_TIME ACPI Error (psparse-0537): Method parse/execution failed [\_SI_._SST] (Node c12e9554), AE_TIME ACPI Exception (hwsleep-0204): AE_TIME, While executing method _SST [20060707] The above messages are from suspend time. On resume, the last line is slightly different: ACPI Exception (hwsleep-0582): AE_TIME, During Method _SST [20060707] While sometimes on resume there is an additional line after the above: ACPI Exception (evxface-0545): AE_NOT_EXIST, Removing notify handler [20060707] And sometimes even these lines are not printed at all on resume, and in those cases the beeps don't manifest either. All this in 2.6.18-rc3 BTW. Thanks, Vasilis
*** Bug 6237 has been marked as a duplicate of this bug. ***
This patch also solves problem with TPB (Thinkpad button program). Before this patch TPB stop working after 10 min and only reboot helps.
I now compile 2.6.18 an I can suspend one time and after this suspend led blinking and cannot suspend again. Why the patch is not included in 2.6.18 ?
If I compile 2.6.18 with patch Sleep work again.
Status report for my ThinkPad X20 with 2.6.19-rc6: - With ec_intr=0, suspend-to-ram works fine, no noticeable delays or annoying beeps. I still get the usual AE_TIME errors in dmesg of course. - Without ec_intr=0, suspend-to-ram has a noticeable delay, both on suspend and on resume, and the second resume fails. It's interesting that the second resume doesn't complete despite dmesg reaching the point where it says "Restarting tasks... done.". Again I get AE_TIME errors in dmesg, but no annoying beeps. Oh, and obviously there's no patch to try out any more, the patch that appears in this bug seems rather obsolete by now. Thanks, Vasilis
Vasilis, Note that if a system needs ec_intr=0, then that is a serious bug. Do you still need ec_intr=0 with recent kernels, such as 2.6.20?
With 2.6.20 on my A21m suspend to RAM work OK.
Thinkpad T21, kernel 2.6.20.3: suspend to ram works OKay without ec_intr=0.
I'm happy to report that with 2.6.20 my laptop (Thinkpad X20) suspends fine, multiple times, even without adding ec_intr=0 on the command line. Thanks for all the good work! Vasilis