lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200907082141.18135.rjw@sisk.pl>
Date:	Wed, 8 Jul 2009 21:41:17 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Jenkins <alan-jenkins@...fmail.co.uk>,
	linux-acpi@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, Pavel Machek <pavel@....cz>,
	Len Brown <lenb@...nel.org>
Subject: Re: [BISECTED] HP G7000 battery disappears after suspend

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 <rjw@...k.pl>
> 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 <rjw@...k.pl>
>     Pavel Machek <pavel@...e.cz>
>     Signed-off-by: Len Brown <len.brown@...el.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