M2N-MX power management under XP

  • Thread starter Thread starter Yousuf Khan
  • Start date Start date
Y

Yousuf Khan

I've got a machine with an M2N-MX mobo. This thing doesn't seem to allow
power management under XP! Even basic things like Standby and Hibernate
are missing. When you press the "Turn Off Computer" button, the only
options are Restart and Turn Off; Standby is greyed out, and Hibernate
isn't even presented as an option in Power Management properties.

I've flashed it to the latest available AMI-BIOS (0704). I've set the
ACPI support from ACPI 1.0 to 2.0 to 3.0 and back down, nothing has
fixed the issue.

I've also got it running under Ubuntu 7.04 64-bit, and it's the same
issues there. Under it, the temperature sensor utilities tell me "no
sensors found". But interestingly the AMD Cool'n'Quiet continues to
work, I see the two processor cores (Athlon X2 4600+) changing speeds up
and down independently like normal.

I have another system with an Asus mobo, M2NPV-VM, with the same basic
chipset (Nforce 430), but with a Phoenix BIOS which is working perfectly.

Any ideas?

Yousuf Khan
 
Yousuf said:
I've got a machine with an M2N-MX mobo. This thing doesn't seem to allow
power management under XP! Even basic things like Standby and Hibernate
are missing. When you press the "Turn Off Computer" button, the only
options are Restart and Turn Off; Standby is greyed out, and Hibernate
isn't even presented as an option in Power Management properties.

I've flashed it to the latest available AMI-BIOS (0704). I've set the
ACPI support from ACPI 1.0 to 2.0 to 3.0 and back down, nothing has
fixed the issue.

I've also got it running under Ubuntu 7.04 64-bit, and it's the same
issues there. Under it, the temperature sensor utilities tell me "no
sensors found". But interestingly the AMD Cool'n'Quiet continues to
work, I see the two processor cores (Athlon X2 4600+) changing speeds up
and down independently like normal.

I have another system with an Asus mobo, M2NPV-VM, with the same basic
chipset (Nforce 430), but with a Phoenix BIOS which is working perfectly.

Any ideas?

Yousuf Khan

If you go to Device Manager, and check the properties of "Computer",
does it say "Standard PC" or "ACPI Multiprocesssor PC" ? If the HAL
is "Standard PC", that would explain the limited options to turn off
the computer.

If you did a clean install, did you get an error message, about some
problem with ACPI ? Like "not compliant" ? I had that happen with one
Asus BIOS, where when I tried to install, the ACPI tables from the BIOS,
were not to the OS installer's liking. I ended up with a "Standard PC"
as a result, and had to endure that "it is safe to turn off your PC"
crap.

Once I tried a later version of the BIOS, then I could install an
ACPI HAL, as normal.

Some HAL changes are easy. Changing from one flavor of ACPI HAL
to another, is a "driver change". But I suspect that escaping from
"Standard PC" is not going to be so easy.

http://support.microsoft.com/kb/237556/en-us

During an OS install, you can press F5 to force a HAL. Normally
I think it would select an ACPI HAL without any coaching, if
the ingredients are there.

http://support.microsoft.com/kb/299340/en-us

Also, when using Ubuntu, did you examine the log messages that
occur during boot ? Were there any complaints about the ACPI tables
passed by the BIOS ? You might get more useful info from Linux, than
from Windows, if there is a problem.

There are also a couple of reports here, of weirdness with that
motherboard. One guy could not get both cores to be recognized
when using a dual core processor. (Make sure you report your problem
to Asus tech support, so maybe in three months time, you'll see
a new BIOS release with a fix. Asus is probably not monitoring
these forums, looking for trouble.)

http://vip.asus.com/forum/topic.asp...1&model=M2N-MX&page_size=100&page=1&count=100

Paul
 
If you go to Device Manager, and check the properties of "Computer",
does it say "Standard PC" or "ACPI Multiprocesssor PC" ? If the HAL
is "Standard PC", that would explain the limited options to turn off
the computer.

