Created attachment 71852 [details] /proc/* This summer I've purchased a new motherboard, the Asus M5A97 running an AMD Phenom(tm) II X6 1090T Processor. The moment I've received this board, I took my trusted Ubuntu 32bit bootable USB stick (11.04) and loaded up to test if everything was working. There appeared to be no problems so I continued for a few weeks. As time went on, I decided it was an idea to install a 64bit OS and booted the system using a 64bit version of Ubuntu on a USB stick (also 11.04). The system booted extremly slow with any USB devices connected. Reading up on several lists I've tried all tricks to disable USB 2 and 3 support as that may cause issues, to no avail. So I went back to the 32bit install and stayed there for a while. Back home from my vacation I installed my favorite distro, Gentoo and used a 64bit variant. After spending some time setting up the system I found I had the exact same USB issues. I disabled USB 2 and 3 in the kernel and built with USB1.1 only to still see the same errors when connecting anything over USB. Booting works fine, if nothing is connected. I've searched far and low but have not found anything that solved or related much to my errors, since everything appears to be working just fine when switching back to 32bit mode. greg k-h mentioned on the linux-usb list that this might be a 64bit IRQ routing issue thus here the post.
Created attachment 71862 [details] .config 3.0.3 gentoo
Created attachment 71872 [details] dmesg
Created attachment 71882 [details] lsusb
Created attachment 71892 [details] lspci
Created attachment 71902 [details] ver_linux
Please attach complete dmesg logs (not just the USB-related parts) from both the working 32-bit boot and the broken (slow) 64-bit boot. Thanks!
Created attachment 71912 [details] dmesg gentoo-64 full dmesg of a 64bit kernel with usb1 built in; usb2 and 3 not loaded/compiled. No USB connected at all in this dmesg!
Created attachment 71922 [details] dsdt.dsl ASL Input: m5a97.dsl - 7187 lines, 246810 bytes, 1607 keywords Compilation complete. 138 Errors, 1 Warnings, 0 Remarks, 97 Optimizations Ouch. If I where Asus/AMI I'd be very ashamed of this dsdt ... Kinda explains why this bios is so buggy and crap! (it really really is) ACPI: XSDT AMI ACPI: FACP AMI ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20110413/tbfadt-560) ACPI: DSDT INTL ACPI: FACS ACPI: APIC AMI ACPI: MCFG MSFT ACPI: HPET AMI ACPI: SSDT AMD What's interesting is, they actually seem to have used the intel compiler for the dsdt, how that got into the binary with so many errors? Or am I confused here? Anyhow, guess it's time to fix this dsdt :S
* OEM Table ID "A M I" * OEM Revision 0x00000000 (0) * Compiler ID "INTL" * Compiler Version 0x20051117 (537202967) This is a version of iASL from 2005. At some point, some of the code in this DSDT was made illegal, and the compiler now reflects that. Namely, this code: Device (SATA) { Name (_ADR, 0x00110000) If (LEqual (STCL, 0x0101)) { The "If" is an "executable" opcode that appears outside of a control method. This is now illegal ASL code. Typically, the fix is to move this code under _SB_._INI, this method gets executed at table load time. But it's not always real simple to do this.
Created attachment 71942 [details] dmesg ubuntu-32 This is a dmesg from Ubuntu 32bit. I will try to get a 64bit ubuntu kernel booting, but I have doubts I can get it to do that (video doesn't work :S) At the end of the dmesg, I plugged in my mouse, it was working fine here.
Created attachment 71952 [details] dmesg ubuntu-64 I managed to actually get dmesg output from the 'Ubuntu mini-iso'. I think it boots the same stock kernel as the 32bit is. (Used PXE to load it as I can't boot from USB) Also, maybe completly unrelated, but just thought I mentioned it, the r8169 driver in 64bit only works when passing the use_dac=1 argument.
Created attachment 71962 [details] iasl 20051117 As an excersize, I tracked down a 64bit pre-compiled binary for iasl version l20051117 (I it from a deb from an old ubuntu version).
lots of info went onto the mailing lists, I fixed the DSDT to remove all errors. After updating the bios, it now works! http://comments.gmane.org/gmane.linux.acpi.devel/51000
Apparently you were running BIOS "0503 05/30/2011" (from your dmesg logs) when USB did not work. I assume you mean you have a BIOS update from the manufacturer? What version are you running now? Are there any BIOS release notes that give hints about what changed? Can you attach a dmesg log from one of the 64-bit kernels and the new BIOS? We didn't change anything in Linux to fix this, so other people who haven't updated the BIOS should still have the problem. If we can figure out what changed in the BIOS, and if there's an easy way to do a similar workaround in Linux, it would be useful to those people.
Created attachment 72147 [details] Working dmesg from Gentoo running 64bit
Created attachment 72148 [details] diff between 0705 and 0901 biosses
Created attachment 72149 [details] Fixes to dsdt to remove warnings/errors from 0901 bios's dsdt
Created attachment 72150 [details] dsdt from 0901 bios
Bjorn, I think I've posted all this info to the linux-acpi and linux-usb lists in hopes to get your insight. Got near zero feedback actually. Having said that, Yes, I have updated the bios, running BIOS 0901 11/24/2011. Asus is very unhelpful in their list of fixes. To copy paste them all here: M5A97 BIOS 0503 Initial release. M5A97 BIOS 0705 Support new CPUs. Please refer to our website at: http://support.asus.com/cpusupport/cpusupport.aspx M5A97 0810 Beta BIOS Update AMD CPU firmware M5A97 BIOS 0901 Improve syatem stability. The actual zip files contains only the ROM, nothing else. I know i used neweggs 'contact supplier' thing once (before I knew the 64bit bug) about why the board boots so slowly, they said it's an uefi thing. The board boots slow (or slower) when USB devices are connected (even now). I'll re-open this bug then so maybe some good can come from this for others and finding what possibly has caused this? I added the diff of the dsdt from the 2 bios versions and notice nothing related.
ping ... Does the problems still exist in the last upstream kernel?
I'll mark the bug as closed/invalid since it is fixed by updating BIOS and we don't have any more progress on this for a long time.