Bug 73339

Summary: apm locks up Asus A7N266VM (nForce chipset)
Product: [Retired] Red Hat Linux Reporter: Toralf <bugzilla>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-10-17 09:22:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Output of dmidecode none

Description Toralf 2002-09-03 08:06:27 UTC
Description of Problem:
I've been trying to setup Red Hat 7.3 on a unit based on the Asus A7N266VM
motherboard, which has an nVidia-220D chipset. Not entirely straight forward,
but with the drivers from nVidia, most things work fine. There is, however, one
remaining issue: All "power management" calls appear to cause a complete hang.


Version-Release number of selected component (if applicable):
2.4.18-3 or 2.4.18-10 (athlon versions)

How Reproducible:
Every time

Steps to Reproduce:
1. service apmd start

or

1. Select Applets->Utility->Battery Charge Monitor in GNOME panel

or

1. Start GNOME panel with default setup (which will involve above mentioned applet.)


Actual Results:
Complete freeze. The only ways out are the reset button and the power switch;
front panel on/off button won't even work.


Expected Results:
Successfull program startup or at least failure with sensible error message. 


Additional Information:
This is more serious than it may sound at first, since starting a GNOME panel
with default setup is enough to lock up the system, probably due to conditional
load of battstat_applet; it looks like the panel will do some sort of APM call
to figure out if the system has a battery, and start applet if it does. What's
even worse, setup test on first-time X server configuration will typically do
that (question: wouldn't it be better to start a simpler session, so that the
GNOME components weren't there to cause confusion?)

Comment 1 Arjan van de Ven 2002-09-03 08:22:44 UTC
I need the output of the "dmidecode" program (part of kernel-utils) to be able
to auto-block APM on your board.

Comment 2 Toralf 2002-09-04 11:57:40 UTC
Right. Ran the program, but forgot to bring the output. This board is in the box
I'm setting up in my living room, which isn't connected to the net yet. I'll try
to attach it later...

Anyhow, I realised after filing this report that the board is ACPI, rather than
APM, compliant. Could that be the cause of the problem? And what exactly is the
status of ACPI support in your kernels etc.?

Comment 3 Arjan van de Ven 2002-09-04 12:02:50 UTC
All I need of the output are the top bits about the bios (eg the bios vendor and
version).

Linux ACPI is not stable enough to ship and I don't forsee that changing in the
next 6 months

Comment 4 Toralf 2002-09-06 11:56:06 UTC
Created attachment 75224 [details]
Output of dmidecode

Comment 5 Toralf 2002-09-06 11:57:24 UTC
Output now attached - the whole thing as it was simplest that way.

Comment 6 Toralf 2002-10-03 12:29:28 UTC
A possibly related problem that I forgot to mention:

When I shut down the system, it is not powered off automatically - it stops at
"power off" message. The machine is then in a state where ATX power button
doesn't work; to switch it off, I have to remove the power chord or press reset,
then power-off. (There is no power button on my PSU.)

Comment 7 Arjan van de Ven 2002-10-17 09:22:42 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2002-206.html


Comment 8 Need Real Name 2002-11-20 14:32:57 UTC
I`ve got a serious problem after I updated my kernel. I should consider that the
NVidia drivers for video dosn't gonna work with the new kernel (the X server
don't starts). Well, I download the drivers from the NVidia web site and I
follow the instructions in the README file. The src RPM can't rebuild the drivers !!
Please, If you are not an advanced user of the redhat system, don't update your
kernel. 
I asked for the right way to fix this problem (if there's any).

Comment 9 Arjan van de Ven 2002-11-20 14:36:05 UTC
jguerra.cl: please read bug #737333

Comment 10 Toralf 2002-11-20 14:45:48 UTC
Above bug id should probably be 73733... I'm not sure it's entirely appropriate,
though. This is not a "binary only" relase, is it?

Anyhow, I had no problems whatsoever rebuilding the drivers. How exactly does it
fail?

Comment 11 Arjan van de Ven 2002-11-20 14:47:33 UTC
eh yeah 73733
but yes the nvidia drivers are binary only (with a thin glue layer)