It says ACPI Multiprocessor PC.
If you did a clean install, did you get an error message, about some
problem with ACPI ? Like "not compliant" ? I had that happen with one
Asus BIOS, where when I tried to install, the ACPI tables from the BIOS,
were not to the OS installer's liking. I ended up with a "Standard PC"
as a result, and had to endure that "it is safe to turn off your PC"
crap.

Yeah, it was a clean install, no problems, which is what's surprising
me about this problem. The only problem I see in the hardware is a
little yellow exclamation point on some USB composite device, but
everything else is working fine, including all USB devices.

Speaking of turning off your PC, when I do choose "Turn off PC", it
doesn't turn off, it reboots. I have to quickly press the power button
before it boots to an OS again.

Also, when using Ubuntu, did you examine the log messages that
occur during boot ? Were there any complaints about the ACPI tables
passed by the BIOS ? You might get more useful info from Linux, than
from Windows, if there is a problem.

No, I didn't check the messages in Ubuntu yet, but I did check the
Windows logs, and there were no alerts of any kind in there. I don't
know if I have to set some error-check level in Windows to see any
messages of this type though.

Throwing something else out from out of left-field. Earlier during the
installation process for this machine I was experimenting with trying
to get the Xen virtualization hypervisor going with Ubuntu. I couldn't
get it going, so I reinstalled Ubuntu from scratch without any of the
Xen stuff in there. I'm wondering if maybe some kind of Xen stub is
left behind that gets loaded automatically -- and invisibly -- with
Grub? This might explain the reduction of features in the PC: they're
being virtualized away. It's a very slim chance, I'll admit.
There are also a couple of reports here, of weirdness with that
motherboard. One guy could not get both cores to be recognized
when using a dual core processor. (Make sure you report your problem
to Asus tech support, so maybe in three months time, you'll see
a new BIOS release with a fix. Asus is probably not monitoring
these forums, looking for trouble.)

http://vip.asus.com/forum/topic.aspx?SLanguage=en-us&board_id=1&model...

I guess I'll have to bite the bullet and call them.
 
bbbl67 said:
It says ACPI Multiprocessor PC.


Yeah, it was a clean install, no problems, which is what's surprising
me about this problem. The only problem I see in the hardware is a
little yellow exclamation point on some USB composite device, but
everything else is working fine, including all USB devices.

Speaking of turning off your PC, when I do choose "Turn off PC", it
doesn't turn off, it reboots. I have to quickly press the power button
before it boots to an OS again.



No, I didn't check the messages in Ubuntu yet, but I did check the
Windows logs, and there were no alerts of any kind in there. I don't
know if I have to set some error-check level in Windows to see any
messages of this type though.

Throwing something else out from out of left-field. Earlier during the
installation process for this machine I was experimenting with trying
to get the Xen virtualization hypervisor going with Ubuntu. I couldn't
get it going, so I reinstalled Ubuntu from scratch without any of the
Xen stuff in there. I'm wondering if maybe some kind of Xen stub is
left behind that gets loaded automatically -- and invisibly -- with
Grub? This might explain the reduction of features in the PC: they're
being virtualized away. It's a very slim chance, I'll admit.


I guess I'll have to bite the bullet and call them.

Can you test with a spare disk and just install Windows on it ?
Just to see if sanity is at all possible.

Paul
 
Can you test with a spare disk and just install Windows on it ?
Just to see if sanity is at all possible.

Just as an update. Well, I did get through to Asus tech support
finally. Told their tech support guy the symptoms under Windows XP. I
also then made the fatal mistake of mentioning that I had Linux
installed on the box. Well, it is usually a fatal mistake because tech
support is usually looking for any excuse to pass off the blame on
anything that they can. I told him that the same problems were
occurring under Ubuntu Linux, and to my astonishment, this technician
actually said that that proved to him that there was a problem with
the motherboard! He told me to get in touch with their RMA department.
Anyways, the techsup guy thinks that perhaps the sensor chips on the
board are defective.

