Bug 6670 - S3 resume: IRQ9 SCI not handled -- Macbook Mac-Mini
Summary: S3 resume: IRQ9 SCI not handled -- Macbook Mac-Mini
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Luming Yu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-09 02:15 UTC by Frederic Riss
Modified: 2007-01-17 01:12 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.17-rc6
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
dmesg of a suspend/resume cycle (5.66 KB, text/plain)
2006-06-09 02:18 UTC, Frederic Riss
Details
result of acpidump (90.94 KB, text/plain)
2006-06-21 11:51 UTC, Frederic Riss
Details
re-enable ACPI after S3 resume (325 bytes, patch)
2006-07-04 02:12 UTC, Luming Yu
Details | Diff

Description Frederic Riss 2006-06-09 02:15:09 UTC
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
Comment 1 Frederic Riss 2006-06-09 02:18:02 UTC
Created attachment 8278 [details]
dmesg of a suspend/resume cycle
Comment 2 desrt 2006-06-09 07:23:35 UTC
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.
Comment 3 Frederic Riss 2006-06-10 00:54:13 UTC
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).
Comment 4 Frederic Riss 2006-06-13 01:39:36 UTC
Ryan has posted a fix for this :
http://marc.theaimsgroup.com/?l=linux-kernel&m=115005083610700&w=2

Any comments on that patch ?
Comment 5 Len Brown 2006-06-14 18:20:20 UTC
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...
Comment 6 Luming Yu 2006-06-20 08:38:08 UTC
Please post acpidump output.
Comment 7 Frederic Riss 2006-06-20 09:30:34 UTC
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
Comment 8 Frederic Riss 2006-06-20 11:48:03 UTC
Regarding acpidump, do you prefer a hexdump output or the binary form ?
Comment 9 Luming Yu 2006-06-20 23:37:39 UTC
just run acpidump > macbook-mini-acpidump.dat
Comment 10 Frederic Riss 2006-06-21 11:51:38 UTC
Created attachment 8368 [details]
result of acpidump
Comment 11 Luming Yu 2006-07-04 02:12:53 UTC
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.
Comment 12 Frederic Riss 2006-10-08 03:38:21 UTC
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 :-(
Comment 13 Adrian Bunk 2006-11-24 18:12:26 UTC
What is the status of this issue in kernel 2.6.19-rc6?
Comment 14 Adrian Bunk 2007-01-16 22:56:02 UTC
Please reopen this bug if it's still present in kernel 2.6.20-rc5.
Comment 15 Len Brown 2007-01-17 01:12:27 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.