Hi,
I've borrowed this laptop for a few days. Linux works pretty well,
but I found a problem on newer kernels. After suspend it claims the
battery has been removed. E.g. /proc/acpi/battery/BAT0/state claims
the battery is not present (but it is).
I've attached acpidump and dmidecode output at
<http://bugzilla.kernel.org/show_bug.cgi?id=13745>. I still have
access to the laptop for further tests, but only until Friday.
I bisected it to the commit below. Manually reverting the patch fixes
the problem (in both 2.6.30 and 2.6.31-rc2).
commit d0c71fe7ebc180f1b7bc7da1d39a07fc19eec768
Author: Rafael J. Wysocki <[email protected]>
Date: Sat Oct 4 00:05:05 2008 +0200
ACPI Suspend: Enable ACPI during resume if SCI_EN is not set
On some machines, like for example MSI Wind U100, the BIOS doesn't
enable ACPI before returning control to the OS, which sometimes
causes resume to fail. This is against the ACPI specification,
which clearly states that "When the platform is waking from an S1, S2
or S3 state, OSPM assumes the hardware is already in the ACPI mode
and will not issue an ACPI_ENABLE", but it won't hurt to check the
SCI_EN bit and enable ACPI during resume from S3 if this bit is not
set.
Fortunately, we already have acpi_enable() for that, so use it in the
resume code path, before executing _BFS, in analogy with the
resume-from-hibernation code path.
NOTE: We aren't supposed to set SCI_EN directly, because it's owned
by the hardware.
Signed-off-by: Rafael J. Wysocki <[email protected]>
Pavel Machek <[email protected]>
Signed-off-by: Len Brown <[email protected]>
Many thanks
Alan
--
A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>>> Q: What is the most annoying thing in e-mail?
On Wednesday 08 July 2009, Alan Jenkins wrote:
> Hi,
>
> I've borrowed this laptop for a few days. Linux works pretty well,
> but I found a problem on newer kernels. After suspend it claims the
> battery has been removed. E.g. /proc/acpi/battery/BAT0/state claims
> the battery is not present (but it is).
>
> I've attached acpidump and dmidecode output at
> <http://bugzilla.kernel.org/show_bug.cgi?id=13745>. I still have
> access to the laptop for further tests, but only until Friday.
>
> I bisected it to the commit below. Manually reverting the patch fixes
> the problem (in both 2.6.30 and 2.6.31-rc2).
Well, the commit below can't be reverted, because that would cause the boxes
it fixed to stop working.
Now, the only case this patch can make any difference is when the BIOS doesn't
set SCI_EN before returning control the the kernel, which quite evidently is a
BIOS bug. The fact that the battery doesn't work with this patch applied means
that the BIOS not only doesn't set SCI_EN, but also expects it to remain unset,
which is insane.
IMO this is a "won't fix", sorry.
Best,
Rafael
> commit d0c71fe7ebc180f1b7bc7da1d39a07fc19eec768
> Author: Rafael J. Wysocki <[email protected]>
> Date: Sat Oct 4 00:05:05 2008 +0200
>
> ACPI Suspend: Enable ACPI during resume if SCI_EN is not set
>
> On some machines, like for example MSI Wind U100, the BIOS doesn't
> enable ACPI before returning control to the OS, which sometimes
> causes resume to fail. This is against the ACPI specification,
> which clearly states that "When the platform is waking from an S1, S2
> or S3 state, OSPM assumes the hardware is already in the ACPI mode
> and will not issue an ACPI_ENABLE", but it won't hurt to check the
> SCI_EN bit and enable ACPI during resume from S3 if this bit is not
> set.
>
> Fortunately, we already have acpi_enable() for that, so use it in the
> resume code path, before executing _BFS, in analogy with the
> resume-from-hibernation code path.
>
> NOTE: We aren't supposed to set SCI_EN directly, because it's owned
> by the hardware.
>
> Signed-off-by: Rafael J. Wysocki <[email protected]>
> Pavel Machek <[email protected]>
> Signed-off-by: Len Brown <[email protected]>
On Wednesday 08 July 2009 21:41:17 Rafael J. Wysocki wrote:
> On Wednesday 08 July 2009, Alan Jenkins wrote:
> > Hi,
> >
> > I've borrowed this laptop for a few days. Linux works pretty well,
> > but I found a problem on newer kernels. After suspend it claims the
> > battery has been removed. E.g. /proc/acpi/battery/BAT0/state claims
> > the battery is not present (but it is).
> >
> > I've attached acpidump and dmidecode output at
> > <http://bugzilla.kernel.org/show_bug.cgi?id=13745>. I still have
> > access to the laptop for further tests, but only until Friday.
> >
> > I bisected it to the commit below. Manually reverting the patch fixes
> > the problem (in both 2.6.30 and 2.6.31-rc2).
>
> Well, the commit below can't be reverted, because that would cause the boxes
> it fixed to stop working.
>
> Now, the only case this patch can make any difference is when the BIOS doesn't
> set SCI_EN before returning control the the kernel, which quite evidently is a
> BIOS bug. The fact that the battery doesn't work with this patch applied means
> that the BIOS not only doesn't set SCI_EN, but also expects it to remain unset,
> which is insane.
>
> IMO this is a "won't fix", sorry.
Lets be pragmatic here..
Besides this is a regression and we are already handling some such insane
systems in STR case. Moreover sending SMI ACPI_ENABLE command may result in
some things happening behind our back and not only setting of SCI_EN bit..
PS Looking at the set_sci_en_on_resume quirk history it seems that if we are
lucky we may may fix another issue (screaming IRQ one) at the same time :)
Alan, could you try this patch?
---
debug patch (needs to have both CONFIG_SUSPEND=y & CONFIG_HIBERNATION=y)
drivers/acpi/sleep.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
Index: b/drivers/acpi/sleep.c
===================================================================
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -383,6 +383,14 @@ static struct dmi_system_id __initdata a
},
},
{
+ .callback = init_set_sci_en_on_resume,
+ .ident = "Hewlett-Packard HP G7000 Notebook PC",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP G7000 Notebook PC"),
+ },
+ },
+ {
.callback = init_old_suspend_ordering,
.ident = "Panasonic CF51-2L",
.matches = {
@@ -472,7 +480,10 @@ static void acpi_hibernation_leave(void)
* If ACPI is not enabled by the BIOS and the boot kernel, we need to
* enable it here.
*/
- acpi_enable();
+ if (set_sci_en_on_resume)
+ acpi_write_bit_register(ACPI_BITREG_SCI_ENABLE, 1);
+ else
+ acpi_enable();
/* Reprogram control registers and execute _BFS */
acpi_leave_sleep_state_prep(ACPI_STATE_S4);
/* Check the hardware signature */
> Now, the only case this patch can make any difference is when the BIOS doesn't
> set SCI_EN before returning control the the kernel, which quite evidently is a
> BIOS bug. The fact that the battery doesn't work with this patch applied means
> that the BIOS not only doesn't set SCI_EN, but also expects it to remain unset,
> which is insane.
>
> IMO this is a "won't fix", sorry.
It's an "oh god we need another DMI entry" case and a regression so it
wants fixing for the next -rc.
Alan
2009/7/8 Bartlomiej Zolnierkiewicz <[email protected]>:
> On Wednesday 08 July 2009 21:41:17 Rafael J. Wysocki wrote:
>> On Wednesday 08 July 2009, Alan Jenkins wrote:
>> > Hi,
>> >
>> > I've borrowed this laptop for a few days. ?Linux works pretty well,
>> > but I found a problem on newer kernels. ?After suspend it claims the
>> > battery has been removed. ?E.g. /proc/acpi/battery/BAT0/state claims
>> > the battery is not present (but it is).
>> >
>> > I've attached acpidump and dmidecode output at
>> > <http://bugzilla.kernel.org/show_bug.cgi?id=13745>. ?I still have
>> > access to the laptop for further tests, but only until Friday.
>> >
>> > I bisected it to the commit below. ?Manually reverting the patch fixes
>> > the problem (in both 2.6.30 and 2.6.31-rc2).
>>
>> Well, the commit below can't be reverted, because that would cause the boxes
>> it fixed to stop working.
>>
>> Now, the only case this patch can make any difference is when the BIOS doesn't
>> set SCI_EN before returning control the the kernel, which quite evidently is a
>> BIOS bug. ?The fact that the battery doesn't work with this patch applied means
>> that the BIOS not only doesn't set SCI_EN, but also expects it to remain unset,
>> which is insane.
>>
>> IMO this is a "won't fix", sorry.
>
> Lets be pragmatic here..
>
> Besides this is a regression and we are already handling some such insane
> systems in STR case. ?Moreover sending SMI ACPI_ENABLE command may result in
> some things happening behind our back and not only setting of SCI_EN bit..
>
> PS Looking at the set_sci_en_on_resume quirk history it seems that if we are
> lucky we may may fix another issue (screaming IRQ one) at the same time :)
>
> Alan, could you try this patch?
>
> ---
> debug patch (needs to have both CONFIG_SUSPEND=y & CONFIG_HIBERNATION=y)
>
> ?drivers/acpi/sleep.c | ? 13 ++++++++++++-
> ?1 file changed, 12 insertions(+), 1 deletion(-)
>
> Index: b/drivers/acpi/sleep.c
> ===================================================================
> --- a/drivers/acpi/sleep.c
> +++ b/drivers/acpi/sleep.c
> @@ -383,6 +383,14 @@ static struct dmi_system_id __initdata a
> ? ? ? ? ? ? ? ?},
> ? ? ? ?},
> ? ? ? ?{
> + ? ? ? .callback = init_set_sci_en_on_resume,
> + ? ? ? .ident = "Hewlett-Packard HP G7000 Notebook PC",
> + ? ? ? .matches = {
> + ? ? ? ? ? ? ? DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> + ? ? ? ? ? ? ? DMI_MATCH(DMI_PRODUCT_NAME, "HP G7000 Notebook PC"),
> + ? ? ? ? ? ? ? },
> + ? ? ? },
> + ? ? ? {
> ? ? ? ?.callback = init_old_suspend_ordering,
> ? ? ? ?.ident = "Panasonic CF51-2L",
> ? ? ? ?.matches = {
Thanks for coding this up for me in full. It works, the battery now
survives, and it does indeed remove the IRQ warning.
I didn't test the hibernation hunk. I have hibernation set up, but
there is a different problem (not a regression). I don't have much
more time to investigate on this laptop, so I don't expect to get it
fixed. But here are some details anyway :-).
When I run s2disk, it writes the image out, and then instantly
resumes. It doesn't seem to read the image, but neither does the
kernel report an error:
[ 491.088802] ACPI: Preparing to enter system sleep state S4
[ 491.090498] PM: Saving platform NVS memory
[ 491.094638] Disabling non-boot CPUs ...
[ 491.094867] PM: Creating hibernation image:
[ 491.096015] PM: Need to copy 114990 pages
[ 491.096015] PM: Normal pages needed: 114990 + 1024 + 22, available
pages: 144595
[ 491.096015] PM: Hibernation image created (114990 pages copied)
[ 491.096015] ACPI: Waking up from system sleep state S4
It happens on 2.6.24-23-generic, 2.6.30, and 2.6.30-rc2.
> @@ -472,7 +480,10 @@ static void acpi_hibernation_leave(void)
> ? ? ? ? * If ACPI is not enabled by the BIOS and the boot kernel, we need to
> ? ? ? ? * enable it here.
> ? ? ? ? */
> - ? ? ? acpi_enable();
> + ? ? ? if (set_sci_en_on_resume)
> + ? ? ? ? ? ? ? acpi_write_bit_register(ACPI_BITREG_SCI_ENABLE, 1);
> + ? ? ? else
> + ? ? ? ? ? ? ? acpi_enable();
> ? ? ? ?/* Reprogram control registers and execute _BFS */
> ? ? ? ?acpi_leave_sleep_state_prep(ACPI_STATE_S4);
> ? ? ? ?/* Check the hardware signature */
>
Thanks
Alan
--
A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>>> Q: What is the most annoying thing in e-mail?
On Thursday 09 July 2009, Alan Jenkins wrote:
> 2009/7/8 Bartlomiej Zolnierkiewicz <[email protected]>:
> > On Wednesday 08 July 2009 21:41:17 Rafael J. Wysocki wrote:
> >> On Wednesday 08 July 2009, Alan Jenkins wrote:
> >> > Hi,
> >> >
> >> > I've borrowed this laptop for a few days. Linux works pretty well,
> >> > but I found a problem on newer kernels. After suspend it claims the
> >> > battery has been removed. E.g. /proc/acpi/battery/BAT0/state claims
> >> > the battery is not present (but it is).
> >> >
> >> > I've attached acpidump and dmidecode output at
> >> > <http://bugzilla.kernel.org/show_bug.cgi?id=13745>. I still have
> >> > access to the laptop for further tests, but only until Friday.
> >> >
> >> > I bisected it to the commit below. Manually reverting the patch fixes
> >> > the problem (in both 2.6.30 and 2.6.31-rc2).
> >>
> >> Well, the commit below can't be reverted, because that would cause the boxes
> >> it fixed to stop working.
> >>
> >> Now, the only case this patch can make any difference is when the BIOS doesn't
> >> set SCI_EN before returning control the the kernel, which quite evidently is a
> >> BIOS bug. The fact that the battery doesn't work with this patch applied means
> >> that the BIOS not only doesn't set SCI_EN, but also expects it to remain unset,
> >> which is insane.
> >>
> >> IMO this is a "won't fix", sorry.
> >
> > Lets be pragmatic here..
> >
> > Besides this is a regression and we are already handling some such insane
> > systems in STR case. Moreover sending SMI ACPI_ENABLE command may result in
> > some things happening behind our back and not only setting of SCI_EN bit..
> >
> > PS Looking at the set_sci_en_on_resume quirk history it seems that if we are
> > lucky we may may fix another issue (screaming IRQ one) at the same time :)
> >
> > Alan, could you try this patch?
> >
> > ---
> > debug patch (needs to have both CONFIG_SUSPEND=y & CONFIG_HIBERNATION=y)
> >
> > drivers/acpi/sleep.c | 13 ++++++++++++-
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > Index: b/drivers/acpi/sleep.c
> > ===================================================================
> > --- a/drivers/acpi/sleep.c
> > +++ b/drivers/acpi/sleep.c
> > @@ -383,6 +383,14 @@ static struct dmi_system_id __initdata a
> > },
> > },
> > {
> > + .callback = init_set_sci_en_on_resume,
> > + .ident = "Hewlett-Packard HP G7000 Notebook PC",
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "HP G7000 Notebook PC"),
> > + },
> > + },
> > + {
> > .callback = init_old_suspend_ordering,
> > .ident = "Panasonic CF51-2L",
> > .matches = {
>
> Thanks for coding this up for me in full. It works, the battery now
> survives, and it does indeed remove the IRQ warning.
Great, thanks for testing, Bart, thanks for the patch!
Len, can you add the Bart's patch to your 2.6.31 queue, please?
> I didn't test the hibernation hunk. I have hibernation set up, but
> there is a different problem (not a regression). I don't have much
> more time to investigate on this laptop, so I don't expect to get it
> fixed. But here are some details anyway :-).
>
> When I run s2disk, it writes the image out, and then instantly
> resumes. It doesn't seem to read the image, but neither does the
> kernel report an error:
>
> [ 491.088802] ACPI: Preparing to enter system sleep state S4
> [ 491.090498] PM: Saving platform NVS memory
> [ 491.094638] Disabling non-boot CPUs ...
> [ 491.094867] PM: Creating hibernation image:
> [ 491.096015] PM: Need to copy 114990 pages
> [ 491.096015] PM: Normal pages needed: 114990 + 1024 + 22, available
> pages: 144595
> [ 491.096015] PM: Hibernation image created (114990 pages copied)
> [ 491.096015] ACPI: Waking up from system sleep state S4
>
> It happens on 2.6.24-23-generic, 2.6.30, and 2.6.30-rc2.
Hmm. Interesting.
I _guess_ this problem is ACPI-related as well. You can try putting
'shutdown method = shutdown' into /etc/suspend.conf (or whatever the s2disk's
configuration file is on your system).
If possible, it would be interesting to see if that also happens if
'echo disk > /sys/power/state' is used to trigger hibernation instead of
s2disk. In particular when booted with init=/bin/bash.
Best,
Rafael
2009/7/9 Rafael J. Wysocki <[email protected]>:
> On Thursday 09 July 2009, Alan Jenkins wrote:
>> 2009/7/8 Bartlomiej Zolnierkiewicz <[email protected]>:
>> > On Wednesday 08 July 2009 21:41:17 Rafael J. Wysocki wrote:
>> >> On Wednesday 08 July 2009, Alan Jenkins wrote:
>> >> > Hi,
>> >> >
>> >> > I've borrowed this laptop for a few days. ?Linux works pretty well,
>> >> > but I found a problem on newer kernels. ?After suspend it claims the
>> >> > battery has been removed. ?E.g. /proc/acpi/battery/BAT0/state claims
>> >> > the battery is not present (but it is).
>> >> >
>> >> > I've attached acpidump and dmidecode output at
>> >> > <http://bugzilla.kernel.org/show_bug.cgi?id=13745>. ?I still have
>> >> > access to the laptop for further tests, but only until Friday.
>> >> >
>> >> > I bisected it to the commit below. ?Manually reverting the patch fixes
>> >> > the problem (in both 2.6.30 and 2.6.31-rc2).
>> >>
>> >> Well, the commit below can't be reverted, because that would cause the boxes
>> >> it fixed to stop working.
>> >>
>> >> Now, the only case this patch can make any difference is when the BIOS doesn't
>> >> set SCI_EN before returning control the the kernel, which quite evidently is a
>> >> BIOS bug. ?The fact that the battery doesn't work with this patch applied means
>> >> that the BIOS not only doesn't set SCI_EN, but also expects it to remain unset,
>> >> which is insane.
>> >>
>> >> IMO this is a "won't fix", sorry.
>> >
>> > Lets be pragmatic here..
>> >
>> > Besides this is a regression and we are already handling some such insane
>> > systems in STR case. ?Moreover sending SMI ACPI_ENABLE command may result in
>> > some things happening behind our back and not only setting of SCI_EN bit..
>> >
>> > PS Looking at the set_sci_en_on_resume quirk history it seems that if we are
>> > lucky we may may fix another issue (screaming IRQ one) at the same time :)
>> >
>> > Alan, could you try this patch?
>> >
>> > ---
>> > debug patch (needs to have both CONFIG_SUSPEND=y & CONFIG_HIBERNATION=y)
>> >
>> > ?drivers/acpi/sleep.c | ? 13 ++++++++++++-
>> > ?1 file changed, 12 insertions(+), 1 deletion(-)
>> >
>> > Index: b/drivers/acpi/sleep.c
>> > ===================================================================
>> > --- a/drivers/acpi/sleep.c
>> > +++ b/drivers/acpi/sleep.c
>> > @@ -383,6 +383,14 @@ static struct dmi_system_id __initdata a
>> > ? ? ? ? ? ? ? ?},
>> > ? ? ? ?},
>> > ? ? ? ?{
>> > + ? ? ? .callback = init_set_sci_en_on_resume,
>> > + ? ? ? .ident = "Hewlett-Packard HP G7000 Notebook PC",
>> > + ? ? ? .matches = {
>> > + ? ? ? ? ? ? ? DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
>> > + ? ? ? ? ? ? ? DMI_MATCH(DMI_PRODUCT_NAME, "HP G7000 Notebook PC"),
>> > + ? ? ? ? ? ? ? },
>> > + ? ? ? },
>> > + ? ? ? {
>> > ? ? ? ?.callback = init_old_suspend_ordering,
>> > ? ? ? ?.ident = "Panasonic CF51-2L",
>> > ? ? ? ?.matches = {
>>
>> Thanks for coding this up for me in full. ?It works, the battery now
>> survives, and it does indeed remove the IRQ warning.
>
> Great, thanks for testing, Bart, thanks for the patch!
>
> Len, can you add the Bart's patch to your 2.6.31 queue, please?
>
>> I didn't test the hibernation hunk. ?I have hibernation set up, but
>> there is a different problem (not a regression). ?I don't have much
>> more time to investigate on this laptop, so I don't expect to get it
>> fixed. ?But here are some details anyway :-).
>>
>> When I run s2disk, it writes the image out, and then instantly
>> resumes. ?It doesn't seem to read the image, but neither does the
>> kernel report an error:
>>
>> [ ?491.088802] ACPI: Preparing to enter system sleep state S4
>> [ ?491.090498] PM: Saving platform NVS memory
>> [ ?491.094638] Disabling non-boot CPUs ...
>> [ ?491.094867] PM: Creating hibernation image:
>> [ ?491.096015] PM: Need to copy 114990 pages
>> [ ?491.096015] PM: Normal pages needed: 114990 + 1024 + 22, available
>> pages: 144595
>> [ ?491.096015] PM: Hibernation image created (114990 pages copied)
>> [ ?491.096015] ACPI: Waking up from system sleep state S4
>>
>> It happens on 2.6.24-23-generic, 2.6.30, and 2.6.30-rc2.
>
> Hmm. ?Interesting.
>
> I _guess_ this problem is ACPI-related as well. ?You can try putting
> 'shutdown method = shutdown' into /etc/suspend.conf (or whatever the s2disk's
> configuration file is on your system).
That doesn't change anything.
> If possible, it would be interesting to see if that also happens if
> 'echo disk > /sys/power/state' is used to trigger hibernation instead of
> s2disk. In particular when booted with init=/bin/bash.
That worked, even though I didn't use init=/bin/bash.
If it matters, I'm using a swap file on an NTFS partition. [The
system was installed by Ubuntu "Wubi" (i.e. using Windows partition
and bootloader), but I had to set up both uswsusp and kernel swsusp
myself. pm-hibernate refuses to work; I don't think it knows about
swap files].
I noticed an error message, I'm not sure if it's relevant or not.
Suspending using this method, I see two lines of ATA errors on the
console when suspending. They appear to be post-snapshot - they don't
appear in the log - but it looks like the same error happens on resume
too. s2disk generates the same error on resume as well.
[ 192.247475] sd 0:0:0:0: [sda] Starting disk
[ 192.340428] ata4.00: ACPI cmd ef/03:0c:00:00:00:a0 filtered out
[ 192.340432] ata4.00: ACPI cmd ef/03:22:00:00:00:a0 filtered out
[ 192.372314] ata4.00: configured for MWDMA2
[ 192.640075] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 192.642338] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
[ 192.644365] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
[ 192.644381] ata1.00: configured for UDMA/100
* [ 192.660076] ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x9 t4
* [ 192.660079] ata1: irq_stat 0x00400040, connection status changed
[ 192.663198] ata1.00: configured for UDMA/100
[ 192.663201] ata1: EH complete
The lines marked with * are the ones that appear on the console during
suspend. This happens on both 2.6.31-rc2 and 2.6.30.
Thanks
Alan
On Thursday 09 July 2009 22:11:30 Rafael J. Wysocki wrote:
> On Thursday 09 July 2009, Alan Jenkins wrote:
> > 2009/7/8 Bartlomiej Zolnierkiewicz <[email protected]>:
> > > On Wednesday 08 July 2009 21:41:17 Rafael J. Wysocki wrote:
> > >> On Wednesday 08 July 2009, Alan Jenkins wrote:
> > >> > Hi,
> > >> >
> > >> > I've borrowed this laptop for a few days. Linux works pretty well,
> > >> > but I found a problem on newer kernels. After suspend it claims the
> > >> > battery has been removed. E.g. /proc/acpi/battery/BAT0/state claims
> > >> > the battery is not present (but it is).
> > >> >
> > >> > I've attached acpidump and dmidecode output at
> > >> > <http://bugzilla.kernel.org/show_bug.cgi?id=13745>. I still have
> > >> > access to the laptop for further tests, but only until Friday.
> > >> >
> > >> > I bisected it to the commit below. Manually reverting the patch fixes
> > >> > the problem (in both 2.6.30 and 2.6.31-rc2).
> > >>
> > >> Well, the commit below can't be reverted, because that would cause the boxes
> > >> it fixed to stop working.
> > >>
> > >> Now, the only case this patch can make any difference is when the BIOS doesn't
> > >> set SCI_EN before returning control the the kernel, which quite evidently is a
> > >> BIOS bug. The fact that the battery doesn't work with this patch applied means
> > >> that the BIOS not only doesn't set SCI_EN, but also expects it to remain unset,
> > >> which is insane.
> > >>
> > >> IMO this is a "won't fix", sorry.
> > >
> > > Lets be pragmatic here..
> > >
> > > Besides this is a regression and we are already handling some such insane
> > > systems in STR case. Moreover sending SMI ACPI_ENABLE command may result in
> > > some things happening behind our back and not only setting of SCI_EN bit..
> > >
> > > PS Looking at the set_sci_en_on_resume quirk history it seems that if we are
> > > lucky we may may fix another issue (screaming IRQ one) at the same time :)
> > >
> > > Alan, could you try this patch?
> > >
> > > ---
> > > debug patch (needs to have both CONFIG_SUSPEND=y & CONFIG_HIBERNATION=y)
> > >
> > > drivers/acpi/sleep.c | 13 ++++++++++++-
> > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > >
> > > Index: b/drivers/acpi/sleep.c
> > > ===================================================================
> > > --- a/drivers/acpi/sleep.c
> > > +++ b/drivers/acpi/sleep.c
> > > @@ -383,6 +383,14 @@ static struct dmi_system_id __initdata a
> > > },
> > > },
> > > {
> > > + .callback = init_set_sci_en_on_resume,
> > > + .ident = "Hewlett-Packard HP G7000 Notebook PC",
> > > + .matches = {
> > > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> > > + DMI_MATCH(DMI_PRODUCT_NAME, "HP G7000 Notebook PC"),
> > > + },
> > > + },
> > > + {
> > > .callback = init_old_suspend_ordering,
> > > .ident = "Panasonic CF51-2L",
> > > .matches = {
> >
> > Thanks for coding this up for me in full. It works, the battery now
> > survives, and it does indeed remove the IRQ warning.
>
> Great, thanks for testing, Bart, thanks for the patch!
>
> Len, can you add the Bart's patch to your 2.6.31 queue, please?
Here is the final patch version:
From: Bartlomiej Zolnierkiewicz <[email protected]>
Subject: [PATCH] acpi: HP G7000 Notebook needs a SCI_EN resume quirk
This fixes regression (battery "vanishing" on resume) introduced by
commit d0c71fe7ebc180f1b7bc7da1d39a07fc19eec768 ("ACPI Suspend: Enable
ACPI during resume if SCI_EN is not set") and also the issue with
the "screaming" IRQ 9.
Fixes:
http://bugzilla.kernel.org/show_bug.cgi?id=13745
Reported-and-tested-by: Alan Jenkins <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Cc: [email protected]
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/acpi/sleep.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
Index: b/drivers/acpi/sleep.c
===================================================================
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -383,6 +383,14 @@ static struct dmi_system_id __initdata a
},
},
{
+ .callback = init_set_sci_en_on_resume,
+ .ident = "Hewlett-Packard HP G7000 Notebook PC",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP G7000 Notebook PC"),
+ },
+ },
+ {
.callback = init_old_suspend_ordering,
.ident = "Panasonic CF51-2L",
.matches = {
On Friday 10 July 2009 10:44:15 Alan Jenkins wrote:
> 2009/7/9 Rafael J. Wysocki <[email protected]>:
> > On Thursday 09 July 2009, Alan Jenkins wrote:
> >> 2009/7/8 Bartlomiej Zolnierkiewicz <[email protected]>:
> >> > On Wednesday 08 July 2009 21:41:17 Rafael J. Wysocki wrote:
> >> >> On Wednesday 08 July 2009, Alan Jenkins wrote:
> >> >> > Hi,
> >> >> >
> >> >> > I've borrowed this laptop for a few days. Linux works pretty well,
> >> >> > but I found a problem on newer kernels. After suspend it claims the
> >> >> > battery has been removed. E.g. /proc/acpi/battery/BAT0/state claims
> >> >> > the battery is not present (but it is).
> >> >> >
> >> >> > I've attached acpidump and dmidecode output at
> >> >> > <http://bugzilla.kernel.org/show_bug.cgi?id=13745>. I still have
> >> >> > access to the laptop for further tests, but only until Friday.
> >> >> >
> >> >> > I bisected it to the commit below. Manually reverting the patch fixes
> >> >> > the problem (in both 2.6.30 and 2.6.31-rc2).
> >> >>
> >> >> Well, the commit below can't be reverted, because that would cause the boxes
> >> >> it fixed to stop working.
> >> >>
> >> >> Now, the only case this patch can make any difference is when the BIOS doesn't
> >> >> set SCI_EN before returning control the the kernel, which quite evidently is a
> >> >> BIOS bug. The fact that the battery doesn't work with this patch applied means
> >> >> that the BIOS not only doesn't set SCI_EN, but also expects it to remain unset,
> >> >> which is insane.
> >> >>
> >> >> IMO this is a "won't fix", sorry.
> >> >
> >> > Lets be pragmatic here..
> >> >
> >> > Besides this is a regression and we are already handling some such insane
> >> > systems in STR case. Moreover sending SMI ACPI_ENABLE command may result in
> >> > some things happening behind our back and not only setting of SCI_EN bit..
> >> >
> >> > PS Looking at the set_sci_en_on_resume quirk history it seems that if we are
> >> > lucky we may may fix another issue (screaming IRQ one) at the same time :)
> >> >
> >> > Alan, could you try this patch?
> >> >
> >> > ---
> >> > debug patch (needs to have both CONFIG_SUSPEND=y & CONFIG_HIBERNATION=y)
> >> >
> >> > drivers/acpi/sleep.c | 13 ++++++++++++-
> >> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >> >
> >> > Index: b/drivers/acpi/sleep.c
> >> > ===================================================================
> >> > --- a/drivers/acpi/sleep.c
> >> > +++ b/drivers/acpi/sleep.c
> >> > @@ -383,6 +383,14 @@ static struct dmi_system_id __initdata a
> >> > },
> >> > },
> >> > {
> >> > + .callback = init_set_sci_en_on_resume,
> >> > + .ident = "Hewlett-Packard HP G7000 Notebook PC",
> >> > + .matches = {
> >> > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> >> > + DMI_MATCH(DMI_PRODUCT_NAME, "HP G7000 Notebook PC"),
> >> > + },
> >> > + },
> >> > + {
> >> > .callback = init_old_suspend_ordering,
> >> > .ident = "Panasonic CF51-2L",
> >> > .matches = {
> >>
> >> Thanks for coding this up for me in full. It works, the battery now
> >> survives, and it does indeed remove the IRQ warning.
> >
> > Great, thanks for testing, Bart, thanks for the patch!
> >
> > Len, can you add the Bart's patch to your 2.6.31 queue, please?
> >
> >> I didn't test the hibernation hunk. I have hibernation set up, but
> >> there is a different problem (not a regression). I don't have much
> >> more time to investigate on this laptop, so I don't expect to get it
> >> fixed. But here are some details anyway :-).
> >>
> >> When I run s2disk, it writes the image out, and then instantly
> >> resumes. It doesn't seem to read the image, but neither does the
> >> kernel report an error:
> >>
> >> [ 491.088802] ACPI: Preparing to enter system sleep state S4
> >> [ 491.090498] PM: Saving platform NVS memory
> >> [ 491.094638] Disabling non-boot CPUs ...
> >> [ 491.094867] PM: Creating hibernation image:
> >> [ 491.096015] PM: Need to copy 114990 pages
> >> [ 491.096015] PM: Normal pages needed: 114990 + 1024 + 22, available
> >> pages: 144595
> >> [ 491.096015] PM: Hibernation image created (114990 pages copied)
> >> [ 491.096015] ACPI: Waking up from system sleep state S4
> >>
> >> It happens on 2.6.24-23-generic, 2.6.30, and 2.6.30-rc2.
> >
> > Hmm. Interesting.
> >
> > I _guess_ this problem is ACPI-related as well. You can try putting
> > 'shutdown method = shutdown' into /etc/suspend.conf (or whatever the s2disk's
> > configuration file is on your system).
>
> That doesn't change anything.
>
> > If possible, it would be interesting to see if that also happens if
> > 'echo disk > /sys/power/state' is used to trigger hibernation instead of
> > s2disk. In particular when booted with init=/bin/bash.
>
> That worked, even though I didn't use init=/bin/bash.
>
> If it matters, I'm using a swap file on an NTFS partition. [The
> system was installed by Ubuntu "Wubi" (i.e. using Windows partition
> and bootloader), but I had to set up both uswsusp and kernel swsusp
> myself. pm-hibernate refuses to work; I don't think it knows about
> swap files].
>
> I noticed an error message, I'm not sure if it's relevant or not.
>
> Suspending using this method, I see two lines of ATA errors on the
> console when suspending. They appear to be post-snapshot - they don't
> appear in the log - but it looks like the same error happens on resume
> too. s2disk generates the same error on resume as well.
>
> [ 192.247475] sd 0:0:0:0: [sda] Starting disk
> [ 192.340428] ata4.00: ACPI cmd ef/03:0c:00:00:00:a0 filtered out
> [ 192.340432] ata4.00: ACPI cmd ef/03:22:00:00:00:a0 filtered out
> [ 192.372314] ata4.00: configured for MWDMA2
> [ 192.640075] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 192.642338] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
> [ 192.644365] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
> [ 192.644381] ata1.00: configured for UDMA/100
> * [ 192.660076] ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x9 t4
> * [ 192.660079] ata1: irq_stat 0x00400040, connection status changed
> [ 192.663198] ata1.00: configured for UDMA/100
> [ 192.663201] ata1: EH complete
>
> The lines marked with * are the ones that appear on the console during
> suspend. This happens on both 2.6.31-rc2 and 2.6.30.
BTW Did you have a chance to test the second part of the original patch?
[ Rafal, what do we want to do with it? It seems logical to have the same
behavior w.r.t. SCI_EN bit both when leaving S3 and S4 but I haven't yet
verified this with the spec (is the ACPI is enabled on leaving the state
assumption also valid for S4 or only for S0-S3?) and the change itself
would require some more time in linux-next if we decide to go this way.. ]
Bartlomiej Zolnierkiewicz wrote:
> On Friday 10 July 2009 10:44:15 Alan Jenkins wrote:
>
>> 2009/7/9 Rafael J. Wysocki <[email protected]>:
>>
>>> On Thursday 09 July 2009, Alan Jenkins wrote:
>>>
>>>> 2009/7/8 Bartlomiej Zolnierkiewicz <[email protected]>:
>>>>
>>>>> On Wednesday 08 July 2009 21:41:17 Rafael J. Wysocki wrote:
>>>>>
>>>>>> On Wednesday 08 July 2009, Alan Jenkins wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've borrowed this laptop for a few days. Linux works pretty well,
>>>>>>> but I found a problem on newer kernels. After suspend it claims the
>>>>>>> battery has been removed. E.g. /proc/acpi/battery/BAT0/state claims
>>>>>>> the battery is not present (but it is).
>>>>>>>
>>>>>>> I've attached acpidump and dmidecode output at
>>>>>>> <http://bugzilla.kernel.org/show_bug.cgi?id=13745>. I still have
>>>>>>> access to the laptop for further tests, but only until Friday.
>>>>>>>
>>>>>>> I bisected it to the commit below. Manually reverting the patch fixes
>>>>>>> the problem (in both 2.6.30 and 2.6.31-rc2).
>>>>>>>
>>>>>> Well, the commit below can't be reverted, because that would cause the boxes
>>>>>> it fixed to stop working.
>>>>>>
>>>>>> Now, the only case this patch can make any difference is when the BIOS doesn't
>>>>>> set SCI_EN before returning control the the kernel, which quite evidently is a
>>>>>> BIOS bug. The fact that the battery doesn't work with this patch applied means
>>>>>> that the BIOS not only doesn't set SCI_EN, but also expects it to remain unset,
>>>>>> which is insane.
>>>>>>
>>>>>> IMO this is a "won't fix", sorry.
>>>>>>
>>>>> Lets be pragmatic here..
>>>>>
>>>>> Besides this is a regression and we are already handling some such insane
>>>>> systems in STR case. Moreover sending SMI ACPI_ENABLE command may result in
>>>>> some things happening behind our back and not only setting of SCI_EN bit..
>>>>>
>>>>> PS Looking at the set_sci_en_on_resume quirk history it seems that if we are
>>>>> lucky we may may fix another issue (screaming IRQ one) at the same time :)
>>>>>
>>>>> Alan, could you try this patch?
>>>>>
>>>>> ---
>>>>> debug patch (needs to have both CONFIG_SUSPEND=y & CONFIG_HIBERNATION=y)
>>>>>
>>>>> drivers/acpi/sleep.c | 13 ++++++++++++-
>>>>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>>>>
>>>>> Index: b/drivers/acpi/sleep.c
>>>>> ===================================================================
>>>>> --- a/drivers/acpi/sleep.c
>>>>> +++ b/drivers/acpi/sleep.c
>>>>> @@ -383,6 +383,14 @@ static struct dmi_system_id __initdata a
>>>>> },
>>>>> },
>>>>> {
>>>>> + .callback = init_set_sci_en_on_resume,
>>>>> + .ident = "Hewlett-Packard HP G7000 Notebook PC",
>>>>> + .matches = {
>>>>> + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
>>>>> + DMI_MATCH(DMI_PRODUCT_NAME, "HP G7000 Notebook PC"),
>>>>> + },
>>>>> + },
>>>>> + {
>>>>> .callback = init_old_suspend_ordering,
>>>>> .ident = "Panasonic CF51-2L",
>>>>> .matches = {
>>>>>
>>>> Thanks for coding this up for me in full. It works, the battery now
>>>> survives, and it does indeed remove the IRQ warning.
>>>>
>>> Great, thanks for testing, Bart, thanks for the patch!
>>>
>>> Len, can you add the Bart's patch to your 2.6.31 queue, please?
>>>
>>>
>>>> I didn't test the hibernation hunk. I have hibernation set up, but
>>>> there is a different problem (not a regression). I don't have much
>>>> more time to investigate on this laptop, so I don't expect to get it
>>>> fixed. But here are some details anyway :-).
>>>>
>>>> When I run s2disk, it writes the image out, and then instantly
>>>> resumes. It doesn't seem to read the image, but neither does the
>>>> kernel report an error:
>>>>
>>>> [ 491.088802] ACPI: Preparing to enter system sleep state S4
>>>> [ 491.090498] PM: Saving platform NVS memory
>>>> [ 491.094638] Disabling non-boot CPUs ...
>>>> [ 491.094867] PM: Creating hibernation image:
>>>> [ 491.096015] PM: Need to copy 114990 pages
>>>> [ 491.096015] PM: Normal pages needed: 114990 + 1024 + 22, available
>>>> pages: 144595
>>>> [ 491.096015] PM: Hibernation image created (114990 pages copied)
>>>> [ 491.096015] ACPI: Waking up from system sleep state S4
>>>>
>>>> It happens on 2.6.24-23-generic, 2.6.30, and 2.6.30-rc2.
>>>>
>>> Hmm. Interesting.
>>>
>>> I _guess_ this problem is ACPI-related as well. You can try putting
>>> 'shutdown method = shutdown' into /etc/suspend.conf (or whatever the s2disk's
>>> configuration file is on your system).
>>>
>> That doesn't change anything.
>>
>>
>>> If possible, it would be interesting to see if that also happens if
>>> 'echo disk > /sys/power/state' is used to trigger hibernation instead of
>>> s2disk. In particular when booted with init=/bin/bash.
>>>
>> That worked, even though I didn't use init=/bin/bash.
>>
>> If it matters, I'm using a swap file on an NTFS partition. [The
>> system was installed by Ubuntu "Wubi" (i.e. using Windows partition
>> and bootloader), but I had to set up both uswsusp and kernel swsusp
>> myself. pm-hibernate refuses to work; I don't think it knows about
>> swap files].
>>
>> I noticed an error message, I'm not sure if it's relevant or not.
>>
>> Suspending using this method, I see two lines of ATA errors on the
>> console when suspending. They appear to be post-snapshot - they don't
>> appear in the log - but it looks like the same error happens on resume
>> too. s2disk generates the same error on resume as well.
>>
>> [ 192.247475] sd 0:0:0:0: [sda] Starting disk
>> [ 192.340428] ata4.00: ACPI cmd ef/03:0c:00:00:00:a0 filtered out
>> [ 192.340432] ata4.00: ACPI cmd ef/03:22:00:00:00:a0 filtered out
>> [ 192.372314] ata4.00: configured for MWDMA2
>> [ 192.640075] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [ 192.642338] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
>> [ 192.644365] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
>> [ 192.644381] ata1.00: configured for UDMA/100
>> * [ 192.660076] ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x9 t4
>> * [ 192.660079] ata1: irq_stat 0x00400040, connection status changed
>> [ 192.663198] ata1.00: configured for UDMA/100
>> [ 192.663201] ata1: EH complete
>>
>> The lines marked with * are the ones that appear on the console during
>> suspend. This happens on both 2.6.31-rc2 and 2.6.30.
>>
>
> BTW Did you have a chance to test the second part of the original patch?
>
> [ Rafal, what do we want to do with it? It seems logical to have the same
> behavior w.r.t. SCI_EN bit both when leaving S3 and S4 but I haven't yet
> verified this with the spec (is the ACPI is enabled on leaving the state
> assumption also valid for S4 or only for S0-S3?) and the change itself
> would require some more time in linux-next if we decide to go this way.. ]
>
I got hibernation working without the second part (and the battery was
fine). I'll try that hunk today and see if it breaks. Right now the
machine's in Windows, recovering from me letting it run out of battery :-).
Alan
On Friday 10 July 2009, Bartlomiej Zolnierkiewicz wrote:
> On Friday 10 July 2009 10:44:15 Alan Jenkins wrote:
> > 2009/7/9 Rafael J. Wysocki <[email protected]>:
> > > On Thursday 09 July 2009, Alan Jenkins wrote:
> > >> 2009/7/8 Bartlomiej Zolnierkiewicz <[email protected]>:
> > >> > On Wednesday 08 July 2009 21:41:17 Rafael J. Wysocki wrote:
> > >> >> On Wednesday 08 July 2009, Alan Jenkins wrote:
> > >> >> > Hi,
> > >> >> >
> > >> >> > I've borrowed this laptop for a few days. Linux works pretty well,
> > >> >> > but I found a problem on newer kernels. After suspend it claims the
> > >> >> > battery has been removed. E.g. /proc/acpi/battery/BAT0/state claims
> > >> >> > the battery is not present (but it is).
> > >> >> >
> > >> >> > I've attached acpidump and dmidecode output at
> > >> >> > <http://bugzilla.kernel.org/show_bug.cgi?id=13745>. I still have
> > >> >> > access to the laptop for further tests, but only until Friday.
> > >> >> >
> > >> >> > I bisected it to the commit below. Manually reverting the patch fixes
> > >> >> > the problem (in both 2.6.30 and 2.6.31-rc2).
> > >> >>
> > >> >> Well, the commit below can't be reverted, because that would cause the boxes
> > >> >> it fixed to stop working.
> > >> >>
> > >> >> Now, the only case this patch can make any difference is when the BIOS doesn't
> > >> >> set SCI_EN before returning control the the kernel, which quite evidently is a
> > >> >> BIOS bug. The fact that the battery doesn't work with this patch applied means
> > >> >> that the BIOS not only doesn't set SCI_EN, but also expects it to remain unset,
> > >> >> which is insane.
> > >> >>
> > >> >> IMO this is a "won't fix", sorry.
> > >> >
> > >> > Lets be pragmatic here..
> > >> >
> > >> > Besides this is a regression and we are already handling some such insane
> > >> > systems in STR case. Moreover sending SMI ACPI_ENABLE command may result in
> > >> > some things happening behind our back and not only setting of SCI_EN bit..
> > >> >
> > >> > PS Looking at the set_sci_en_on_resume quirk history it seems that if we are
> > >> > lucky we may may fix another issue (screaming IRQ one) at the same time :)
> > >> >
> > >> > Alan, could you try this patch?
> > >> >
> > >> > ---
> > >> > debug patch (needs to have both CONFIG_SUSPEND=y & CONFIG_HIBERNATION=y)
> > >> >
> > >> > drivers/acpi/sleep.c | 13 ++++++++++++-
> > >> > 1 file changed, 12 insertions(+), 1 deletion(-)
> > >> >
> > >> > Index: b/drivers/acpi/sleep.c
> > >> > ===================================================================
> > >> > --- a/drivers/acpi/sleep.c
> > >> > +++ b/drivers/acpi/sleep.c
> > >> > @@ -383,6 +383,14 @@ static struct dmi_system_id __initdata a
> > >> > },
> > >> > },
> > >> > {
> > >> > + .callback = init_set_sci_en_on_resume,
> > >> > + .ident = "Hewlett-Packard HP G7000 Notebook PC",
> > >> > + .matches = {
> > >> > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> > >> > + DMI_MATCH(DMI_PRODUCT_NAME, "HP G7000 Notebook PC"),
> > >> > + },
> > >> > + },
> > >> > + {
> > >> > .callback = init_old_suspend_ordering,
> > >> > .ident = "Panasonic CF51-2L",
> > >> > .matches = {
> > >>
> > >> Thanks for coding this up for me in full. It works, the battery now
> > >> survives, and it does indeed remove the IRQ warning.
> > >
> > > Great, thanks for testing, Bart, thanks for the patch!
> > >
> > > Len, can you add the Bart's patch to your 2.6.31 queue, please?
> > >
> > >> I didn't test the hibernation hunk. I have hibernation set up, but
> > >> there is a different problem (not a regression). I don't have much
> > >> more time to investigate on this laptop, so I don't expect to get it
> > >> fixed. But here are some details anyway :-).
> > >>
> > >> When I run s2disk, it writes the image out, and then instantly
> > >> resumes. It doesn't seem to read the image, but neither does the
> > >> kernel report an error:
> > >>
> > >> [ 491.088802] ACPI: Preparing to enter system sleep state S4
> > >> [ 491.090498] PM: Saving platform NVS memory
> > >> [ 491.094638] Disabling non-boot CPUs ...
> > >> [ 491.094867] PM: Creating hibernation image:
> > >> [ 491.096015] PM: Need to copy 114990 pages
> > >> [ 491.096015] PM: Normal pages needed: 114990 + 1024 + 22, available
> > >> pages: 144595
> > >> [ 491.096015] PM: Hibernation image created (114990 pages copied)
> > >> [ 491.096015] ACPI: Waking up from system sleep state S4
> > >>
> > >> It happens on 2.6.24-23-generic, 2.6.30, and 2.6.30-rc2.
> > >
> > > Hmm. Interesting.
> > >
> > > I _guess_ this problem is ACPI-related as well. You can try putting
> > > 'shutdown method = shutdown' into /etc/suspend.conf (or whatever the s2disk's
> > > configuration file is on your system).
> >
> > That doesn't change anything.
> >
> > > If possible, it would be interesting to see if that also happens if
> > > 'echo disk > /sys/power/state' is used to trigger hibernation instead of
> > > s2disk. In particular when booted with init=/bin/bash.
> >
> > That worked, even though I didn't use init=/bin/bash.
> >
> > If it matters, I'm using a swap file on an NTFS partition. [The
> > system was installed by Ubuntu "Wubi" (i.e. using Windows partition
> > and bootloader), but I had to set up both uswsusp and kernel swsusp
> > myself. pm-hibernate refuses to work; I don't think it knows about
> > swap files].
> >
> > I noticed an error message, I'm not sure if it's relevant or not.
> >
> > Suspending using this method, I see two lines of ATA errors on the
> > console when suspending. They appear to be post-snapshot - they don't
> > appear in the log - but it looks like the same error happens on resume
> > too. s2disk generates the same error on resume as well.
> >
> > [ 192.247475] sd 0:0:0:0: [sda] Starting disk
> > [ 192.340428] ata4.00: ACPI cmd ef/03:0c:00:00:00:a0 filtered out
> > [ 192.340432] ata4.00: ACPI cmd ef/03:22:00:00:00:a0 filtered out
> > [ 192.372314] ata4.00: configured for MWDMA2
> > [ 192.640075] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > [ 192.642338] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
> > [ 192.644365] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
> > [ 192.644381] ata1.00: configured for UDMA/100
> > * [ 192.660076] ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x9 t4
> > * [ 192.660079] ata1: irq_stat 0x00400040, connection status changed
> > [ 192.663198] ata1.00: configured for UDMA/100
> > [ 192.663201] ata1: EH complete
> >
> > The lines marked with * are the ones that appear on the console during
> > suspend. This happens on both 2.6.31-rc2 and 2.6.30.
>
> BTW Did you have a chance to test the second part of the original patch?
>
> [ Rafal, what do we want to do with it? It seems logical to have the same
> behavior w.r.t. SCI_EN bit both when leaving S3 and S4 but I haven't yet
> verified this with the spec (is the ACPI is enabled on leaving the state
> assumption also valid for S4 or only for S0-S3?) and the change itself
> would require some more time in linux-next if we decide to go this way.. ]
The situation during resume from hibernation is different, because that code
is usually run when the boot kernel has already initialized ACPI.
Also, IIRC the specification implies that ACPI won't be enabled by the BIOS
during resume from S4 at it is the responsibility of the kernel to enable ACPI
in that case. In fact we don't follow the specification in that respect,
because ACPI should only be enabled by the image kernel and the boot kernel
shouldn't touch it.
OTOH, I'm not sure what the behavior of the affected systems would be if the
boot kernel didn't enable ACPI. I'm not sure if that's worth investigating at
the moment, though.
Best,
Rafael
On 7/11/09, Alan Jenkins <[email protected]> wrote:
> Bartlomiej Zolnierkiewicz wrote:
>> On Friday 10 July 2009 10:44:15 Alan Jenkins wrote:
>>
>>> 2009/7/9 Rafael J. Wysocki <[email protected]>:
>>>
>>>> On Thursday 09 July 2009, Alan Jenkins wrote:
>>>>
>>>>> 2009/7/8 Bartlomiej Zolnierkiewicz <[email protected]>:
>>>>>
>>>>>> On Wednesday 08 July 2009 21:41:17 Rafael J. Wysocki wrote:
>>>>>>
>>>>>>> On Wednesday 08 July 2009, Alan Jenkins wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I've borrowed this laptop for a few days. Linux works pretty well,
>>>>>>>> but I found a problem on newer kernels. After suspend it claims the
>>>>>>>> battery has been removed. E.g. /proc/acpi/battery/BAT0/state claims
>>>>>>>> the battery is not present (but it is).
>>>>>>>>
>>>>>>>> I've attached acpidump and dmidecode output at
>>>>>>>> <http://bugzilla.kernel.org/show_bug.cgi?id=13745>. I still have
>>>>>>>> access to the laptop for further tests, but only until Friday.
>>>>>>>>
>>>>>>>> I bisected it to the commit below. Manually reverting the patch
>>>>>>>> fixes
>>>>>>>> the problem (in both 2.6.30 and 2.6.31-rc2).
>>>>>>>>
>>>>>>> Well, the commit below can't be reverted, because that would cause
>>>>>>> the boxes
>>>>>>> it fixed to stop working.
>>>>>>>
>>>>>>> Now, the only case this patch can make any difference is when the
>>>>>>> BIOS doesn't
>>>>>>> set SCI_EN before returning control the the kernel, which quite
>>>>>>> evidently is a
>>>>>>> BIOS bug. The fact that the battery doesn't work with this patch
>>>>>>> applied means
>>>>>>> that the BIOS not only doesn't set SCI_EN, but also expects it to
>>>>>>> remain unset,
>>>>>>> which is insane.
>>>>>>>
>>>>>>> IMO this is a "won't fix", sorry.
>>>>>>>
>>>>>> Lets be pragmatic here..
>>>>>>
>>>>>> Besides this is a regression and we are already handling some such
>>>>>> insane
>>>>>> systems in STR case. Moreover sending SMI ACPI_ENABLE command may
>>>>>> result in
>>>>>> some things happening behind our back and not only setting of SCI_EN
>>>>>> bit..
>>>>>>
>>>>>> PS Looking at the set_sci_en_on_resume quirk history it seems that if
>>>>>> we are
>>>>>> lucky we may may fix another issue (screaming IRQ one) at the same
>>>>>> time :)
>>>>>>
>>>>>> Alan, could you try this patch?
>>>>>>
>>>>>> ---
>>>>>> debug patch (needs to have both CONFIG_SUSPEND=y &
>>>>>> CONFIG_HIBERNATION=y)
>>>>>>
>>>>>> drivers/acpi/sleep.c | 13 ++++++++++++-
>>>>>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> Index: b/drivers/acpi/sleep.c
>>>>>> ===================================================================
>>>>>> --- a/drivers/acpi/sleep.c
>>>>>> +++ b/drivers/acpi/sleep.c
>>>>>> @@ -383,6 +383,14 @@ static struct dmi_system_id __initdata a
>>>>>> },
>>>>>> },
>>>>>> {
>>>>>> + .callback = init_set_sci_en_on_resume,
>>>>>> + .ident = "Hewlett-Packard HP G7000 Notebook PC",
>>>>>> + .matches = {
>>>>>> + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
>>>>>> + DMI_MATCH(DMI_PRODUCT_NAME, "HP G7000 Notebook PC"),
>>>>>> + },
>>>>>> + },
>>>>>> + {
>>>>>> .callback = init_old_suspend_ordering,
>>>>>> .ident = "Panasonic CF51-2L",
>>>>>> .matches = {
>>>>>>
>>>>> Thanks for coding this up for me in full. It works, the battery now
>>>>> survives, and it does indeed remove the IRQ warning.
>>>>>
>>>> Great, thanks for testing, Bart, thanks for the patch!
>>>>
>>>> Len, can you add the Bart's patch to your 2.6.31 queue, please?
>>>>
>>>>
>>>>> I didn't test the hibernation hunk. I have hibernation set up, but
>>>>> there is a different problem (not a regression). I don't have much
>>>>> more time to investigate on this laptop, so I don't expect to get it
>>>>> fixed. But here are some details anyway :-).
>>>>>
>>>>> When I run s2disk, it writes the image out, and then instantly
>>>>> resumes. It doesn't seem to read the image, but neither does the
>>>>> kernel report an error:
>>>>>
>>>>> [ 491.088802] ACPI: Preparing to enter system sleep state S4
>>>>> [ 491.090498] PM: Saving platform NVS memory
>>>>> [ 491.094638] Disabling non-boot CPUs ...
>>>>> [ 491.094867] PM: Creating hibernation image:
>>>>> [ 491.096015] PM: Need to copy 114990 pages
>>>>> [ 491.096015] PM: Normal pages needed: 114990 + 1024 + 22, available
>>>>> pages: 144595
>>>>> [ 491.096015] PM: Hibernation image created (114990 pages copied)
>>>>> [ 491.096015] ACPI: Waking up from system sleep state S4
>>>>>
>>>>> It happens on 2.6.24-23-generic, 2.6.30, and 2.6.30-rc2.
>>>>>
>>>> Hmm. Interesting.
>>>>
>>>> I _guess_ this problem is ACPI-related as well. You can try putting
>>>> 'shutdown method = shutdown' into /etc/suspend.conf (or whatever the
>>>> s2disk's
>>>> configuration file is on your system).
>>>>
>>> That doesn't change anything.
>>>
>>>
>>>> If possible, it would be interesting to see if that also happens if
>>>> 'echo disk > /sys/power/state' is used to trigger hibernation instead of
>>>> s2disk. In particular when booted with init=/bin/bash.
>>>>
>>> That worked, even though I didn't use init=/bin/bash.
>>>
>>> If it matters, I'm using a swap file on an NTFS partition. [The
>>> system was installed by Ubuntu "Wubi" (i.e. using Windows partition
>>> and bootloader), but I had to set up both uswsusp and kernel swsusp
>>> myself. pm-hibernate refuses to work; I don't think it knows about
>>> swap files].
>>>
>>> I noticed an error message, I'm not sure if it's relevant or not.
>>>
>>> Suspending using this method, I see two lines of ATA errors on the
>>> console when suspending. They appear to be post-snapshot - they don't
>>> appear in the log - but it looks like the same error happens on resume
>>> too. s2disk generates the same error on resume as well.
>>>
>>> [ 192.247475] sd 0:0:0:0: [sda] Starting disk
>>> [ 192.340428] ata4.00: ACPI cmd ef/03:0c:00:00:00:a0 filtered out
>>> [ 192.340432] ata4.00: ACPI cmd ef/03:22:00:00:00:a0 filtered out
>>> [ 192.372314] ata4.00: configured for MWDMA2
>>> [ 192.640075] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [ 192.642338] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
>>> [ 192.644365] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
>>> [ 192.644381] ata1.00: configured for UDMA/100
>>> * [ 192.660076] ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x9
>>> t4
>>> * [ 192.660079] ata1: irq_stat 0x00400040, connection status changed
>>> [ 192.663198] ata1.00: configured for UDMA/100
>>> [ 192.663201] ata1: EH complete
>>>
>>> The lines marked with * are the ones that appear on the console during
>>> suspend. This happens on both 2.6.31-rc2 and 2.6.30.
>>>
>>
>> BTW Did you have a chance to test the second part of the original patch?
>>
>> [ Rafal, what do we want to do with it? It seems logical to have the same
>> behavior w.r.t. SCI_EN bit both when leaving S3 and S4 but I haven't yet
>> verified this with the spec (is the ACPI is enabled on leaving the state
>> assumption also valid for S4 or only for S0-S3?) and the change itself
>> would require some more time in linux-next if we decide to go this way..
>> ]
>>
>
> I got hibernation working without the second part (and the battery was
> fine). I'll try that hunk today and see if it breaks.
It still works with the second half of the patch applied.
Alan
Hi Len,
On Friday 10 July 2009, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 09 July 2009 22:11:30 Rafael J. Wysocki wrote:
> > On Thursday 09 July 2009, Alan Jenkins wrote:
> > > 2009/7/8 Bartlomiej Zolnierkiewicz <[email protected]>:
> > > > On Wednesday 08 July 2009 21:41:17 Rafael J. Wysocki wrote:
> > > >> On Wednesday 08 July 2009, Alan Jenkins wrote:
> > > >> > Hi,
> > > >> >
> > > >> > I've borrowed this laptop for a few days. Linux works pretty well,
> > > >> > but I found a problem on newer kernels. After suspend it claims the
> > > >> > battery has been removed. E.g. /proc/acpi/battery/BAT0/state claims
> > > >> > the battery is not present (but it is).
> > > >> >
> > > >> > I've attached acpidump and dmidecode output at
> > > >> > <http://bugzilla.kernel.org/show_bug.cgi?id=13745>. I still have
> > > >> > access to the laptop for further tests, but only until Friday.
> > > >> >
> > > >> > I bisected it to the commit below. Manually reverting the patch fixes
> > > >> > the problem (in both 2.6.30 and 2.6.31-rc2).
> > > >>
> > > >> Well, the commit below can't be reverted, because that would cause the boxes
> > > >> it fixed to stop working.
> > > >>
> > > >> Now, the only case this patch can make any difference is when the BIOS doesn't
> > > >> set SCI_EN before returning control the the kernel, which quite evidently is a
> > > >> BIOS bug. The fact that the battery doesn't work with this patch applied means
> > > >> that the BIOS not only doesn't set SCI_EN, but also expects it to remain unset,
> > > >> which is insane.
> > > >>
> > > >> IMO this is a "won't fix", sorry.
> > > >
> > > > Lets be pragmatic here..
> > > >
> > > > Besides this is a regression and we are already handling some such insane
> > > > systems in STR case. Moreover sending SMI ACPI_ENABLE command may result in
> > > > some things happening behind our back and not only setting of SCI_EN bit..
> > > >
> > > > PS Looking at the set_sci_en_on_resume quirk history it seems that if we are
> > > > lucky we may may fix another issue (screaming IRQ one) at the same time :)
> > > >
> > > > Alan, could you try this patch?
> > > >
> > > > ---
> > > > debug patch (needs to have both CONFIG_SUSPEND=y & CONFIG_HIBERNATION=y)
> > > >
> > > > drivers/acpi/sleep.c | 13 ++++++++++++-
> > > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > > >
> > > > Index: b/drivers/acpi/sleep.c
> > > > ===================================================================
> > > > --- a/drivers/acpi/sleep.c
> > > > +++ b/drivers/acpi/sleep.c
> > > > @@ -383,6 +383,14 @@ static struct dmi_system_id __initdata a
> > > > },
> > > > },
> > > > {
> > > > + .callback = init_set_sci_en_on_resume,
> > > > + .ident = "Hewlett-Packard HP G7000 Notebook PC",
> > > > + .matches = {
> > > > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> > > > + DMI_MATCH(DMI_PRODUCT_NAME, "HP G7000 Notebook PC"),
> > > > + },
> > > > + },
> > > > + {
> > > > .callback = init_old_suspend_ordering,
> > > > .ident = "Panasonic CF51-2L",
> > > > .matches = {
> > >
> > > Thanks for coding this up for me in full. It works, the battery now
> > > survives, and it does indeed remove the IRQ warning.
> >
> > Great, thanks for testing, Bart, thanks for the patch!
> >
> > Len, can you add the Bart's patch to your 2.6.31 queue, please?
>
> Here is the final patch version:
>
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Subject: [PATCH] acpi: HP G7000 Notebook needs a SCI_EN resume quirk
>
> This fixes regression (battery "vanishing" on resume) introduced by
> commit d0c71fe7ebc180f1b7bc7da1d39a07fc19eec768 ("ACPI Suspend: Enable
> ACPI during resume if SCI_EN is not set") and also the issue with
> the "screaming" IRQ 9.
>
> Fixes:
> http://bugzilla.kernel.org/show_bug.cgi?id=13745
>
> Reported-and-tested-by: Alan Jenkins <[email protected]>
> Acked-by: Rafael J. Wysocki <[email protected]>
> Cc: [email protected]
> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
I'm adding this patch to my linux-next branch and will push it to Linus for
2.6.32. Is that fine with you?
Rafael
> ---
> drivers/acpi/sleep.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> Index: b/drivers/acpi/sleep.c
> ===================================================================
> --- a/drivers/acpi/sleep.c
> +++ b/drivers/acpi/sleep.c
> @@ -383,6 +383,14 @@ static struct dmi_system_id __initdata a
> },
> },
> {
> + .callback = init_set_sci_en_on_resume,
> + .ident = "Hewlett-Packard HP G7000 Notebook PC",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP G7000 Notebook PC"),
> + },
> + },
> + {
> .callback = init_old_suspend_ordering,
> .ident = "Panasonic CF51-2L",
> .matches = {
>