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

DISCUSSION Andrey Skvortsov 4 participants 16 messages Jun 10, 2016 – Aug 10, 2016 1 message not in the archive

Subsystems (2)

ACPI ACPI component architecture (acpica)

lore

Share & tools

lore

Andrey Skvortsov

author

2016-06-10 20:32 UTC #0 lore raw

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?

Signature · 2 lines

Best regards,
Andrey Skvortsov

Rafael J. Wysocki

2016-06-10 21:20 UTC #1 lore raw

Quoted 36 lines · Andrey Skvortsov

--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.

Quoted 2 lines

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.

Thanks,
Rafael

Andrey Skvortsov

author

2016-06-11 10:49 UTC #2 lore raw

Quoted 31 lines · Rafael J. Wysocki

Quoted 30 lines · Andrey Skvortsov
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.

Quoted 7 lines

Quoted 2 lines
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.

drivers/acpi/acpica/tbfadt.c +6 -1

index 6208069..a476e94 100644
@@ -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

Rafael J. Wysocki

2016-06-11 11:52 UTC #3 lore raw

Quoted 35 lines · Andrey Skvortsov

Quoted 34 lines · Rafael J. Wysocki
Quoted 32 lines · Andrey Skvortsov
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?

Quoted 8 lines

Quoted 4 lines
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.

Quoted 5 lines

drivers/acpi/acpica/tbfadt.c +0 -0
index 6208069..a476e94 100644

drivers/acpi/acpica/tbfadt.c static void acpi_tb_setup_fadt_registers(void) · line 723

Quoted 10 lines

drivers/acpi/acpica/tbfadt.c +6 -0

@@ -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.

A message that is not in the archive (sent off-list or not yet received): 744357E9AAD1214791ACBA4B0B9092633AA54819@SHSMSX101.ccr.corp.intel.com

Zheng, Lv

2016-06-13 08:50 UTC #5 lore raw

Hi, Andrey

Quoted 4 lines

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

Quoted 23 lines

Quoted 22 lines · Andrey Skvortsov
Quoted 21 lines · Rafael J. Wysocki
Quoted 20 lines · Andrey Skvortsov
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).

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

Quoted 10 lines

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
The root of the problem seems to be not the commit
66b1ed5aa8dd25
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
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?

[Lv Zheng]
My question would be:
Does Windows behave correctly for this table?
However there is a real case showing that there are real tables need us to correctly support BitWidth/BitOffset. Here is the information for you to refer:
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870

Quoted 21 lines

Quoted 9 lines
Quoted 5 lines
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.
Quoted 9 lines
(quoted diff) +0 -0
b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
drivers/acpi/acpica/tbfadt.c +0 -0
@@ -714,7 +714,14 @@ static void acpi_tb_setup_fadt_registers(void)
                        }
                }
        }
 

Quoted 8 lines

