Distribution: The system is running Ubuntu Dapper, but the kernel is a vanilla 2.6.17-rc6 with http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-03-pci/pci-reverse-pci-config-space-restore-order.patch applied on top of it. Hardware Environment: Mac Mini powered by an Intel Core Duo 1.66 GHz(dual core processor) Software Environment: The Mac mini has no BIOS, it uses EFI to boot OSs. Apple provided the Bootcamp utility that emulates a BIOS in order for other OSs than MacOS to boot the beast. This system is installed using BootCamp. Problem Description: During the wakeup from a suspend to RAM, there seems to be an unhandled ACPI interrupt that disables the ACPI interrupt from this point. This prevents ACPI from working after the resume. I'll attach the part of dmesg that corresponds to a suspend/resume cycle. The error is in the middle of it. Steps to reproduce: 1. Put the box to sleep using 's2ram -f -p' (the sky2 network driver must be unloaded prior to that) 2. Wake up 3. look at dmesg
Created attachment 8278 [details] dmesg of a suspend/resume cycle
This problem applies to the Macbook too. Please see this posting for the cause of this problem and how to fix it (but currently it's dirty): http://marc.theaimsgroup.com/?l=linux-acpi&m=114957637501557&w=2 Note for the Macbook: when you fix this bug you'll trigger another one. The irq9 is actually your friend because it slows down how fast your laptop returns from sleep. Once you fix the irq9 thing the Macbook will (often) try to reenable the harddrive before it has properly spun up (and will fail -- and you won't have access to your harddrive anymore). To fix: insert ssleep(5) somewhere in the startup. I inserted it in the resume_device() function in libata-core.c. You can probably get away with much smaller values than 5 seconds -- I have not yet tried.
I confirm that reseting the SCI_EN bit just after we return from sleep will fix the issue for me (and cause the disk issue desrt is reffering to).
Ryan has posted a fix for this : http://marc.theaimsgroup.com/?l=linux-kernel&m=115005083610700&w=2 Any comments on that patch ?
It is likely that this is an issue with the apple firmware that OSX is working around. Note that there are no other EFI firmware systems doing suspend/resume before this one...
Please post acpidump output.
I can of course post acpidump, but is it still worth as a fix for this has hit Linus' tree ? http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5603509137940f4cbc577281cee62110d4097b1b
Regarding acpidump, do you prefer a hexdump output or the binary form ?
just run acpidump > macbook-mini-acpidump.dat
Created attachment 8368 [details] result of acpidump
Created attachment 8486 [details] re-enable ACPI after S3 resume I think we'd better re-enable ACPI , rather than just just re-enalbe SCI_EN bit.
Sorry Len, I tried your patch but it locks the box up on resume. I just discovered that the July 1st ACPICA merge made Linus' fix mentioned above a no-op thus breaking the Mactel's supsend again :-(
What is the status of this issue in kernel 2.6.19-rc6?
Please reopen this bug if it's still present in kernel 2.6.20-rc5.
This issue was caused by a bug in Intel's reference EFI BIOS. The BIOS did not re-enable the SCI on resume from S3 like it is supposed to. Apple discovered this bug, but rather than fixing the firmware, they apparently worked around it in OSX by re-enabling ACPI mode on resume from S3. While that workaround might be okay for Apple, it might be risky if applied to all the Windows-compatible BIOS out there, so the simple workaround of re-enabling the SCI seems more prudent. commit 53a5fbdc2dff55161a206ed1a1385a8fa8055c34 ACPI: Allow setting SCI_EN bit in PM1_CONTROL register went upstream between 2.6.19-rc1 and 2.6.19-rc2 to allow the simple workaround of scribbling on the (read only) SCI_EN bit to work again. closed.