Description of problem:
Multiple ACPI problems and warnings on boot, PC will suspend and resume, but on
the next reboot, it hangs and requires a hard reset, Thermal Zone and Fan
control support also appear to be missing, I had to set the BIOS to take control
of the fans, or else they run at 100% at all times.
The website for this motherboard:
I am using latest BIOS, which seems to allow CPU Frequency scaling to function.
Version-Release number of selected component (if applicable):
Running a 2.6.26-git9 kernel appears to fix (some?) of this in that ACPI: Failed
To Attach Device messages are gone and PC suspends, resumes, and reboots, still
get checksum error relating to tbautils.
Behaviour is the same with ACPI 1, 2, or 3.
Steps to Reproduce:
1. Install Foxconn G33M or G33M-S motherboard.
2. Boot Fedora
3. Try a suspend, resume reboot.
Depdning on your kernel, either resume no worky, reboot no worky, and in all
cases, ugly kernel error messages.
Suspend, resume, reboot all worky, kernel gives no error messages.
I've attached a lot of all my kernel related messages.
I've attempted to ask Foxconn about this, and they recommended I remove all of
my RAM and see if the problem continues. (OK, not as useful as funny, but still)
Created attachment 312410 [details]
Clip of kernel messages on boot, with shoddy Foxconn motherboard
Created attachment 312417 [details]
Clip from /var/log/messages with 126.96.36.199-97
System log messages with kernel 188.8.131.52-97, I installed this kernel because
it appears to be more verbose.
Linux correctly reports that the table has an incorrect checksum, but that
should be purely cosmetic. The only obvious remaining bug is that the machine
fails to reboot after a suspend to RAM? Does booting with
as a kernel command option work around this?
Man I suck at bugzilla. Reopening since I closed it by accident.
reboot-b has no effect.
I've sent you my ACPI dump.
Foxconn is apparently working on some kind of a patch, and has stated that they
will make an official announcement over why this happened on Monday.
They've been frantically working on getting the BIOS to boot up Linux and
correctly interface with it on their test machines.
From what I can tell an improved BIOS ROM is on the way?
I will post link to the ROM when they put it on their site so we can close this bug.
Just to confirm, you tried
, right? It needs to be passed as a kernel option from grub.
yes, I put reboot=b in menu.lst, same behavior
Get an error on resume that I couldn't make out before.
ATA 6 revalidation error.
Just to go over what Matthew has stated on his blog, paraphrasing:
"There's no way altering the DSDT fixes any of the errors, especially not the
It does indeed fix all of that, or at least no errors in my log when I change to
_OSI and Store Zero (What Vista and XP get), and remove the _OS reference to
"Linux", so I don't know, I'm even more uncomfortable with this, he says this
shouldn't happen, but it does.
I have been in touch with Foxconn several times today, this bug also affects:
P5E WS and P5E WS PRO
MSI P965 series
It is the BIOS that is defective, not the chipset.
American Megatrends (AMI) shipped the defective BIOS, if yours is an Award BIOS,
this is not an issue.
I've been told to expect the Foxconn fix within a matter of days, users of ASUS
or MSI motherboards are encouraged to contact them for the fix and reference
that Foxconn has confirmed that the AMI BIOS is defective.
I would also like to say before anyone asks that despite what original post
says, I never was able to get it to reboot properly after suspend no matter what
I did, I was deliriously tired (and typing angry) when I wrote this up, trying
to figure out what was wrong, if the problem would go away with the newest kernels.
BIOS fix for Foxconn motherboards very soon, I am beta testing a new BIOS that
resolves all the party poopers as long as you're using kernel 2.6.26
MSI and ASUS appear to want to have nothing to do with this, thats my hunch
anyway, kindly pester them if you're their customer would be my suggestion, but
we all know that would make me a hypocrite. :P
I've been in communication with the AMI engineers. The issue appears to be that Linux doesn't clear the WAK_STS flag on resume, which causes the BIOS to think that a reset is actually a resume. I've got a test board now, so will check this later today. Should be a trivial patch.
Fix applied to Rawhide and sent upstream. Should land within the next day or so. Tested successfully on a G33M board.