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: http://www.foxconnchannel.com/product/Motherboards/detail_overview.aspx?ID=en-us0000327 I am using latest BIOS, which seems to allow CPU Frequency scaling to function. Version-Release number of selected component (if applicable): Kernel 2.6.25.10-86 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. How reproducible: Steps to Reproduce: 1. Install Foxconn G33M or G33M-S motherboard. 2. Boot Fedora 3. Try a suspend, resume reboot. Actual results: Depdning on your kernel, either resume no worky, reboot no worky, and in all cases, ugly kernel error messages. Expected results: Suspend, resume, reboot all worky, kernel gives no error messages. Additional info: 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 2.6.25.11-97 System log messages with kernel 2.6.25.11-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 reboot=b 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 reboot=b and not reboot-b , 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. Something like: 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 checksum" 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: Asus P5K-E 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. http://izanbardprince.wordpress.com/2008/07/28/foxconn-says-acpi-issues-are-amis-fault-is-having-them-repair-the-code/ 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.