Bug 3575 – apmd queue overflow failure

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 3575 - apmd queue overflow failure

Summary:	apmd queue overflow failure

Status:	CLOSED WORKSFORME

Aliases:	None

Product:	Red Hat Linux
Classification:	Retired
Component:	kernel (Show other bugs)
Sub Component:
Version:	6.0
Hardware:	i386 Linux

Priority	medium Severity high
Target Milestone:	---
Target Release:	---
Assigned To:	Bernhard Rosenkraenzer
QA Contact:
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	1999-06-18 13:11 EDT by burchard
Modified:	2008-05-01 11:37 EDT (History)
CC List:	1 user (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2000-02-03 10:53:54 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description burchard 1999-06-18 13:11:34 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).

Comment 1 Michael K. Johnson 1999-07-13 14:23:59 EDT

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 16:12:59 EDT

Added Zach to CC line so that he can look.

Comment 3 Bill Nottingham 1999-08-19 18:06:59 EDT

Also, try the latest apmd from Raw Hide.

Comment 4 burchard 1999-08-19 18:43:59 EDT

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

Comment 5 Bill Nottingham 1999-08-31 13:07:59 EDT

Ack. I mean the apmd-3.0beta9 RPMs, currently in Raw Hide.

Comment 6 Bernhard Rosenkraenzer 1999-11-12 13:17:59 EST

This is not apmd related - it's related to the APM part of the kernel...

Comment 7 Zach Brown 1999-11-12 13:46:59 EST

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 07:09:21 EDT

Closing due to lack of user input

Comment 9 burchard 2000-07-17 12:12:18 EDT

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)

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