Bug 6749 - Thinkpad A21m freeze after second supedn to RAM
Summary: Thinkpad A21m freeze after second supedn to RAM
Alias: None
Product: ACPI
Classification: Unclassified
Component: EC (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Luming Yu
: 5989 6237 6251 (view as bug list)
Depends on:
Reported: 2006-06-26 02:05 UTC by Daniel Smolik
Modified: 2008-10-17 21:44 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.17 + latest acpi patch for 2.6.17
Regression: ---
Bisected commit-id:

required output of acpidump (48.43 KB, text/plain)
2006-06-26 02:07 UTC, Daniel Smolik
required output of dmidecode (10.95 KB, text/plain)
2006-06-26 02:08 UTC, Daniel Smolik
required output of dmesg (4.87 KB, application/x-tar)
2006-06-26 02:09 UTC, Daniel Smolik
required output of lspci (7.10 KB, text/plain)
2006-06-26 02:09 UTC, Daniel Smolik
required output of interrupts (476 bytes, text/plain)
2006-06-26 02:10 UTC, Daniel Smolik
release global lock in acpi_ec_wait (774 bytes, patch)
2006-07-02 19:36 UTC, Luming Yu
Details | Diff

Description Daniel Smolik 2006-06-26 02:05:25 UTC
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
Comment 1 Daniel Smolik 2006-06-26 02:07:59 UTC
Created attachment 8414 [details]
required output of acpidump
Comment 2 Daniel Smolik 2006-06-26 02:08:29 UTC
Created attachment 8415 [details]
required output of dmidecode
Comment 3 Daniel Smolik 2006-06-26 02:09:09 UTC
Created attachment 8416 [details]
required output of dmesg
Comment 4 Daniel Smolik 2006-06-26 02:09:37 UTC
Created attachment 8417 [details]
required output of lspci
Comment 5 Daniel Smolik 2006-06-26 02:10:07 UTC
Created attachment 8418 [details]
required output of interrupts
Comment 6 Daniel Smolik 2006-06-27 14:06:11 UTC
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.
Comment 7 Daniel Smolik 2006-06-28 14:08:12 UTC
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

Comment 8 Luming Yu 2006-07-02 19:36:59 UTC
Created attachment 8481 [details]
release global lock in acpi_ec_wait

Please help test this patch.
Comment 9 Luming Yu 2006-07-02 22:33:33 UTC
*** Bug 5989 has been marked as a duplicate of this bug. ***
Comment 10 Daniel Smolik 2006-07-03 01:38:53 UTC
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.

Comment 11 Luming Yu 2006-07-03 01:51:43 UTC
>[\_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?

Comment 12 Daniel Smolik 2006-07-03 02:05:21 UTC
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.
Comment 13 Daniel Smolik 2006-07-03 04:07:14 UTC
Sorry I cannot reproduce this message. I test with and without patch and message
never occur.
Comment 14 Sanjoy Mahajan 2006-07-03 22:39:14 UTC
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!

Comment 15 Len Brown 2006-07-05 18:39:38 UTC
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.

Comment 16 Len Brown 2006-07-05 18:46:38 UTC
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.
Comment 17 Luming Yu 2006-08-02 05:18:36 UTC
*** Bug 6251 has been marked as a duplicate of this bug. ***
Comment 18 Vasilis Vasaitis 2006-08-02 06:14:41 UTC
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

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.

Comment 19 Luming Yu 2006-08-03 18:01:47 UTC
*** Bug 6237 has been marked as a duplicate of this bug. ***
Comment 20 Daniel Smolik 2006-08-09 03:14:50 UTC
This patch also solves problem with TPB (Thinkpad button program). Before this
patch TPB stop working after 10 min and only reboot helps.
Comment 21 Daniel Smolik 2006-10-03 12:04:18 UTC
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 ?
Comment 22 Daniel Smolik 2006-10-12 13:31:27 UTC
If I compile 2.6.18 with patch Sleep work again.
Comment 23 Vasilis Vasaitis 2006-11-24 05:42:06 UTC
  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.

Comment 24 Len Brown 2007-03-30 20:09:09 UTC
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?
Comment 25 Daniel Smolik 2007-03-31 02:47:17 UTC
With 2.6.20 on my A21m suspend to RAM work OK. 
Comment 26 Matej Laitl 2007-03-31 06:00:23 UTC
Thinkpad T21, kernel suspend to ram works OKay without ec_intr=0.
Comment 27 Vasilis Vasaitis 2007-04-01 03:15:02 UTC
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!

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