public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: ACPI suspend problems revisited: USB & 1394 modules?
Date: Mon, 22 May 2006 01:06:10 -0600	[thread overview]
Message-ID: <447162E2.7050803@shaw.ca> (raw)

I reported a problem with ACPI suspend on a Compaq Presario X1050 laptop 
a while ago:

http://bugzilla.kernel.org/show_bug.cgi?id=6075

Essentially when coming out of suspend I get ACPI execution errors like:

ACPI: read EC, IB not empty
ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for
[EmbeddedControl] [20060127]
ACPI Exception (dswexec-0458): AE_TIME, While resolving operands for
[AE_NOT_CONFIGURED] [20060127]
ACPI Error (psparse-0517): Method parse/execution failed
[\_SB_.C046.C059.C0EA.C11D] (Node dfea0280), AE_TIME
ACPI Error (psparse-0517): Method parse/execution failed [\_WAK] (Node
c14dc500), AE_TIME

After this point, the battery status is no longer reported, the keyboard 
starts losing keypresses and the mouse pointer tends to freeze up for a 
while and then unstick. What ACPI seems to be having problems with is 
that the ACPI Embedded Controller seems to be in a wacked-out state 
where it appears to not process its input. As well, the keyboard/PS2 
controller is messed up and keeps losing sync. Since these are 
apparently usually the same physical hardware, this isn't too surprising 
to see both problems.

Another user mentioned recently. that removing USB and IEEE1394 modules 
prevented the problem on his HP laptop. For me, if the ohci_hcd, 
ehci_hcd and ohci1394 modules are removed, suspend indeed appears to 
work. I haven't tested all possible combinations, but it seems that if 
any of those are loaded, the problem shows up. I've seen a number of 
suspend scripts people have written that remove at least the USB modules 
before suspend and reload them afterwards, but this seems like a rather 
brutal hack.

I can possibly imagine some BIOS SMM code causing problems on the USB 
side, but I'm not sure how the 1394 module could be involved here..

Does anyone have any ideas as to how I could help debug this further?

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

                 reply	other threads:[~2006-05-22  7:06 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=447162E2.7050803@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox