Hi,
my Mac mini Core Duo doesn't wake up from suspend to RAM anymore with
2.6.27.4. It works with 2.6.27.3. I enabled pm_trace, but dmesg | grep
"hash matches" didn't show anything after resume. I tried 2.6.27.5,
which also failed to resume.
The system is i386, the hardware is basically Intel based: Core Duo
T2300 CPU, Intel graphics i945, ICH7, Marvell GbE (sky2), a SATA hard
disk, PATA DVD drive, a Firewire hard disk, and a lot of USB devices.
Does that ring any bells? Any hints what commit I should try to revert?
Regards,
Tino
On Sun, Nov 09, 2008 at 09:28:30PM +0100, Tino Keitel wrote:
> Hi,
>
> my Mac mini Core Duo doesn't wake up from suspend to RAM anymore with
> 2.6.27.4. It works with 2.6.27.3. I enabled pm_trace, but dmesg | grep
> "hash matches" didn't show anything after resume. I tried 2.6.27.5,
> which also failed to resume.
>
> The system is i386, the hardware is basically Intel based: Core Duo
> T2300 CPU, Intel graphics i945, ICH7, Marvell GbE (sky2), a SATA hard
> disk, PATA DVD drive, a Firewire hard disk, and a lot of USB devices.
>
> Does that ring any bells? Any hints what commit I should try to revert?
Can you run 'git bisect' on the patches in 2.6.27.4 to see which one
broke your box?
thanks,
greg k-h
On Sunday, 9 of November 2008, Greg KH wrote:
> On Sun, Nov 09, 2008 at 09:28:30PM +0100, Tino Keitel wrote:
> > Hi,
> >
> > my Mac mini Core Duo doesn't wake up from suspend to RAM anymore with
> > 2.6.27.4. It works with 2.6.27.3. I enabled pm_trace, but dmesg | grep
> > "hash matches" didn't show anything after resume. I tried 2.6.27.5,
> > which also failed to resume.
> >
> > The system is i386, the hardware is basically Intel based: Core Duo
> > T2300 CPU, Intel graphics i945, ICH7, Marvell GbE (sky2), a SATA hard
> > disk, PATA DVD drive, a Firewire hard disk, and a lot of USB devices.
> >
> > Does that ring any bells? Any hints what commit I should try to revert?
>
> Can you run 'git bisect' on the patches in 2.6.27.4 to see which one
> broke your box?
I would start from these commits:
3b987ac961486373f91191b14291b331fa546072
"ACPI suspend: Always use the 32-bit waking vector"
66036f5862883fcc9f7ff8550685a5a3de1a57e4
"ACPI Suspend: Enable ACPI during resume if SCI_EN is not set"
If none of them causes this problem to happen, I have no idea what can, so
please bisect in this case.
If any of them breaks suspend for you, we'd have to find out why, because
both of them are rather important bug fixes.
Thanks,
Rafael
On Sun, Nov 09, 2008 at 21:51:57 +0100, Rafael J. Wysocki wrote:
> On Sunday, 9 of November 2008, Greg KH wrote:
> > On Sun, Nov 09, 2008 at 09:28:30PM +0100, Tino Keitel wrote:
> > > Hi,
> > >
> > > my Mac mini Core Duo doesn't wake up from suspend to RAM anymore with
> > > 2.6.27.4. It works with 2.6.27.3. I enabled pm_trace, but dmesg | grep
> > > "hash matches" didn't show anything after resume. I tried 2.6.27.5,
> > > which also failed to resume.
> > >
> > > The system is i386, the hardware is basically Intel based: Core Duo
> > > T2300 CPU, Intel graphics i945, ICH7, Marvell GbE (sky2), a SATA hard
> > > disk, PATA DVD drive, a Firewire hard disk, and a lot of USB devices.
> > >
> > > Does that ring any bells? Any hints what commit I should try to revert?
> >
> > Can you run 'git bisect' on the patches in 2.6.27.4 to see which one
> > broke your box?
>
> I would start from these commits:
>
> 3b987ac961486373f91191b14291b331fa546072
> "ACPI suspend: Always use the 32-bit waking vector"
>
> 66036f5862883fcc9f7ff8550685a5a3de1a57e4
> "ACPI Suspend: Enable ACPI during resume if SCI_EN is not set"
Thanks Rafael, 2.6.27.5 with 66036f5862883fcc9f7ff8550685a5a3de1a57e4
reverted resumes fine.
Regards,
Tino
On Sun, Nov 09, 2008 at 21:51:57 +0100, Rafael J. Wysocki wrote:
> On Sunday, 9 of November 2008, Greg KH wrote:
> > On Sun, Nov 09, 2008 at 09:28:30PM +0100, Tino Keitel wrote:
> > > Hi,
> > >
> > > my Mac mini Core Duo doesn't wake up from suspend to RAM anymore with
> > > 2.6.27.4. It works with 2.6.27.3. I enabled pm_trace, but dmesg | grep
> > > "hash matches" didn't show anything after resume. I tried 2.6.27.5,
> > > which also failed to resume.
> > >
> > > The system is i386, the hardware is basically Intel based: Core Duo
> > > T2300 CPU, Intel graphics i945, ICH7, Marvell GbE (sky2), a SATA hard
> > > disk, PATA DVD drive, a Firewire hard disk, and a lot of USB devices.
> > >
> > > Does that ring any bells? Any hints what commit I should try to revert?
> >
> > Can you run 'git bisect' on the patches in 2.6.27.4 to see which one
> > broke your box?
>
> I would start from these commits:
>
> 3b987ac961486373f91191b14291b331fa546072
> "ACPI suspend: Always use the 32-bit waking vector"
>
> 66036f5862883fcc9f7ff8550685a5a3de1a57e4
> "ACPI Suspend: Enable ACPI during resume if SCI_EN is not set"
Thanks Rafael, 2.6.27.5 with 66036f5862883fcc9f7ff8550685a5a3de1a57e4
reverted resumes fine.
Regards,
Tino
On Tuesday, 11 of November 2008, Tino Keitel wrote:
> On Sun, Nov 09, 2008 at 21:51:57 +0100, Rafael J. Wysocki wrote:
> > On Sunday, 9 of November 2008, Greg KH wrote:
> > > On Sun, Nov 09, 2008 at 09:28:30PM +0100, Tino Keitel wrote:
> > > > Hi,
> > > >
> > > > my Mac mini Core Duo doesn't wake up from suspend to RAM anymore with
> > > > 2.6.27.4. It works with 2.6.27.3. I enabled pm_trace, but dmesg | grep
> > > > "hash matches" didn't show anything after resume. I tried 2.6.27.5,
> > > > which also failed to resume.
> > > >
> > > > The system is i386, the hardware is basically Intel based: Core Duo
> > > > T2300 CPU, Intel graphics i945, ICH7, Marvell GbE (sky2), a SATA hard
> > > > disk, PATA DVD drive, a Firewire hard disk, and a lot of USB devices.
> > > >
> > > > Does that ring any bells? Any hints what commit I should try to revert?
> > >
> > > Can you run 'git bisect' on the patches in 2.6.27.4 to see which one
> > > broke your box?
> >
> > I would start from these commits:
> >
> > 3b987ac961486373f91191b14291b331fa546072
> > "ACPI suspend: Always use the 32-bit waking vector"
> >
> > 66036f5862883fcc9f7ff8550685a5a3de1a57e4
> > "ACPI Suspend: Enable ACPI during resume if SCI_EN is not set"
>
> Thanks Rafael, 2.6.27.5 with 66036f5862883fcc9f7ff8550685a5a3de1a57e4
> reverted resumes fine.
This really is not a good news, because this commit evidently fixes at least
several systems.
First, let's try to remove things that we shouldn't be doing.
Please apply the patch below to 2.6.27.5 without reverting that commit and see
if that works.
Thanks,
Rafael
---
drivers/acpi/pci_link.c | 4 ----
1 file changed, 4 deletions(-)
Index: linux-2.6/drivers/acpi/pci_link.c
===================================================================
--- linux-2.6.orig/drivers/acpi/pci_link.c
+++ linux-2.6/drivers/acpi/pci_link.c
@@ -796,10 +796,6 @@ static int irqrouter_resume(struct sys_d
struct list_head *node = NULL;
struct acpi_pci_link *link = NULL;
-
- /* Make sure SCI is enabled again (Apple firmware bug?) */
- acpi_set_register(ACPI_BITREG_SCI_ENABLE, 1);
-
list_for_each(node, &acpi_link.entries) {
link = list_entry(node, struct acpi_pci_link, node);
if (!link) {
On Tue, Nov 11, 2008 at 15:16:08 +0100, Rafael J. Wysocki wrote:
[...]
> This really is not a good news, because this commit evidently fixes at least
> several systems.
>
> First, let's try to remove things that we shouldn't be doing.
>
> Please apply the patch below to 2.6.27.5 without reverting that commit and see
> if that works.
It doesn't work. 2.6.27.5 with the patch applied hangs at resume.
Regards,
Tino
On Tuesday, 11 of November 2008, Tino Keitel wrote:
> On Tue, Nov 11, 2008 at 15:16:08 +0100, Rafael J. Wysocki wrote:
>
> [...]
>
> > This really is not a good news, because this commit evidently fixes at least
> > several systems.
> >
> > First, let's try to remove things that we shouldn't be doing.
> >
> > Please apply the patch below to 2.6.27.5 without reverting that commit and see
> > if that works.
>
> It doesn't work. 2.6.27.5 with the patch applied hangs at resume.
Well, this appears to be a broken BIOS thing. Perhaps we'll have to blacklist
the box or something.
Is there any possibility to get some information about where exactly it hangs?
Rafael
On Wednesday, 12 of November 2008, Rafael J. Wysocki wrote:
> On Tuesday, 11 of November 2008, Tino Keitel wrote:
> > On Tue, Nov 11, 2008 at 15:16:08 +0100, Rafael J. Wysocki wrote:
> >
> > [...]
> >
> > > This really is not a good news, because this commit evidently fixes at least
> > > several systems.
> > >
> > > First, let's try to remove things that we shouldn't be doing.
> > >
> > > Please apply the patch below to 2.6.27.5 without reverting that commit and see
> > > if that works.
> >
> > It doesn't work. 2.6.27.5 with the patch applied hangs at resume.
>
> Well, this appears to be a broken BIOS thing. Perhaps we'll have to blacklist
> the box or something.
>
> Is there any possibility to get some information about where exactly it hangs?
Also, can you check this patch on top of 2.6.27.4 and see what happens?
Rafael
---
drivers/acpi/pci_link.c | 4 ----
drivers/acpi/sleep/main.c | 3 ++-
2 files changed, 2 insertions(+), 5 deletions(-)
Index: linux-2.6/drivers/acpi/pci_link.c
===================================================================
--- linux-2.6.orig/drivers/acpi/pci_link.c
+++ linux-2.6/drivers/acpi/pci_link.c
@@ -796,10 +796,6 @@ static int irqrouter_resume(struct sys_d
struct list_head *node = NULL;
struct acpi_pci_link *link = NULL;
-
- /* Make sure SCI is enabled again (Apple firmware bug?) */
- acpi_set_register(ACPI_BITREG_SCI_ENABLE, 1);
-
list_for_each(node, &acpi_link.entries) {
link = list_entry(node, struct acpi_pci_link, node);
if (!link) {
Index: linux-2.6/drivers/acpi/sleep/main.c
===================================================================
--- linux-2.6.orig/drivers/acpi/sleep/main.c
+++ linux-2.6/drivers/acpi/sleep/main.c
@@ -249,7 +249,8 @@ static int acpi_suspend_enter(suspend_st
}
/* If ACPI is not enabled by the BIOS, we need to enable it here. */
- acpi_enable();
+ acpi_set_register(ACPI_BITREG_SCI_ENABLE, 1);
+ /*acpi_enable();*/
/* Reprogram control registers and execute _BFS */
acpi_leave_sleep_state_prep(acpi_state);
On Wed, Nov 12, 2008 at 00:48:06 +0100, Rafael J. Wysocki wrote:
[...]
> Is there any possibility to get some information about where exactly
> it hangs?
Any idea how to do this? I already tried pm_trace, and there isn't a
serial interface. The screen is black when it hangs.
Regards,
Tino
On Wed, Nov 12, 2008 at 01:03:54 +0100, Rafael J. Wysocki wrote:
[...]
> Also, can you check this patch on top of 2.6.27.4 and see what happens?
With that patch, resume works (although I used 2.6.27.5 and not
2.6.27.5, if that matters).
Regards,
Tino
On Wednesday, 12 of November 2008, Tino Keitel wrote:
> On Wed, Nov 12, 2008 at 01:03:54 +0100, Rafael J. Wysocki wrote:
>
> [...]
>
> > Also, can you check this patch on top of 2.6.27.4 and see what happens?
>
> With that patch, resume works (although I used 2.6.27.5 and not
> 2.6.27.5, if that matters).
It shouldn't really matter.
Thanks for testing and please send me the output of dmidecode.
It seems that blacklisting may be the only way to handle your box. :-(
Thanks,
Rafael
On Wed, Nov 12, 2008 at 22:41:08 +0100, Rafael J. Wysocki wrote:
> On Wednesday, 12 of November 2008, Tino Keitel wrote:
> > On Wed, Nov 12, 2008 at 01:03:54 +0100, Rafael J. Wysocki wrote:
> >
> > [...]
> >
> > > Also, can you check this patch on top of 2.6.27.4 and see what happens?
> >
> > With that patch, resume works (although I used 2.6.27.5 and not
> > 2.6.27.5, if that matters).
>
> It shouldn't really matter.
>
> Thanks for testing and please send me the output of dmidecode.
> It seems that blacklisting may be the only way to handle your box. :-(
Attached.
Regards,
Tino
On Thursday, 13 of November 2008, Tino Keitel wrote:
> On Wed, Nov 12, 2008 at 22:41:08 +0100, Rafael J. Wysocki wrote:
> > On Wednesday, 12 of November 2008, Tino Keitel wrote:
> > > On Wed, Nov 12, 2008 at 01:03:54 +0100, Rafael J. Wysocki wrote:
> > >
> > > [...]
> > >
> > > > Also, can you check this patch on top of 2.6.27.4 and see what happens?
> > >
> > > With that patch, resume works (although I used 2.6.27.5 and not
> > > 2.6.27.5, if that matters).
> >
> > It shouldn't really matter.
> >
> > Thanks for testing and please send me the output of dmidecode.
> > It seems that blacklisting may be the only way to handle your box. :-(
>
> Attached.
Please try the appended patch on top of the Linus' tree.
Thanks,
Rafael
---
drivers/acpi/sleep/main.c | 40 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/acpi/sleep/main.c
===================================================================
--- linux-2.6.orig/drivers/acpi/sleep/main.c
+++ linux-2.6/drivers/acpi/sleep/main.c
@@ -104,6 +104,18 @@ void __init acpi_s4_no_nvs(void)
s4_no_nvs = true;
}
+/*
+ * According to the ACPI specification the BIOS should make sure that ACPI is
+ * enabled and SCI_EN bit is set on wake-up from S1 - S3 sleep states. Still,
+ * some BIOSes don't do that and therefore we use acpi_enable() to enable ACPI
+ * on such systems during resume. Unfortunately that doesn't help in
+ * particularly pathological cases in which SCI_EN has to be set directly on
+ * resume, although the specification states very clearly that this flag is
+ * owned by the hardware. The set_sci_en_on_resume variable will be set in such
+ * cases.
+ */
+static bool set_sci_en_on_resume;
+
/**
* acpi_pm_disable_gpes - Disable the GPEs.
*/
@@ -249,7 +261,11 @@ static int acpi_suspend_enter(suspend_st
}
/* If ACPI is not enabled by the BIOS, we need to enable it here. */
- acpi_enable();
+ if (set_sci_en_on_resume)
+ acpi_set_register(ACPI_BITREG_SCI_ENABLE, 1);
+ else
+ acpi_enable();
+
/* Reprogram control registers and execute _BFS */
acpi_leave_sleep_state_prep(acpi_state);
@@ -337,6 +353,12 @@ static int __init init_old_suspend_order
return 0;
}
+static int __init init_set_sci_en_on_resume(const struct dmi_system_id *d)
+{
+ set_sci_en_on_resume = true;
+ return 0;
+}
+
static struct dmi_system_id __initdata acpisleep_dmi_table[] = {
{
.callback = init_old_suspend_ordering,
@@ -354,6 +376,22 @@ static struct dmi_system_id __initdata a
DMI_MATCH(DMI_PRODUCT_NAME, "HP xw4600 Workstation"),
},
},
+ {
+ .callback = init_set_sci_en_on_resume,
+ .ident = "Apple MacBook 1,1",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Computer, Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBook1,1"),
+ },
+ },
+ {
+ .callback = init_set_sci_en_on_resume,
+ .ident = "Apple MacMini 1,1",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Computer, Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Macmini1,1"),
+ },
+ },
{},
};
#endif /* CONFIG_SUSPEND */
On Thursday, 13 of November 2008, Rafael J. Wysocki wrote:
> On Thursday, 13 of November 2008, Tino Keitel wrote:
> > On Wed, Nov 12, 2008 at 22:41:08 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, 12 of November 2008, Tino Keitel wrote:
> > > > On Wed, Nov 12, 2008 at 01:03:54 +0100, Rafael J. Wysocki wrote:
> > > >
> > > > [...]
> > > >
> > > > > Also, can you check this patch on top of 2.6.27.4 and see what happens?
> > > >
> > > > With that patch, resume works (although I used 2.6.27.5 and not
> > > > 2.6.27.5, if that matters).
> > >
> > > It shouldn't really matter.
> > >
> > > Thanks for testing and please send me the output of dmidecode.
> > > It seems that blacklisting may be the only way to handle your box. :-(
> >
> > Attached.
>
> Please try the appended patch on top of the Linus' tree.
This patch also applies to current -stable, so you can test it on top of that.
I need your confirmation that the patch works to push it upstream.
Thanks,
Rafael
> ---
> drivers/acpi/sleep/main.c | 40 +++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 39 insertions(+), 1 deletion(-)
>
> Index: linux-2.6/drivers/acpi/sleep/main.c
> ===================================================================
> --- linux-2.6.orig/drivers/acpi/sleep/main.c
> +++ linux-2.6/drivers/acpi/sleep/main.c
> @@ -104,6 +104,18 @@ void __init acpi_s4_no_nvs(void)
> s4_no_nvs = true;
> }
>
> +/*
> + * According to the ACPI specification the BIOS should make sure that ACPI is
> + * enabled and SCI_EN bit is set on wake-up from S1 - S3 sleep states. Still,
> + * some BIOSes don't do that and therefore we use acpi_enable() to enable ACPI
> + * on such systems during resume. Unfortunately that doesn't help in
> + * particularly pathological cases in which SCI_EN has to be set directly on
> + * resume, although the specification states very clearly that this flag is
> + * owned by the hardware. The set_sci_en_on_resume variable will be set in such
> + * cases.
> + */
> +static bool set_sci_en_on_resume;
> +
> /**
> * acpi_pm_disable_gpes - Disable the GPEs.
> */
> @@ -249,7 +261,11 @@ static int acpi_suspend_enter(suspend_st
> }
>
> /* If ACPI is not enabled by the BIOS, we need to enable it here. */
> - acpi_enable();
> + if (set_sci_en_on_resume)
> + acpi_set_register(ACPI_BITREG_SCI_ENABLE, 1);
> + else
> + acpi_enable();
> +
> /* Reprogram control registers and execute _BFS */
> acpi_leave_sleep_state_prep(acpi_state);
>
> @@ -337,6 +353,12 @@ static int __init init_old_suspend_order
> return 0;
> }
>
> +static int __init init_set_sci_en_on_resume(const struct dmi_system_id *d)
> +{
> + set_sci_en_on_resume = true;
> + return 0;
> +}
> +
> static struct dmi_system_id __initdata acpisleep_dmi_table[] = {
> {
> .callback = init_old_suspend_ordering,
> @@ -354,6 +376,22 @@ static struct dmi_system_id __initdata a
> DMI_MATCH(DMI_PRODUCT_NAME, "HP xw4600 Workstation"),
> },
> },
> + {
> + .callback = init_set_sci_en_on_resume,
> + .ident = "Apple MacBook 1,1",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Computer, Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "MacBook1,1"),
> + },
> + },
> + {
> + .callback = init_set_sci_en_on_resume,
> + .ident = "Apple MacMini 1,1",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Apple Computer, Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Macmini1,1"),
> + },
> + },
> {},
> };
> #endif /* CONFIG_SUSPEND */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Everyone knows that debugging is twice as hard as writing a program
in the first place. So if you're as clever as you can be when you write it,
how will you ever debug it? --- Brian Kernighan
On Sun, Nov 16, 2008 at 12:04:16AM +0100, Rafael J. Wysocki wrote:
> On Thursday, 13 of November 2008, Rafael J. Wysocki wrote:
> > On Thursday, 13 of November 2008, Tino Keitel wrote:
>
> This patch also applies to current -stable, so you can test it on top of that.
>
> I need your confirmation that the patch works to push it upstream.
I can at least confirm the Macbook side of this works fine.
--
Bob Copeland %% http://www.bobcopeland.com
On Sun, Nov 16, 2008 at 00:04:16 +0100, Rafael J. Wysocki wrote:
> On Thursday, 13 of November 2008, Rafael J. Wysocki wrote:
[...]
> > Please try the appended patch on top of the Linus' tree.
>
> This patch also applies to current -stable, so you can test it on top of that.
>
> I need your confirmation that the patch works to push it upstream.
Hi,
I saw that 2.6.27.8 still missed that fix, maybe because I forgot to
send any confirmation. So, yes, this patch fixes the regression for me.
Regards,
Tino
On Monday, 8 of December 2008, Tino Keitel wrote:
> On Sun, Nov 16, 2008 at 00:04:16 +0100, Rafael J. Wysocki wrote:
> > On Thursday, 13 of November 2008, Rafael J. Wysocki wrote:
>
> [...]
>
> > > Please try the appended patch on top of the Linus' tree.
> >
> > This patch also applies to current -stable, so you can test it on top of that.
> >
> > I need your confirmation that the patch works to push it upstream.
>
> Hi,
>
> I saw that 2.6.27.8 still missed that fix, maybe because I forgot to
> send any confirmation. So, yes, this patch fixes the regression for me.
Thanks.
I sent the inclusion request to -stable, but apparently it was too late for
2.6.27.8.
Rafael