On 05 Aug, Zheng, Lv wrote:

Hi, Andrey

quoted

From: Andrey Skvortsov [mailto:andrej.skvortzov@gmail.com]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1

On 24 Jun, Zheng, Lv wrote:

quoted

Hi,

quoted

From: Andrey Skvortsov [mailto:andrej.skvortzov@gmail.com]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1

Hi Lv,

On 13 Jun, Zheng, Lv wrote:

quoted

quoted

From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
owner@vger.kernel.org] On Behalf Of Rafael J. Wysocki
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1

On Saturday, June 11, 2016 01:49:22 PM Andrey Skvortsov wrote:

quoted

On 10 Jun, Rafael J. Wysocki wrote:

quoted

On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote:

quoted

Hi,

On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken

suspend

quoted

quoted

to RAM.

quoted

quoted

quoted

quoted

quoted

Laptop doesn't finish suspend to RAM process (disks are off,

but

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

quoted

for acpi_hw_write()].

If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to

RAM

quoted

quoted

quoted

quoted

quoted

quoted

quoted

is working again.

The cause of this problem is that after this commit write to

PM1A

quoted

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

quoted

quoted

quoted

be 2 (16-bit), but it's 1 (8-bit).

[Lv Zheng]
Could you send me the acpidump of the machine?

Here it is

https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpid

quoted

quoted

ump.bin

[Lv Zheng]
I've been trying to download it these days but all failed.
Could you send an off-list email to me with this attached?

Strange. I've check now. The link above is working, but I see that
part of the link above is moved to the next line.
Anyway I resend you all files off-list.

quoted

quoted

quoted

quoted

quoted

quoted

quoted

The root of the problem seems to be not the commit

66b1ed5aa8dd25

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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?

quoted

quoted

quoted

[Lv Zheng]
My question would be:
Does Windows behave correctly for this table?

Yes, suspend to RAM is working under Windows Vista.
IIRC it worked under Windows XP too.

quoted

However there is a real case showing that there are real tables need

us to

quoted

quoted

correctly support BitWidth/BitOffset.

quoted

Here is the information for you to refer:

http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870

quoted

quoted

quoted

quoted

quoted

quoted

Well, if the commit in question caused a problem to happen for

you,

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

control register or even for all registers? This will fix the issue too.

That's a good idea actually.

quoted

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)

quoted

quoted

quoted

                        }
                }
        }

+       /*
+        * Reset access_width in the GAS for PM1A control register

to

quoted

quoted

quoted

quoted

quoted

+        * 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.

[Lv Zheng]
There is a commit in 4.7-rc2:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=

quoted

quoted

7f9bef9d

quoted

Have you tried if the problem still exists in 4.7-rc2?

I've just tried v4.7-rc3. It contains commit 7f9bef9d and the problem
exists there too.

[Lv Zheng]
IMO, for the time being, you can use quirks.
Booting your kernel with the following parameters:

acpi=rsdt
Or
acpi_force_32bit_fadt_addr
Or
Both

Rafael reverted commit, so I'm ok now.

Actually acpi_force_32bit_fadt_addr will not help here, because it's take
effect only if address64 != address32. But here these addresses are
the same, therefore access_width is taken from extended address.

[Lv Zheng] 
This sounds strange.
My recent investigation shows that Windows may favor 32bit fadt address.
So we need to get this quirk working.
I filed a bug here, hope you can help me to dig this a bit further:
https://bugzilla.kernel.org/show_bug.cgi?id=151501

Hi Lv,

That's putty. I uploaded requested acpidump -c off output to bugzilla.


-- 
Best regards,
Andrey Skvortsov