|Summary:||apmd queue overflow failure|
|Product:||[Retired] Red Hat Linux||Reporter:||burchard|
|Component:||kernel||Assignee:||Bernhard Rosenkraenzer <bero>|
|Status:||CLOSED WORKSFORME||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2000-02-03 15:53:54 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description burchard 1999-06-18 17:11:34 UTC
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).
Comment 1 Michael K. Johnson 1999-07-13 18:23:59 UTC
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.
Comment 2 Michael K. Johnson 1999-07-30 20:12:59 UTC
Added Zach to CC line so that he can look.
Comment 3 Bill Nottingham 1999-08-19 22:06:59 UTC
Also, try the latest apmd from Raw Hide.
Comment 4 burchard 1999-08-19 22:43:59 UTC
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: Version 3.0beta8 (APM BIOS 1.2, Linux driver 1.9) Aug 19 15:30:05 horizon apmd: Battery: * * * (1003221223716nknown) Aug 19 15:30:31 horizon kernel: ent Aug 19 15:30:32 horizon apmd: System Suspend Aug 19 15:31:59 horizon last message repeated 19 times Aug 19 15:32:46 horizon apmd: System Suspend Aug 19 15:34:06 horizon kernel: ent Aug 19 15:34:08 horizon apmd: System Suspend Aug 19 15:34:10 horizon last message repeated 18 times
Comment 5 Bill Nottingham 1999-08-31 17:07:59 UTC
Ack. I mean the apmd-3.0beta9 RPMs, currently in Raw Hide.
Comment 6 Bernhard Rosenkraenzer 1999-11-12 18:17:59 UTC
This is not apmd related - it's related to the APM part of the kernel...
Comment 7 Zach Brown 1999-11-12 18:46:59 UTC
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..
Comment 8 Bernhard Rosenkraenzer 2000-07-17 11:09:21 UTC
Closing due to lack of user input