drivers/acpi/acpica/tbfadt.c static void acpi_tb_setup_fadt_registers(void) · line 723
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c +6 -0
+       /*
+        * 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.

[Lv Zheng]
There is a commit in 4.7-rc2:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7f9bef9d
Have you tried if the problem still exists in 4.7-rc2?

Thanks and best regards
-Lv

Andrey Skvortsov

author

2016-06-13 10:07 UTC #6 lore raw

Hi Lv,

Quoted 21 lines · Lv

Quoted 21 lines
From: [email protected] [mailto:linux-acpi- [email protected]] On Behalf Of Rafael J. Wysocki
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 16 lines · Andrey Skvortsov
Quoted 15 lines · Rafael J. Wysocki
Quoted 14 lines · Andrey Skvortsov
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.

Quoted 8 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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).
[Lv Zheng]
Could you send me the acpidump of the machine?

Here it is
https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpidump.bin

Quoted 8 lines

Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
The root of the problem seems to be not the commit
66b1ed5aa8dd25
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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.

Quoted 5 lines

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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?
[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 33 lines

However there is a real case showing that there are real tables need us to correctly support BitWidth/BitOffset. Here is the information for you to refer:
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
Quoted 21 lines
Quoted 9 lines
Quoted 5 lines
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.
Quoted 9 lines
(quoted diff) +0 -0
b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
drivers/acpi/acpica/tbfadt.c +0 -0
@@ -714,7 +714,14 @@ static void acpi_tb_setup_fadt_registers(void)
                        }
                }
        }
 
Quoted 8 lines
drivers/acpi/acpica/tbfadt.c static void acpi_tb_setup_fadt_registers(void) · line 723
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c +6 -0
+       /*
+        * 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.

Quoted 4 lines

[Lv Zheng]
There is a commit in 4.7-rc2:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7f9bef9d
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.

Signature · 2 lines

Best regards,
Andrey Skvortsov

Rafael J. Wysocki

maintainer

2016-06-15 00:24 UTC #7 lore raw

Quoted 84 lines · Andrey Skvortsov

Hi Lv,
Quoted 21 lines · Lv
Quoted 21 lines
From: [email protected] [mailto:linux-acpi- [email protected]] On Behalf Of Rafael J. Wysocki
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 16 lines · Andrey Skvortsov
Quoted 15 lines · Rafael J. Wysocki
Quoted 14 lines · Andrey Skvortsov
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.
Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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).
[Lv Zheng]
Could you send me the acpidump of the machine?
Here it is
https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpidump.bin
Quoted 8 lines
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
The root of the problem seems to be not the commit
66b1ed5aa8dd25
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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.
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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?
[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 33 lines
However there is a real case showing that there are real tables need us to correctly support BitWidth/BitOffset. Here is the information for you to refer:
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
Quoted 29 lines
Quoted 9 lines
Quoted 5 lines
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.
Quoted 5 lines
(quoted diff) +0 -0
b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
drivers/acpi/acpica/tbfadt.c static void acpi_tb_setup_fadt_registers(void) · line 723
Quoted 10 lines
drivers/acpi/acpica/tbfadt.c +6 -0
@@ -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.

Quoted 6 lines

Quoted 4 lines
[Lv Zheng]
There is a commit in 4.7-rc2:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7f9bef9d
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.

I have decided to revert commit 66b1ed5aa8dd25 as in principle other registers may be similarly affected on other systems.

Thanks,
Rafael

Zheng, Lv

2016-06-15 06:05 UTC #8 lore raw

Hi, Rafael

Quoted 104 lines

From: rjwysocki(a)gmail.com [mailto:rjwysocki(a)gmail.com] On Behalf Of Rafael J. Wysocki
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 13 lines · Andrey Skvortsov
Hi Lv,
Quoted 10 lines · Lv
Quoted 10 lines
From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi- owner(a)vger.kernel.org] On Behalf Of Rafael J. Wysocki
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 5 lines · Andrey Skvortsov
Quoted 4 lines · Rafael J. Wysocki
Quoted 3 lines · Andrey Skvortsov
Hi,
On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend
to RAM.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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
ump.bin
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
The root of the problem seems to be not the commit
66b1ed5aa8dd25
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
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?
Quoted 7 lines
Quoted 3 lines
[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 1 line
However there is a real case showing that there are real tables need us
to correctly support BitWidth/BitOffset.
Quoted 5 lines
Quoted 5 lines
Here is the information for you to refer:
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Well, if the commit in question caused a problem to happen for
you,
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 1 line
control register or even for all registers? This will fix the issue too.
That's a good idea actually.
drivers/acpi/acpica/tbfadt.c static void
Quoted 5 lines
(quoted diff) +0 -0
b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
drivers/acpi/acpica/tbfadt.c +0 -0
@@ -714,7 +714,14 @@ static void
acpi_tb_setup_fadt_registers(void)
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
drivers/acpi/acpica/tbfadt.c +6 -0
                        }
                }
        }
 
+       /*
+        * 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;
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
OK, let's see what Bob and Lv think about that.
[Lv Zheng]
There is a commit in 4.7-rc2:

Quoted 8 lines

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
7f9bef9d
Quoted 3 lines
Quoted 1 line
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.
I have decided to revert commit 66b1ed5aa8dd25 as in principle other registers may be similarly affected on other systems.

[Lv Zheng]
Yes.
I didn't prepare fallback mechanism for this support. It seems we have to do the reversion.
Please revert it.
Next time I'll prepare a quirk mechanism when this is upstreamed.

For Andrey:
Could you provide me the DMIdecode output of the machine?

Thanks
-Lv

Quoted 3 lines

Thanks,
Rafael

Andrey Skvortsov

author

2016-06-15 20:03 UTC #9 lore raw

Quoted 112 lines · Lv

Hi, Rafael
Quoted 110 lines
From: [email protected] [mailto:[email protected]] On Behalf Of Rafael J. Wysocki
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 13 lines · Andrey Skvortsov
Hi Lv,
Quoted 10 lines · Lv
Quoted 10 lines
From: [email protected] [mailto:linux-acpi- [email protected]] On Behalf Of Rafael J. Wysocki
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 5 lines · Andrey Skvortsov
Quoted 4 lines · Rafael J. Wysocki
Quoted 3 lines · Andrey Skvortsov
Hi,
On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend
to RAM.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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
ump.bin
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
The root of the problem seems to be not the commit
66b1ed5aa8dd25
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
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?
Quoted 7 lines
Quoted 3 lines
[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 1 line
However there is a real case showing that there are real tables need us
to correctly support BitWidth/BitOffset.
Quoted 5 lines
Quoted 5 lines
Here is the information for you to refer:
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Well, if the commit in question caused a problem to happen for
you,
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 1 line
control register or even for all registers? This will fix the issue too.
That's a good idea actually.
drivers/acpi/acpica/tbfadt.c static void
Quoted 5 lines
(quoted diff) +0 -0
b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
drivers/acpi/acpica/tbfadt.c +0 -0
@@ -714,7 +714,14 @@ static void
acpi_tb_setup_fadt_registers(void)
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
drivers/acpi/acpica/tbfadt.c +6 -0
                        }
                }
        }
 
+       /*
+        * 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;
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
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=
7f9bef9d
Quoted 3 lines
Quoted 1 line
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.

Quoted 8 lines

Quoted 2 lines
I have decided to revert commit 66b1ed5aa8dd25 as in principle other registers may be similarly affected on other systems.
[Lv Zheng]
Yes.
I didn't prepare fallback mechanism for this support. It seems we have to do the reversion.
Please revert it.
Next time I'll prepare a quirk mechanism when this is upstreamed.

Lv, Could you CC me, when you'll upstream quirk mechanism?

Quoted 2 lines

For Andrey:
Could you provide me the DMIdecode output of the machine?

DMI binary dump is available here:
https://dl.dropboxusercontent.com/u/24023626/dell-vostro-1500.dmidecode.dump

And here is dmidecode output:

# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.4 present.
45 structures occupying 1977 bytes.
Table at 0x000F7180.

Handle 0xDA00, DMI type 218, 251 bytes OEM-specific Type

	Header and Data:
		DA FB 00 DA B2 00 0D 5F 1F 37 40 7D 00 00 00 00
		00 7E 00 02 00 00 00 40 00 04 00 01 00 41 00 04
		00 00 00 65 00 05 00 00 00 66 00 05 00 01 00 5E
		00 06 00 01 00 5F 00 06 00 00 00 89 01 07 00 00
		00 8A 01 07 00 01 00 42 00 08 00 01 00 43 00 08
		00 00 00 55 00 09 00 00 00 6D 00 09 00 01 00 2D
		00 0A 00 02 00 6E 00 0A 00 01 00 2E 00 0A 00 00
		00 11 01 0B 00 00 00 10 01 0B 00 01 00 F0 00 0C
		00 01 00 ED 00 0C 00 00 00 41 01 0D 00 01 00 40
		01 0D 00 00 00 47 01 0E 00 01 00 46 01 0E 00 00
		00 4A 01 0F 00 00 00 4B 01 0F 00 01 00 52 01 10
		00 01 00 53 01 10 00 00 00 80 01 11 00 01 00 7F
		01 11 00 00 00 7C 01 12 00 01 00 7B 01 12 00 00
		00 7E 01 13 00 01 00 7D 01 13 00 00 00 92 01 14
		00 00 00 91 01 14 00 01 00 94 01 15 00 00 00 93
		01 15 00 01 00 FF FF 00 00 00 00

Handle 0xDA01, DMI type 218, 251 bytes OEM-specific Type

	Header and Data:
		DA FB 01 DA B2 00 0D 5F 1F 37 40 86 01 16 00 01
		00 85 01 16 00 00 00 82 01 17 00 01 00 81 01 17
		00 00 00 84 01 18 00 01 00 83 01 18 00 00 00 9B
		01 19 00 00 00 9C 01 19 00 01 00 9D 01 19 00 02
		00 9E 01 19 00 03 00 8B 01 1A 00 00 00 8C 01 1A
		00 01 00 EA 00 1B 00 00 00 EB 00 1B 00 01 00 EC
		00 1B 00 02 00 28 00 1C 00 00 00 29 00 1C 00 01
		00 2A 00 1C 00 02 00 2B 00 1D 00 00 00 2C 00 1E
		00 00 00 E7 00 1F 00 01 00 E6 00 1F 00 00 00 0E
		01 20 00 01 00 0F 01 20 00 00 00 9B 00 21 00 01
		00 9C 00 21 00 00 00 4D 01 22 00 01 00 4C 01 22
		00 00 00 01 01 23 00 00 00 02 01 23 00 01 00 04
		01 23 00 02 00 37 01 24 00 00 00 38 01 24 00 01
		00 D9 01 25 00 01 00 D8 01 25 00 00 00 EA 01 26
		00 00 00 EB 01 26 00 01 00 EC 01 27 00 00 00 ED
		01 27 00 01 00 FF FF 00 00 00 00

Handle 0xDA02, DMI type 218, 53 bytes OEM-specific Type

	Header and Data:
		DA 35 02 DA B2 00 0D 5F 1F 37 40 76 01 76 01 01
		00 75 01 75 01 01 00 01 F0 01 F0 00 00 02 F0 02
		F0 00 00 03 F0 03 F0 00 00 04 F0 04 F0 00 00 FF
		FF 00 00 00 00

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Dell Inc.
Version: A06
Release Date: 04/21/2008
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 1024 kB
Characteristics:
ISA is supported
PCI is supported
PC Card (PCMCIA) is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
3.5"/720 kB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported
USB legacy is supported
AGP is supported
Smart battery is supported
BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported
BIOS Revision: 0.6
Firmware Revision: 0.6

Handle 0x0100, DMI type 1, 27 bytes
System Information
Manufacturer: Dell Inc.
Product Name: Vostro 1500
Version: Not Specified
Serial Number: 2KPDQF1
UUID: 44454C4C-4B00-1050-8044-B2C04F514631 Wake-up Type: Power Switch
SKU Number: Not Specified
Family:

Handle 0x0200, DMI type 2, 9 bytes
Base Board Information
Manufacturer: Dell Inc.
Product Name: 0NX907
Version:
Serial Number: .2KPDQF1.CN486438228200. Asset Tag:

Handle 0x0300, DMI type 3, 13 bytes Chassis Information
Manufacturer: Dell Inc.
Type: Portable
Lock: Not Present
Version: Not Specified Serial Number: 2KPDQF1 Asset Tag: Not Specified Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None

Handle 0x0400, DMI type 4, 40 bytes
Processor Information
Socket Designation: Microprocessor
Type: Central Processor
Family: Core 2 Duo
Manufacturer: Intel
ID: 76 06 01 00 FF FB EB BF
Signature: Type 0, Family 6, Model 23, Stepping 6 Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call)
MTRR (Memory type range registers) PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported) PAT (Page attribute table)
PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store)
ACPI (ACPI supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
SS (Self-snoop)
HTT (Multi-threading)
TM (Thermal monitor supported)
PBE (Pending break enabled)
Version: Not Specified
Voltage: 3.3 V
External Clock: 200 MHz
Max Speed: 2600 MHz
Current Speed: 2600 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x0700
L2 Cache Handle: 0x0701
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Core Count: 2
Core Enabled: 2
Thread Count: 2
Characteristics:
64-bit capable

Handle 0x0700, DMI type 7, 19 bytes
Cache Information
Socket Designation: Not Specified
Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Back
Location: Internal
Installed Size: 32 kB
Maximum Size: 32 kB
Supported SRAM Types:
Unknown
Installed SRAM Type: Unknown
Speed: Unknown
Error Correction Type: None
System Type: Data
Associativity: 4-way Set-associative

Handle 0x0701, DMI type 7, 19 bytes
Cache Information
Socket Designation: Not Specified
Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Varies With Memory Address
Location: Internal
Installed Size: 6144 kB
Maximum Size: 6144 kB
Supported SRAM Types:
Pipeline Burst
Installed SRAM Type: Pipeline Burst
Speed: 15 ns
Error Correction Type: None
System Type: Unified
Associativity: Other

Handle 0x0804, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: USB Internal Connector Type: None External Reference Designator: Not Specified External Connector Type: Access Bus (USB) Port Type: USB

Handle 0x0806, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: MONITOR Internal Connector Type: None External Reference Designator: Not Specified External Connector Type: DB-15 female Port Type: Video Port

Handle 0x080B, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: FireWire Internal Connector Type: None External Reference Designator: Not Specified External Connector Type: IEEE 1394 Port Type: Firewire (IEEE P1394)

Handle 0x080C, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Modem Internal Connector Type: None External Reference Designator: Not Specified External Connector Type: RJ-11
Port Type: Modem Port

Handle 0x080D, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Ethernet Internal Connector Type: None External Reference Designator: Not Specified External Connector Type: RJ-45
Port Type: Network Port

Handle 0x0A00, DMI type 10, 6 bytes
On Board Device Information
Type: Video
Status: Enabled
Description: Intel Crestline Graphics

Handle 0x0A01, DMI type 10, 6 bytes On Board Device Information
Type: Sound
Status: Enabled
Description: Sigmatel 9205

Handle 0x0B00, DMI type 11, 5 bytes OEM Strings

	String 1: Dell System
	String 2: 5[0003]
	String 3: 13[PP22L]

Handle 0x0D00, DMI type 13, 22 bytes
BIOS Language Information
Language Description Format: Long Installable Languages: 1
en|US|iso8859-1
Currently Installed Language: en|US|iso8859-1

Handle 0x1000, DMI type 16, 15 bytes Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None Maximum Capacity: 4 GB
Error Information Handle: Not Provided Number Of Devices: 2

Handle 0x1100, DMI type 17, 27 bytes Memory Device

	Array Handle: 0x1000
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM_A
	Bank Locator: Not Specified
	Type: DDR
	Type Detail: Synchronous
	Speed: 667 MHz
	Manufacturer: 7F98000000000000
	Serial Number: 453E7A84
	Asset Tag: 000B05
	Part Number:

Handle 0x1101, DMI type 17, 27 bytes Memory Device

	Array Handle: 0x1000
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 256 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM_B
	Bank Locator: Not Specified
	Type: DDR
	Type Detail: Synchronous
	Speed: 667 MHz
	Manufacturer: 7F7F7F7F7F020000
	Serial Number: 00000000
	Asset Tag: 000000
	Part Number: PSD24G8002S

Handle 0x1301, DMI type 19, 15 bytes Memory Array Mapped Address

	Starting Address: 0x00000000000
	Ending Address: 0x0008FFFFFFF
	Range Size: 2304 MB
	Physical Array Handle: 0x1000
	Partition Width: 1

Handle 0x1401, DMI type 20, 19 bytes Memory Device Mapped Address

	Starting Address: 0x00000000000
	Ending Address: 0x0001FFFFFFF
	Range Size: 512 MB
	Physical Device Handle: 0x1100
	Memory Array Mapped Address Handle: 0x1301
	Partition Row Position: 1
	Interleave Position: 1
	Interleaved Data Depth: 8

Handle 0x1411, DMI type 20, 19 bytes Memory Device Mapped Address

	Starting Address: 0x00020000000
	Ending Address: 0x0008FFFFFFF
	Range Size: 1792 MB
	Physical Device Handle: 0x1100
	Memory Array Mapped Address Handle: 0x1301
	Partition Row Position: 1

Handle 0x1402, DMI type 20, 19 bytes Memory Device Mapped Address

	Starting Address: 0x00000000000
	Ending Address: 0x0001FFFFFFF
	Range Size: 512 MB
	Physical Device Handle: 0x1101
	Memory Array Mapped Address Handle: 0x1301
	Partition Row Position: 1
	Interleave Position: 2
	Interleaved Data Depth: 8

Handle 0x1412, DMI type 126, 19 bytes Inactive

Handle 0x1500, DMI type 21, 7 bytes Built-in Pointing Device
Type: Touch Pad
Interface: Bus Mouse
Buttons: 2

Handle 0x1600, DMI type 22, 26 bytes Portable Battery
Location: Sys. Battery Bay
Manufacturer: Sanyo
Name: DELL UW28082
Design Capacity: 78000 mWh Design Voltage: 11100 mV
SBDS Version: 1.0
Maximum Error: 1%
SBDS Serial Number: 1019
SBDS Manufacture Date: 2008-02-15 SBDS Chemistry: LION OEM-specific Information: 0x00000001

Handle 0x1B00, DMI type 27, 12 bytes Cooling Device

	Type: Fan
	Status: OK
	OEM-specific Information: 0x0000DD00

Handle 0x1C00, DMI type 28, 20 bytes Temperature Probe
Description: CPU Internal Temperature
Location: Processor
Status: OK
Maximum Value: 127.0 deg C Minimum Value: 0.0 deg C
Resolution: 1.000 deg C
Tolerance: 0.5 deg C
Accuracy: Unknown
OEM-specific Information: 0x0000DC00

Handle 0x2000, DMI type 32, 11 bytes System Boot Information
Status: No errors detected

Handle 0xB000, DMI type 176, 5 bytes OEM-specific Type

	Header and Data:
		B0 05 00 B0 01

Handle 0xB100, DMI type 177, 12 bytes OEM-specific Type

	Header and Data:
		B1 0C 00 B1 02 00 00 00 00 00 00 00

Handle 0xB200, DMI type 178, 6 bytes OEM-specific Type

	Header and Data:
		B2 06 00 B2 99 99

Handle 0xD000, DMI type 208, 10 bytes OEM-specific Type

	Header and Data:
		D0 0A 00 D0 01 04 FE 00 28 02

Handle 0xD800, DMI type 216, 9 bytes OEM-specific Type

	Header and Data:
		D8 09 00 D8 01 03 01 F0 03
	Strings:
		Intel Corp.          
		 
		1466

Handle 0xD900, DMI type 217, 8 bytes OEM-specific Type

	Header and Data:
		D9 08 00 D9 01 02 01 03
	Strings:
		US-101
		Proprietary

Handle 0xDB00, DMI type 219, 9 bytes
OEM-specific Type
Header and Data:
DB 09 00 DB 03 01 02 03 FF
Strings:
System Device Bay
Floppy, Battery, CD-ROM, CD-RW, DVD, DVD+RW, DVD+/-RW, Hard Disk, BLU-RAY Hard-Disk

Handle 0xDC00, DMI type 220, 22 bytes OEM-specific Type

	Header and Data:
		DC 16 00 DC 01 F0 00 00 02 F0 00 00 00 00 03 F0
		04 F0 00 00 00 00

Handle 0xDD00, DMI type 221, 19 bytes OEM-specific Type

	Header and Data:
		DD 13 00 DD 00 00 00 00 00 00 00 00 00 00 00 00
		00 00 00

Handle 0xD400, DMI type 212, 37 bytes OEM-specific Type

	Header and Data:
		D4 25 00 D4 74 00 75 00 00 10 2D 2E 5C 00 78 BF
		40 5D 00 78 BF 00 08 00 1D DF 00 03 00 1D DF 00
		FF FF 00 00 00

Handle 0xD401, DMI type 212, 17 bytes OEM-specific Type

	Header and Data:
		D4 11 01 D4 74 00 75 00 03 40 49 4A FF FF 00 00
		00

Handle 0xDE00, DMI type 222, 16 bytes OEM-specific Type

	Header and Data:
		DE 10 00 DE 01 02 FF FF 00 00 00 00 00 00 00 01

Handle 0x7F00, DMI type 127, 4 bytes End Of Table

Signature · 2 lines

Best regards,
Andrey Skvortsov

Zheng, Lv

2016-06-24 01:02 UTC #10 lore raw

In reply to Andrey Skvortsov

Hi,

Quoted 34 lines

From: Andrey Skvortsov [mailto:andrej.skvortzov(a)gmail.com]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Hi Lv,
Quoted 10 lines · Lv
Quoted 10 lines
From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi- owner(a)vger.kernel.org] On Behalf Of Rafael J. Wysocki
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 5 lines · Andrey Skvortsov
Quoted 4 lines · Rafael J. Wysocki
Quoted 3 lines · Andrey Skvortsov
Hi,
On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend
to RAM.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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.

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
To get it working 'access_width' for PM1A Control Block needs to 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
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?

Quoted 54 lines

Quoted 9 lines
Quoted 9 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
The root of the problem seems to be not the commit
66b1ed5aa8dd25
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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.
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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?
[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 1 line
However there is a real case showing that there are real tables need us to
correctly support BitWidth/BitOffset.
Quoted 5 lines
Here is the information for you to refer:
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Well, if the commit in question caused a problem to happen for
you,
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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 9 lines
Quoted 9 lines
Quoted 1 line
control register or even for all registers? This will fix the issue too.
That's a good idea actually.
drivers/acpi/acpica/tbfadt.c static void
Quoted 5 lines
(quoted diff) +0 -0
b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
drivers/acpi/acpica/tbfadt.c +0 -0
@@ -714,7 +714,14 @@ static void
acpi_tb_setup_fadt_registers(void)
Quoted 12 lines
Quoted 12 lines
drivers/acpi/acpica/tbfadt.c static void acpi_tb_setup_fadt_registers(void) · line 723
Quoted 10 lines
drivers/acpi/acpica/tbfadt.c +6 -0
                        }
                }
        }
 
+       /*
+        * 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.

Quoted 8 lines

Quoted 3 lines
[Lv Zheng]
There is a commit in 4.7-rc2:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
7f9bef9d
Quoted 1 line
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

Thanks
-Lv

Andrey Skvortsov

author

2016-06-24 21:32 UTC #11 lore raw

Quoted 38 lines · Lv

Hi,
Quoted 36 lines
From: Andrey Skvortsov [mailto:[email protected]]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Hi Lv,
Quoted 10 lines · Lv
Quoted 10 lines
From: [email protected] [mailto:linux-acpi- [email protected]] On Behalf Of Rafael J. Wysocki
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 5 lines · Andrey Skvortsov
Quoted 4 lines · Rafael J. Wysocki
Quoted 3 lines · Andrey Skvortsov
Hi,
On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend
to RAM.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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).

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
[Lv Zheng]
Could you send me the acpidump of the machine?
Here it is
https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpid
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 64 lines

Quoted 52 lines
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
The root of the problem seems to be not the commit
66b1ed5aa8dd25
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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.
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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?
[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 1 line
However there is a real case showing that there are real tables need us to
correctly support BitWidth/BitOffset.
Quoted 5 lines
Here is the information for you to refer:
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Well, if the commit in question caused a problem to happen for
you,
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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 9 lines
Quoted 9 lines
Quoted 1 line
control register or even for all registers? This will fix the issue too.
That's a good idea actually.
drivers/acpi/acpica/tbfadt.c static void
Quoted 5 lines
(quoted diff) +0 -0
b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
drivers/acpi/acpica/tbfadt.c +0 -0
@@ -714,7 +714,14 @@ static void
acpi_tb_setup_fadt_registers(void)
Quoted 12 lines
Quoted 12 lines
drivers/acpi/acpica/tbfadt.c static void acpi_tb_setup_fadt_registers(void) · line 723
Quoted 10 lines
drivers/acpi/acpica/tbfadt.c +6 -0
                        }
                }
        }
 
+       /*
+        * 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.
Quoted 8 lines
Quoted 3 lines
[Lv Zheng]
There is a commit in 4.7-rc2:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
7f9bef9d
Quoted 1 line
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:

Quoted 5 lines

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.

http://lxr.free-electrons.com/source/drivers/acpi/acpica/tbfadt.c#L576

acpi=rsdt helps. Thanks for the information about this option. I missed it, when I read documentation.

Signature · 2 lines

Best regards,
Andrey Skvortsov

Zheng, Lv

2016-06-27 01:17 UTC #12 lore raw

Hi,

Quoted 50 lines

From: Andrey Skvortsov [mailto:andrej.skvortzov(a)gmail.com]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 18 lines · Lv
Hi,
Quoted 16 lines
From: Andrey Skvortsov [mailto:andrej.skvortzov(a)gmail.com]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Hi Lv,
Quoted 10 lines · Lv
Quoted 10 lines
From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi- owner(a)vger.kernel.org] On Behalf Of Rafael J. Wysocki
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 5 lines · Andrey Skvortsov
Quoted 4 lines · Rafael J. Wysocki
Quoted 3 lines · Andrey Skvortsov
Hi,
On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken
suspend
Quoted 2 lines
Quoted 2 lines
to RAM.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Laptop doesn't finish suspend to RAM process (disks are off,
but
Quoted 9 lines
Quoted 9 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
for acpi_hw_write()].
If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to
RAM
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
is working again.
The cause of this problem is that after this commit write to
PM1A
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
be 2 (16-bit), but it's 1 (8-bit).
[Lv Zheng]
Could you send me the acpidump of the machine?
Here it is

Quoted 7 lines

https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpid
Quoted 4 lines
Quoted 1 line
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.

[Lv Zheng]
Maybe this is just because of ISP firewall.

Quoted 1 line

Anyway I resend you all files off-list.

[Lv Zheng]
Great!

Quoted 78 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
The root of the problem seems to be not the commit
66b1ed5aa8dd25
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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 7 lines
Quoted 7 lines
Quoted 3 lines
[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 1 line
However there is a real case showing that there are real tables need
us to
Quoted 3 lines
Quoted 3 lines
correctly support BitWidth/BitOffset.
Quoted 2 lines
Here is the information for you to refer:
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
Quoted 21 lines
Quoted 21 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Well, if the commit in question caused a problem to happen for
you,
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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 9 lines
Quoted 9 lines
Quoted 1 line
control register or even for all registers? This will fix the issue too.
That's a good idea actually.
drivers/acpi/acpica/tbfadt.c static void
Quoted 5 lines
(quoted diff) +0 -0
b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
drivers/acpi/acpica/tbfadt.c +0 -0
@@ -714,7 +714,14 @@ static void
acpi_tb_setup_fadt_registers(void)
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c static void · line 719
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c +2 -0
                        }
                }
        }
 
+       /*
+        * Reset access_width in the GAS for PM1A control register
to
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c static void · line 723
Quoted 4 lines
drivers/acpi/acpica/tbfadt.c +4 -0
+        * 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 8 lines
Quoted 4 lines
7f9bef9d
Quoted 1 line
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:
Quoted 5 lines
acpi=rsdt
Or
acpi_force_32bit_fadt_addr
Or
Both

Quoted 7 lines

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.
http://lxr.free-electrons.com/source/drivers/acpi/acpica/tbfadt.c#L576

[Lv Zheng]
In addition to the address check, we may add access width check here. I need to check this with the decision makers.

Quoted 4 lines

acpi=rsdt helps. Thanks for the information about this option. I missed it, when I read documentation.

[Lv Zheng]
Great to know that at least 1 quirk works.
Back to this bug, it seems we should use fixed access_width for some pre-defined PM registers.

Thanks and best regards
-Lv

Andrey Skvortsov

author

2016-06-27 08:49 UTC #13 lore raw

Quoted 146 lines · Lv

Hi,
Quoted 50 lines
From: Andrey Skvortsov [mailto:[email protected]]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 18 lines · Lv
Hi,
Quoted 16 lines
From: Andrey Skvortsov [mailto:[email protected]]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Hi Lv,
Quoted 10 lines · Lv
Quoted 10 lines
From: [email protected] [mailto:linux-acpi- [email protected]] On Behalf Of Rafael J. Wysocki
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 5 lines · Andrey Skvortsov
Quoted 4 lines · Rafael J. Wysocki
Quoted 3 lines · Andrey Skvortsov
Hi,
On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken
suspend
Quoted 2 lines
Quoted 2 lines
to RAM.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Laptop doesn't finish suspend to RAM process (disks are off,
but
Quoted 9 lines
Quoted 9 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
for acpi_hw_write()].
If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to
RAM
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
is working again.
The cause of this problem is that after this commit write to
PM1A
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
be 2 (16-bit), but it's 1 (8-bit).
[Lv Zheng]
Could you send me the acpidump of the machine?
Here it is
Quoted 7 lines
https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpid
Quoted 4 lines
Quoted 1 line
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.
[Lv Zheng]
Maybe this is just because of ISP firewall.
Quoted 1 line
Anyway I resend you all files off-list.
[Lv Zheng]
Great!
Quoted 80 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
The root of the problem seems to be not the commit
66b1ed5aa8dd25
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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 7 lines
Quoted 7 lines
Quoted 3 lines
[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 1 line
However there is a real case showing that there are real tables need
us to
Quoted 3 lines
Quoted 3 lines
correctly support BitWidth/BitOffset.
Quoted 2 lines
Here is the information for you to refer:
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
Quoted 21 lines
Quoted 21 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Well, if the commit in question caused a problem to happen for
you,
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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 9 lines
Quoted 9 lines
Quoted 1 line
control register or even for all registers? This will fix the issue too.
That's a good idea actually.
drivers/acpi/acpica/tbfadt.c static void
Quoted 5 lines
(quoted diff) +0 -0
b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
drivers/acpi/acpica/tbfadt.c +0 -0
@@ -714,7 +714,14 @@ static void
acpi_tb_setup_fadt_registers(void)
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c static void · line 719
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c +2 -0
                        }
                }
        }
 
+       /*
+        * Reset access_width in the GAS for PM1A control register
to
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c static void · line 723
Quoted 4 lines
drivers/acpi/acpica/tbfadt.c +4 -0
+        * 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 8 lines
Quoted 4 lines
7f9bef9d
Quoted 1 line
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:
Quoted 5 lines
acpi=rsdt
Or
acpi_force_32bit_fadt_addr
Or
Both
Rafael reverted commit, so I'm ok now.

Quoted 8 lines

Quoted 5 lines
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.
http://lxr.free-electrons.com/source/drivers/acpi/acpica/tbfadt.c#L576
[Lv Zheng]
In addition to the address check, we may add access width check here. I need to check this with the decision makers.

Make sense. But then it's necessary to set default access width for registers from FADT for this check. Because in the old 32-bit part of FADT only address and length are defined, but not access width.

Quoted 5 lines

Quoted 2 lines
acpi=rsdt helps. Thanks for the information about this option. I missed it, when I read documentation.
[Lv Zheng]
Great to know that at least 1 quirk works.
Back to this bug, it seems we should use fixed access_width for some pre-defined PM registers.

This is what I meant by suggesting to reset xpm1a's
access_width to zero (or maybe another registers from FADT too) in acpi_tb_setup_fadt_registers (see quoted diff above from my previous answer). If access_width is zero, then code works as before and access_width is calculated by acpi_hw_get_access_bit_width (will return reg->bit_width or max_bit_width(32) in our case).

Setting access_width to some pre-defined value is an option.
But it's not as flexible, because ACPI specification doesn't define access width and some pre-defined PM registers have variable length and only the minimal register length is defined (PM1A Control Reg, PM1B Control Reg, PM1A event block, PM1B event block).

Previously you pointed to commit that requires usage of access width field.
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
I see it's related to APEI, therefore setting access_width for registers in FADT will not affect it.

Signature · 2 lines

Best regards,
Andrey Skvortsov

Zheng, Lv

2016-06-28 05:10 UTC #14 lore raw

Hi,

Quoted 212 lines

From: Andrey Skvortsov [mailto:andrej.skvortzov(a)gmail.com]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 19 lines · Lv
Hi,
Quoted 17 lines
From: Andrey Skvortsov [mailto:andrej.skvortzov(a)gmail.com]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 13 lines · Lv
Hi,
Quoted 11 lines
From: Andrey Skvortsov [mailto:andrej.skvortzov(a)gmail.com]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Hi Lv,
Quoted 5 lines · Lv
Quoted 5 lines
From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi- owner(a)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
Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line
On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov
Quoted 6 lines · wrote:
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Hi,
On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken
suspend
Quoted 2 lines
Quoted 2 lines
to RAM.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Laptop doesn't finish suspend to RAM process (disks are
off,
Quoted 2 lines
Quoted 2 lines
but
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
WiFi and Power LEDs are still on). The only way to get it
out of
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
support
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
for acpi_hw_write()].
If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to
RAM
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
is working again.
The cause of this problem is that after this commit write
to
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
PM1A
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Control Block (16-bit register) is done using two 8-bit
writes.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
If I force this write to be 16-bit, then all is working as
before.
Quoted 9 lines
Quoted 9 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
To get it working 'access_width' for PM1A Control Block
needs to
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
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?
Quoted 14 lines
Quoted 2 lines
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.
[Lv Zheng]
Maybe this is just because of ISP firewall.
Quoted 1 line
Anyway I resend you all files off-list.
[Lv Zheng]
Great!
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
The root of the problem seems to be not the commit
66b1ed5aa8dd25
Quoted 1 line
Quoted 1 line
Quoted 1 line
itself, but the ACPI tables in BIOS where wrong
access_width
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
comes from. I fixed problem in FACP table, put it in initrd
to
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
override FACP table from BIOS. This fixed the issue,
suspend
Quoted 4 lines
Quoted 4 lines
to
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
RAM is working now again.
But I'm not sure whether is this proper fix for this
problem.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Is there any place in the kernel, where such ACPI quirks
are
Quoted 8 lines
Quoted 8 lines
placed?
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
[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 1 line
However there is a real case showing that there are real tables
need
Quoted 5 lines
Quoted 5 lines
us to
Quoted 3 lines
Quoted 3 lines
correctly support BitWidth/BitOffset.
Quoted 2 lines
Here is the information for you to refer:
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Well, if the commit in question caused a problem to happen
for
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
you,
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
PM1A
Quoted 1 line
Quoted 1 line
Quoted 1 line
control register or even for all registers? This will fix the issue
too.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
That's a good idea actually.
Quoted 2 lines
(quoted diff) +0 -0
b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94
100644
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 3 lines
Quoted 3 lines
drivers/acpi/acpica/tbfadt.c static void
Quoted 3 lines
drivers/acpi/acpica/tbfadt.c +0 -0
@@ -714,7 +714,14 @@ static void
acpi_tb_setup_fadt_registers(void)
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c +2 -0
                        }
                }
        }
 
+       /*
+        * Reset access_width in the GAS for PM1A control
register
Quoted 2 lines
Quoted 2 lines
to
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
drivers/acpi/acpica/tbfadt.c +1 -0
+        * undefined value. Because in some cases this field
contains
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Quoted 5 lines
drivers/acpi/acpica/tbfadt.c static void · line 723
Quoted 3 lines
drivers/acpi/acpica/tbfadt.c +3 -0
+        * 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 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
7f9bef9d
Quoted 1 line
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
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
Quoted 1 line
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
Quoted 3 lines
Quoted 3 lines
Rafael reverted commit, so I'm ok now.
Actually acpi_force_32bit_fadt_addr will not help here, because it's
take
Quoted 4 lines
Quoted 4 lines
effect only if address64 != address32. But here these addresses are the same, therefore access_width is taken from extended address.
http://lxr.free-
electrons.com/source/drivers/acpi/acpica/tbfadt.c#L576
Quoted 3 lines
[Lv Zheng]
In addition to the address check, we may add access width check here. I need to check this with the decision makers.
Make sense. But then it's necessary to set default access width for registers from
FADT for this check. Because in the old 32-bit part of FADT only address and
length are defined, but not access width.
Quoted 5 lines
Quoted 2 lines
acpi=rsdt helps. Thanks for the information about this option. I missed it, when I read documentation.
[Lv Zheng]
Great to know that at least 1 quirk works.
Back to this bug, it seems we should use fixed access_width for some
pre-defined PM registers.
This is what I meant by suggesting to reset xpm1a's access_width to zero (or maybe another registers from FADT too) in acpi_tb_setup_fadt_registers (see quoted diff above from my previous answer).
If access_width is zero, then code works as before and access_width is calculated by acpi_hw_get_access_bit_width (will return reg->bit_width or max_bit_width(32) in our case).
Setting access_width to some pre-defined value is an option. But it's not as flexible, because ACPI specification doesn't define access width and some pre-defined PM registers have variable length and only the minimal register length is defined (PM1A Control Reg, PM1B Control
Reg, PM1A event block, PM1B event block).

Quoted 5 lines

Previously you pointed to commit that requires usage of access width field.
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
I see it's related to APEI, therefore setting access_width for registers in FADT will not affect it.

[Lv Zheng]
Yes, I can see your point and it looks reasonable. For now, I'm going to probe Windows behavior using qemu.

It looks I can achieve this by modifying:
hw/i386/acpi-build.c: http://git.qemu.org/?p=qemu.git;a=blob;f=hw/i386/acpi-build.c
hw/acpi/ich9.c: http://git.qemu.org/?p=qemu.git;a=blob;f=hw/acpi/ich9.c

The result may help us to make more accurate decision.

Thanks and best regards
-Lv

Zheng, Lv

2016-08-05 01:06 UTC #15 lore raw

In reply to Andrey Skvortsov

Hi, Andrey

Quoted 136 lines

From: Andrey Skvortsov [mailto:andrej.skvortzov(a)gmail.com]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 18 lines · Lv
Hi,
Quoted 16 lines
From: Andrey Skvortsov [mailto:andrej.skvortzov(a)gmail.com]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Hi Lv,
Quoted 10 lines · Lv
Quoted 10 lines
From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi- owner(a)vger.kernel.org] On Behalf Of Rafael J. Wysocki
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 5 lines · Andrey Skvortsov
Quoted 4 lines · Rafael J. Wysocki
Quoted 3 lines · Andrey Skvortsov
Hi,
On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken
suspend
Quoted 2 lines
Quoted 2 lines
to RAM.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Laptop doesn't finish suspend to RAM process (disks are off,
but
Quoted 9 lines
Quoted 9 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
for acpi_hw_write()].
If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to
RAM
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
is working again.
The cause of this problem is that after this commit write to
PM1A
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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 4 lines
Quoted 1 line
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 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
The root of the problem seems to be not the commit
66b1ed5aa8dd25
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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 7 lines
Quoted 7 lines
Quoted 3 lines
[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 1 line
However there is a real case showing that there are real tables need
us to
Quoted 3 lines
Quoted 3 lines
correctly support BitWidth/BitOffset.
Quoted 2 lines
Here is the information for you to refer:
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
Quoted 21 lines
Quoted 21 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Well, if the commit in question caused a problem to happen for
you,
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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 9 lines
Quoted 9 lines
Quoted 1 line
control register or even for all registers? This will fix the issue too.
That's a good idea actually.
drivers/acpi/acpica/tbfadt.c static void
Quoted 5 lines
(quoted diff) +0 -0
b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
drivers/acpi/acpica/tbfadt.c +0 -0
@@ -714,7 +714,14 @@ static void
acpi_tb_setup_fadt_registers(void)
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c static void · line 719
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c +2 -0
                        }
                }
        }
 
+       /*
+        * Reset access_width in the GAS for PM1A control register
to
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c static void · line 723
Quoted 4 lines
drivers/acpi/acpica/tbfadt.c +4 -0
+        * 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 8 lines
Quoted 4 lines
7f9bef9d
Quoted 1 line
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:
Quoted 5 lines
acpi=rsdt
Or
acpi_force_32bit_fadt_addr
Or
Both

Quoted 5 lines

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

Thanks in advance.

Best regards
Lv

Quoted 13 lines

http://lxr.free-electrons.com/source/drivers/acpi/acpica/tbfadt.c#L576
acpi=rsdt helps. Thanks for the information about this option. I missed it, when I read documentation.
--
Best regards,
Andrey Skvortsov

Andrey Skvortsov

author

2016-08-10 18:13 UTC #16 lore raw

Quoted 143 lines · Lv

Hi, Andrey
Quoted 136 lines
From: Andrey Skvortsov [mailto:[email protected]]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 18 lines · Lv
Hi,
Quoted 16 lines
From: Andrey Skvortsov [mailto:[email protected]]
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Hi Lv,
Quoted 10 lines · Lv
Quoted 10 lines
From: [email protected] [mailto:linux-acpi- [email protected]] On Behalf Of Rafael J. Wysocki
Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
Quoted 5 lines · Andrey Skvortsov
Quoted 4 lines · Rafael J. Wysocki
Quoted 3 lines · Andrey Skvortsov
Hi,
On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken
suspend
Quoted 2 lines
Quoted 2 lines
to RAM.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Laptop doesn't finish suspend to RAM process (disks are off,
but
Quoted 9 lines
Quoted 9 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
for acpi_hw_write()].
If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to
RAM
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
is working again.
The cause of this problem is that after this commit write to
PM1A
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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 4 lines
Quoted 1 line
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 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
The root of the problem seems to be not the commit
66b1ed5aa8dd25
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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 7 lines
Quoted 7 lines
Quoted 3 lines
[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 1 line
However there is a real case showing that there are real tables need
us to
Quoted 3 lines
Quoted 3 lines
correctly support BitWidth/BitOffset.
Quoted 2 lines
Here is the information for you to refer:
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
Quoted 21 lines
Quoted 21 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Well, if the commit in question caused a problem to happen for
you,
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
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 9 lines
Quoted 9 lines
Quoted 1 line
control register or even for all registers? This will fix the issue too.
That's a good idea actually.
drivers/acpi/acpica/tbfadt.c static void
Quoted 5 lines
(quoted diff) +0 -0
b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
drivers/acpi/acpica/tbfadt.c +0 -0
@@ -714,7 +714,14 @@ static void
acpi_tb_setup_fadt_registers(void)
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c static void · line 719
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c +2 -0
                        }
                }
        }
 
+       /*
+        * Reset access_width in the GAS for PM1A control register
to
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 6 lines
drivers/acpi/acpica/tbfadt.c static void · line 723
Quoted 4 lines
drivers/acpi/acpica/tbfadt.c +4 -0
+        * 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 8 lines
Quoted 4 lines
7f9bef9d
Quoted 1 line
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:
Quoted 5 lines
acpi=rsdt
Or
acpi_force_32bit_fadt_addr
Or
Both
Quoted 5 lines
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.

Quoted 6 lines

[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.

Signature · 2 lines

Best regards,
Andrey Skvortsov