Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1419963
| From | Andrey Skvortsov <andrej.skvortzov@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: acpi: broken suspend to RAM with v4.7-rc1 |
| Date | 2016-06-11 12:50 +0200 |
| Message-ID | <rIOEh-1Yk-7@gated-at.bofh.it> (permalink) |
| References | <rIBnH-1m9-5@gated-at.bofh.it> <rICa6-24v-23@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
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.
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;
--
Best regards,
Andrey Skvortsov
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
acpi: broken suspend to RAM with v4.7-rc1 Andrey Skvortsov <andrej.skvortzov@gmail.com> - 2016-06-10 22:40 +0200
Re: acpi: broken suspend to RAM with v4.7-rc1 "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-06-10 23:30 +0200
Re: acpi: broken suspend to RAM with v4.7-rc1 Andrey Skvortsov <andrej.skvortzov@gmail.com> - 2016-06-11 12:50 +0200
Re: acpi: broken suspend to RAM with v4.7-rc1 "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-06-11 14:00 +0200
RE: acpi: broken suspend to RAM with v4.7-rc1 "Zheng, Lv" <lv.zheng@intel.com> - 2016-06-13 11:00 +0200
Re: acpi: broken suspend to RAM with v4.7-rc1 Andrey Skvortsov <andrej.skvortzov@gmail.com> - 2016-06-13 12:10 +0200
Re: acpi: broken suspend to RAM with v4.7-rc1 "Rafael J. Wysocki" <rafael@kernel.org> - 2016-06-15 02:30 +0200
RE: acpi: broken suspend to RAM with v4.7-rc1 "Zheng, Lv" <lv.zheng@intel.com> - 2016-06-15 08:10 +0200
Re: acpi: broken suspend to RAM with v4.7-rc1 Andrey Skvortsov <andrej.skvortzov@gmail.com> - 2016-06-15 22:10 +0200
csiph-web