Yousuf Khan
 
bbbl67 said:
Just as an update. Well, I did get through to Asus tech support
finally. Told their tech support guy the symptoms under Windows XP. I
also then made the fatal mistake of mentioning that I had Linux
installed on the box. Well, it is usually a fatal mistake because tech
support is usually looking for any excuse to pass off the blame on
anything that they can. I told him that the same problems were
occurring under Ubuntu Linux, and to my astonishment, this technician
actually said that that proved to him that there was a problem with
the motherboard! He told me to get in touch with their RMA department.
Anyways, the techsup guy thinks that perhaps the sensor chips on the
board are defective.

Yousuf Khan

It'll be interesting to see if an RMA can fix it.
Usually on those boards, the hardware monitor is part of the SuperI/O
chip. If the SuperI/O was bad, you'd think there would be other
symptoms, such as defective floppy, serial port, parallel port etc.
It would be a bit strange for only the sensor section to be bad.

Paul
 
Paul said:
It'll be interesting to see if an RMA can fix it.
Usually on those boards, the hardware monitor is part of the SuperI/O
chip. If the SuperI/O was bad, you'd think there would be other
symptoms, such as defective floppy, serial port, parallel port etc.
It would be a bit strange for only the sensor section to be bad.


The thing is, it's possible that all of those things are bad too, but it
also happens to be a whole bunch of the things that we're *not* using.
No floppy drive attached on the system, no need for serial port, printer
services is obtained through USB or network, etc. Super I/O is old
legacy stuff these days.

Yousuf Khan
 
Paul said:
It'll be interesting to see if an RMA can fix it.
Usually on those boards, the hardware monitor is part of the SuperI/O
chip. If the SuperI/O was bad, you'd think there would be other
symptoms, such as defective floppy, serial port, parallel port etc.
It would be a bit strange for only the sensor section to be bad.

Paul

It didn't fix a thing. According to the worksheet, they replaced the
board with a new board, but the exact same issues are cropping up again.
I don't know if I want to bother with RMA'ing it again.

Yousuf Khan
 
Yousuf said:
It didn't fix a thing. According to the worksheet, they replaced the
board with a new board, but the exact same issues are cropping up again.
I don't know if I want to bother with RMA'ing it again.

Yousuf Khan

What BIOS revision is installed in the board now ? I took a look
at the BIOS info on the Asus download site for M2N-MX, but the change log
doesn't mention anything close to your symptoms. Other than
changing BIOS versions, I would go back to software testing.

On shutdown, is it still automatically restarting again ?
Sometimes that is related to the Magic Packet wakeup feature
of a network interface, as some network interfaces basically
wake up when any packet is received. Disconnecting the network
cable, then testing shutdown, may show a difference in behavior,
if that is the case.

Paul
 
What BIOS revision is installed in the board now ? I took a look
at the BIOS info on the Asus download site for M2N-MX, but the change log
doesn't mention anything close to your symptoms. Other than
changing BIOS versions, I would go back to software testing.

On shutdown, is it still automatically restarting again ?
Sometimes that is related to the Magic Packet wakeup feature
of a network interface, as some network interfaces basically
wake up when any packet is received. Disconnecting the network
cable, then testing shutdown, may show a difference in behavior,
if that is the case.

Or mouse. My wife's ThinkPad was waking up randomly. It turned out
the mouse was set to wake it up. The slightest vibration, such as
waking by, would set it off.
 
Paul said:
What BIOS revision is installed in the board now ? I took a look
at the BIOS info on the Asus download site for M2N-MX, but the change log
doesn't mention anything close to your symptoms. Other than
changing BIOS versions, I would go back to software testing.

