Re: [BISECTED] HP G7000 battery disappears after suspend
From: Alan Jenkins
Date: Sat Jul 11 2009 - 05:43:15 EST
Bartlomiej Zolnierkiewicz wrote:
On Friday 10 July 2009 10:44:15 Alan Jenkins wrote:
2009/7/9 Rafael J. Wysocki <rjw@xxxxxxx>:
On Thursday 09 July 2009, Alan Jenkins wrote:
2009/7/8 Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>:
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/