Bug 101525 - X on Toshiba laptop logs "PM Event received: Power Status Change"
Summary: X on Toshiba laptop logs "PM Event received: Power Status Change"
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 7.3
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-08-02 16:54 UTC by Roy Kidder
Modified: 2007-04-18 16:56 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-02-03 02:04:52 UTC
Embargoed:


Attachments (Terms of Use)

Description Roy Kidder 2003-08-02 16:54:51 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314

Description of problem:
XFree86 (or possibly xdm) on a Toshiba Satellite 4090XDVD writes the message
"(II) PM Event received: Power Status Change" to /var/log/XFree86.0.log with
annoying frequency. It actually causes the hard disc to become so involved with
attemtping to write the log, that other applications (even X itself) become
unresponsive for several seconds at a time. Google search generates hits where
people think it's a problem with xdm (my laptop does indeed boot to init level
5). One Google hit stated that this issue is related to the kernel reporting
different minutes of battery time left. In fact, when watching /proc/apm the
battery minutes fluctuate between 141 minutes and 146 minutes, even when on AC
power.

Version-Release number of selected component (if applicable):
XFree86-4.2.1-13.73.3, XFree86-xdm-4.2.1-13.73.3

How reproducible:
Always

Steps to Reproduce:
1. Happens whenever X runs (only tested in init level 5).

Additional info:

Comment 1 Mike A. Harris 2004-02-03 02:04:52 UTC
XFree86 logs to the log file things that X developers find useful
or require in order to debug the server for various problems.  This
includes things like power events, as such are useful to developers
for debugging problems.  It is entirely possible for things outside
the control of XFree86 to generate events that cause the X server
to log them to the log file and fill up disk space over time.

The default X server log messages, and verbosity, are intended not
for end user convenience, but rather for developer convenience
when problems arise.  Under normal working conditions, this works
fine for both developers and end users.  However, end users who
have problematic hardware, misconfigured hardware or software,
or software which conflicts with the X server and might cause
excessive data items to be logged are certainly possible.

It sounds to me, like the cause of your problem is either faulty
hardware, or possibly a kernel bug which causes excessive APM
events to be sent to the X server.  Changing the X server to not
log this information is not the solution, as that just hides the
problem and does not solve it.  It also would make power events
no longer log in the log file and thus become invisible to
developers troubleshooting log files.

The proper solution, is to figure out what is the _cause_ of the
problem rather than bandaiding over the side effects that are
caused by the problematic system.  I will not remove these
messages from the X server, nor change the default verbosity of
the X server, as it is set for developer preference, and under
normal circumstances, that is not a problem.

You may however wish to work around the log file side effect problem
by changing the verbosity of the server on your own system by using
the -logverbose option documented in the Xserver or XFree86 manpage.
That will allow you to ignore the messages, however the generated
log files are less useful to developers who might be looking at
your log files trying to diagnose this or other problems.

The true solution to the problem is to find out the real cause of
the misreported events, and then fix that.  That might be a faulty
kernel module, or faulty hardware.  Either way, this isn't an
XFree86 bug, so I'm closing it NOTABUG.

Also, as a side note, we no longer support Red Hat Linux 8.0 (as
of Dec 31, 2003), and so I recommend upgrading your OS to Fedora
Core 1, or Red Hat Enterprise Linux 3.  If the problem you are
encountering is kernel related, it's possible the new OS release
may solve or workaround this issue for you.

Closing as 'NOTABUG'


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