linux-kernel - Re: acpi: broken suspend to RAM with v4.7-rc1

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] [day] [month] [year] [list]

Message-ID: <2544058.dYPSaC0ylY@vostro.rjw.lan>
Date:	Sat, 11 Jun 2016 13:56:17 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Andrey Skvortsov <andrej.skvortzov@...il.com>
Cc:	Lv Zheng <lv.zheng@...el.com>, Bob Moore <robert.moore@...el.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	linux-acpi@...r.kernel.org, devel@...ica.org,
	linux-kernel@...r.kernel.org, Bob Moore <robert.moore@...el.com>
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1

On Saturday, June 11, 2016 01:49:22 PM Andrey Skvortsov wrote:
> On 10 Jun, Rafael J. Wysocki wrote:
> > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote:
> > > Hi,
> > > 
> > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend to RAM.
> > > Laptop doesn't finish suspend to RAM process (disks are off, but WiFi
> > > and Power LEDs are still on). The only way to get it out of this
> > > state, is to turn the power off.
> > > 
> > > I've bisected the issue to commit 66b1ed5aa8dd25
> > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_h=
> > > w_write()].
> > > 
> > > If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to RAM is
> > > working again.
> > > 
> > > The cause of this problem is that after this commit write to PM1A Control B=
> > > lock
> > > (16-bit register) is done using two 8-bit writes. If I force this write
> > > to be 16-bit, then all is working as before.
> > > 
> > > To get it working 'access_width' for PM1A Control Block needs to be 2 (16-b=
> > > it), but it's=20
> > > 1 (8-bit).
> > > 
> > > The root of the problem seems to be not the commit 66b1ed5aa8dd25 itself, b=
> > > ut the ACPI
> > > tables in BIOS where wrong access_width comes from. I fixed problem in FACP=
> > >  table,
> > > put it in initrd to override FACP table from BIOS. This fixed the issue,
> > > suspend to RAM is working now again.
> > > 
> > > But I'm not sure whether is this proper fix for this problem.
> > > Is there any place in the kernel, where such ACPI quirks are placed?
> > 
> > Well, if the commit in question caused a problem to happen for you, it also
> > might cause similar problems to happen elsewhere.
> > 
> > It looks like we'll need to revert that commit.
> Hi,
> 
> or maybe to reset access_width AnyAcc from FACP table only for PM1A control
> register or even for all registers? This will fix the issue too.

That's a good idea actually.

> diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
> index 6208069..a476e94 100644
> --- a/drivers/acpi/acpica/tbfadt.c
> +++ b/drivers/acpi/acpica/tbfadt.c
> @@ -714,7 +714,14 @@ static void acpi_tb_setup_fadt_registers(void)
>                         }
>                 }
>         }
> 
> +       /*
> +        * Reset access_width in the GAS for PM1A control register to
> +        * undefined value. Because in some cases this field contains
> +        * wrong value.
> +        */
> +       acpi_gbl_FADT.xpm1a_control_block.access_width = 0;

OK, let's see what Bob and Lv think about that.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)