Created attachment 90091 [details] acpidump output I got a pair of these for my kids for the holidays. They will not boot linux without acpi_no_auto_ssdt. However, without the SSDTs, they don't believe they have a battery, and so will pretty much just run until the battery gives out, without any warnings. I am sure there are other issues I haven't recognized. Booting without acpi_no_auto_ssdt causes the IOAPIC not to be recognized, leading to all kinds of fun. iasl -d spots several issues, and won't even decompile SSDT1 due to a namespace issue. ASL.exe /u also produces similarly broken output.
Created attachment 90101 [details] dmesg output
Created attachment 90111 [details] dmidecode output
Created attachment 90121 [details] /proc/interrupts
Created attachment 90131 [details] lspci -vv output
Oh, a couple of additional bits of info: 1) Issue also exists with Fedora 17 kernels. 2) Windows 8 seems to work as expected.
what do you get if you boot without acpi_no_auto_ssdt?
It dies right after udev Coldplug runs. The keyboard is completely unresponsive (num/caps lock lights don't toggle). I have to hold down the power switch to get it to do anything. I've been trying to use netconsole to capture the output, but haven't had any luck yet. I suspect that the network adapter is getting hosed because of the ACPI issues.
Is there any method I can use to capture the boot up messages that meets the following criteria? 1. Can't require a full boot. 2. Can't be network - Network appears to be hosed by the ACPI issue. 3. Can't be serial - no serial port on the laptop. Is there some way to save the boot message off to a flash drive, or a separate partition on the hard drive or something? I'm really at a loss for how to grab the information when not using acpi_no_auto_ssdt...
This is still an issue for me. Anyone have any idea how to proceed?
Whelp, verified that it isn't the lack of "acpi=copy_dsdt" since that is happening automatically: TOSHIBA Satellite detected - force copy of DSDT to local memory [ 0.022064] ACPI: Forced DSDT copy: length 0x0861D copied locally, original unmapped
Still an issue... any pointers on how to diagnose?
(In reply to Matt Mossholder from comment #11) > Still an issue... any pointers on how to diagnose? Can you try booting with EFI disabled
Matt, can you please try the suggestion in comment #12? can you please try the latest kernel and check if boot otpion "acpi_no_static_ssdt" helps?
In the /proc/interrupt, there is such a line: 9: 0 0 IO-APIC-fasteoi acpi I guess if you loaded some SSDTs, unwanted acpi IRQ storming could be triggered which might be starving other IRQs. If so, either your keyboard or your NIC will be unresponsive. This might be related to this storming: I have to hold down the power switch to get it to do anything. Did you still see this issue using recent upstream kernels?
Bug closed as there is no response from the bug reporter. please feel free to re-open it if you can provide the information required in comment #13 and #14.
This seems to be resolved in 3.16 (Fedora version), if not earlier.