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?)
I need the output of the "dmidecode" program (part of kernel-utils) to be able to auto-block APM on your board.
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.?
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
Created attachment 75224 [details] Output of dmidecode
Output now attached - the whole thing as it was simplest that way.
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.)
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
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).
jguerra.cl: please read bug #737333
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?
eh yeah 73733 but yes the nvidia drivers are binary only (with a thin glue layer)