Red Hat Bugzilla – Bug 3575
apmd queue overflow failure
Last modified: 2008-05-01 11:37:50 EDT
Using the latest apmd update as of 6/18/99 (apmd-3.0beta5-8) on an IBM Thinkpad 570 laptop, apmd fails to suspend on closing the lid. Instead the following error message appears: apm: an event queue overflowed The requested suspend actually still occurs -- but is delayed until the moment when the moribund apmd is killed. There are no problems invoking suspend manually, using the command "apm -s". (The only exception is that if apmd is running and has entered the moribund state described above, then manual suspend doesn't work either).
Which kernel version are you using? ------- Additional Comments From 07/14/99 05:32 ------- The kernel is version 2.2.5-22 (on i386), which is still the most current update. Let me know if there are any specific tests I can run to clarify the problem. ------- Additional Comments From 07/14/99 05:34 ------- [This time with cookies on...] The kernel is version 2.2.5-22 (on i386), which is still the most current update. Let me know if there are any specific tests I can run to clarify the problem.
Added Zach to CC line so that he can look.
Also, try the latest apmd from Raw Hide.
The latest rawhide (apmd-3.0beta8-1) gives different messages but has the same problem. Below are the kernel messages for a sequence of 3 attempts to suspend by closing the lid, after starting apmd. These attempts fail (hardware blanks the screen, but everything is still running); only when I subsequently kill apmd (with kill -HUP) does the system finally suspend. Aug 19 15:30:05 horizon apmd[10987]: Version 3.0beta8 (APM BIOS 1.2, Linux driver 1.9) Aug 19 15:30:05 horizon apmd[10987]: Battery: * * * (1003221223716nknown) Aug 19 15:30:31 horizon kernel: ent Aug 19 15:30:32 horizon apmd[10987]: System Suspend Aug 19 15:31:59 horizon last message repeated 19 times Aug 19 15:32:46 horizon apmd[10987]: System Suspend Aug 19 15:34:06 horizon kernel: ent Aug 19 15:34:08 horizon apmd[10987]: System Suspend Aug 19 15:34:10 horizon last message repeated 18 times
Ack. I mean the apmd-3.0beta9 RPMs, currently in Raw Hide.
This is not apmd related - it's related to the APM part of the kernel...
guessing time! It seems to me that kernel is getting a flood of suspend events from the bios. Were that to happen, the kernel would constantly notify apmd that it wants to suspend, and apmd would constantly tell the kernel to just do it already. But the BIOS keeps injecting suspend events into the mix? This would explain why killing apmd makes it work (no one around to listen to suspend events, so the kernel just does it) and why apm -s works (only one suspend event from the operator, rather than a stream of them from the BIOS). I'm not familiar enough with the apm code to know why this would start happening. maybe apmd and the kernel are getting out of sync, or maybe one of them used to have a high water mark before they would just do it. Can you try updating the BIOS on your laptop to see if this still happens? Its a scary operation and not guaranteed to work. If that doesn't sound like fun :), we can instrument apmd to see just what it thinks is going on..
Closing due to lack of user input
What do you mean by "lack of user input"? I have offered to run any test you want. If you have an instrumented apmp I'd be more than happy to run it. Paul Burchard (burchard@pobox.com)