I had downloaded and installed the latest BIOS from Asus, both times
(before and after RMA'ing the board).
On shutdown, is it still automatically restarting again ?
Sometimes that is related to the Magic Packet wakeup feature
of a network interface, as some network interfaces basically
wake up when any packet is received. Disconnecting the network
cable, then testing shutdown, may show a difference in behavior,
if that is the case.


I think the key factor to this problem is that power-down states aren't
supported on this board for some reason. That would probably also
explain why shutdown and reboot are affected, as those are also
power-down states (albeit more primitive ones).

Also the fact the problem also occurs under Linux indicates that it's a
bit more than just a software issue. The Ubuntu standard Linux kernel
boots up fine on this board, but none of the ACPI temperature sensor
utilities (lm-sensor) work with it. But a Xen-virtualization version of
the Ubuntu kernel starts booting but then aborts quickly after
complaining about an ACPI related issue (scrolls by too fast for me to
see it completely). All of these same utilities and kernels work just
fine on my other Asus motherboard with the same chipset. The major
difference between the two boards is the good one uses a Phoenix BIOS
(Asus M2NPV-VM), while the crappy one uses an AMI BIOS (Asus M2N-MX).

Right now Asus has had me try changing the power supply (told me it had
to be an ACPI 2.0 compatible PS). When that didn't fix anything, then
they are now telling me to try to switch out the RAM and the processor.

I got sick of this crap and bought a new motherboard, an M2A-VM. Yes,
ironically it's an Asus again, it's the only thing the local stores
carry in stock these days. The difference here of course that it's an
AMD 690G chipset now rather than an Nforce 430. I haven't installed it
yet, but I'll see how it goes. I've been curious about the AMD/ATI
chipsets for a while now, anyways.

Yousuf Khan
 
Yousuf said:
I had downloaded and installed the latest BIOS from Asus, both times
(before and after RMA'ing the board).



I think the key factor to this problem is that power-down states aren't
supported on this board for some reason. That would probably also
explain why shutdown and reboot are affected, as those are also
power-down states (albeit more primitive ones).

Also the fact the problem also occurs under Linux indicates that it's a
bit more than just a software issue. The Ubuntu standard Linux kernel
boots up fine on this board, but none of the ACPI temperature sensor
utilities (lm-sensor) work with it. But a Xen-virtualization version of
the Ubuntu kernel starts booting but then aborts quickly after
complaining about an ACPI related issue (scrolls by too fast for me to
see it completely). All of these same utilities and kernels work just
fine on my other Asus motherboard with the same chipset. The major
difference between the two boards is the good one uses a Phoenix BIOS
(Asus M2NPV-VM), while the crappy one uses an AMI BIOS (Asus M2N-MX).

Right now Asus has had me try changing the power supply (told me it had
to be an ACPI 2.0 compatible PS). When that didn't fix anything, then
they are now telling me to try to switch out the RAM and the processor.

I got sick of this crap and bought a new motherboard, an M2A-VM. Yes,
ironically it's an Asus again, it's the only thing the local stores
carry in stock these days. The difference here of course that it's an
AMD 690G chipset now rather than an Nforce 430. I haven't installed it
yet, but I'll see how it goes. I've been curious about the AMD/ATI
chipsets for a while now, anyways.

Yousuf Khan

Maybe you'll get lucky, and the BIOS will pass a nice set of ACPI
tables to the OS :-)

Linux usually puts some messages on the screen (dmesg or the like)
telling the user what tables were passed. It would be interesting
to compare the dmesg from the broken board, with the new one.

ACPI: RSDP (v000 VIA694 ) @ 0x000f7400
ACPI: RSDT (v001 VIA694 AWRDACPI 16944.11825) @ 0x1fff3000
ACPI: FADT (v001 VIA694 AWRDACPI 16944.11825) @ 0x1fff3040
ACPI: DSDT (v001 VIA694 AWRDACPI 00000.04096) @ 0x00000000
ACPI: BIOS passes blacklist
ACPI: MADT not present

I have no idea what those do :-)

Paul
 
Back
Top