From: Andrey Skvortsov <andrej.skvortzov@gmail.com>
To: Lv Zheng <lv.zheng@intel.com>, Bob Moore <robert.moore@intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
linux-acpi@vger.kernel.org, devel@acpica.org,
linux-kernel@vger.kernel.org
Subject: acpi: broken suspend to RAM with v4.7-rc1
Date: Fri, 10 Jun 2016 23:32:10 +0300 [thread overview]
Message-ID: <20160610203210.GA2262@nest> (raw)
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
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_hw_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 Block
(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-bit), but it's
1 (8-bit).
The root of the problem seems to be not the commit 66b1ed5aa8dd25 itself, but 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?
--
Best regards,
Andrey Skvortsov
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next reply other threads:[~2016-06-10 20:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-10 20:32 Andrey Skvortsov [this message]
2016-06-10 21:24 ` acpi: broken suspend to RAM with v4.7-rc1 Rafael J. Wysocki
2016-06-11 10:49 ` Andrey Skvortsov
2016-06-11 11:56 ` Rafael J. Wysocki
[not found] ` <744357E9AAD1214791ACBA4B0B9092633AA54819@SHSMSX101.ccr.corp.intel.com>
2016-06-13 8:50 ` Zheng, Lv
2016-06-13 10:07 ` Andrey Skvortsov
2016-06-15 0:24 ` Rafael J. Wysocki
2016-06-15 6:05 ` Zheng, Lv
2016-06-15 20:02 ` Andrey Skvortsov
2016-06-24 1:02 ` Zheng, Lv
2016-06-24 21:32 ` Andrey Skvortsov
2016-06-27 1:17 ` Zheng, Lv
2016-06-27 8:49 ` Andrey Skvortsov
2016-06-28 5:10 ` Zheng, Lv
2016-08-05 1:06 ` Zheng, Lv
2016-08-10 17:51 ` Andrey Skvortsov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160610203210.GA2262@nest \
--to=andrej.skvortzov@gmail.com \
--cc=devel@acpica.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=robert.moore@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).