Bug 456352
| Summary: | Defective AMI BIOS present in multiple LGA 775 motherboards by Foxconn, ASUS, and MSI causes ACPI failures | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ryan Farmer <ryan.farmer.personal> | ||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 9 | CC: | jfeeney | ||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-08-06 18:36:40 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
Ryan Farmer
2008-07-23 02:43:57 UTC
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. |