* acpi: broken suspend to RAM with v4.7-rc1 @ 2016-06-10 20:32 Andrey Skvortsov 2016-06-10 21:24 ` Rafael J. Wysocki 0 siblings, 1 reply; 16+ messages in thread From: Andrey Skvortsov @ 2016-06-10 20:32 UTC (permalink / raw) To: Lv Zheng, Bob Moore, Rafael J. Wysocki, linux-acpi, devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1251 bytes --] Hi, On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend to RAM. Laptop doesn't finish suspend to RAM process (disks are off, but WiFi and Power LEDs are still on). The only way to get it out of this state, is to turn the power off. I've bisected the issue to commit 66b1ed5aa8dd25 [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()]. If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to RAM is working again. The cause of this problem is that after this commit write to PM1A Control Block (16-bit register) is done using two 8-bit writes. If I force this write to be 16-bit, then all is working as before. To get it working 'access_width' for PM1A Control Block needs to be 2 (16-bit), but it's 1 (8-bit). The root of the problem seems to be not the commit 66b1ed5aa8dd25 itself, but the ACPI tables in BIOS where wrong access_width comes from. I fixed problem in FACP table, put it in initrd to override FACP table from BIOS. This fixed the issue, suspend to RAM is working now again. But I'm not sure whether is this proper fix for this problem. Is there any place in the kernel, where such ACPI quirks are placed? -- Best regards, Andrey Skvortsov [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: acpi: broken suspend to RAM with v4.7-rc1 2016-06-10 20:32 acpi: broken suspend to RAM with v4.7-rc1 Andrey Skvortsov @ 2016-06-10 21:24 ` Rafael J. Wysocki 2016-06-11 10:49 ` Andrey Skvortsov 0 siblings, 1 reply; 16+ messages in thread From: Rafael J. Wysocki @ 2016-06-10 21:24 UTC (permalink / raw) To: Andrey Skvortsov Cc: Lv Zheng, Bob Moore, Rafael J. Wysocki, linux-acpi, devel, linux-kernel On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > > --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. > > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: acpi: broken suspend to RAM with v4.7-rc1 2016-06-10 21:24 ` Rafael J. Wysocki @ 2016-06-11 10:49 ` Andrey Skvortsov 2016-06-11 11:56 ` Rafael J. Wysocki 0 siblings, 1 reply; 16+ messages in thread From: Andrey Skvortsov @ 2016-06-11 10:49 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Lv Zheng, Bob Moore, Rafael J. Wysocki, linux-acpi, devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2398 bytes --] On 10 Jun, Rafael J. Wysocki wrote: > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > > Hi, > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend to RAM. > > Laptop doesn't finish suspend to RAM process (disks are off, but WiFi > > and Power LEDs are still on). The only way to get it out of this > > state, is to turn the power off. > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_h= > > w_write()]. > > > > If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to RAM is > > working again. > > > > The cause of this problem is that after this commit write to PM1A Control B= > > lock > > (16-bit register) is done using two 8-bit writes. If I force this write > > to be 16-bit, then all is working as before. > > > > To get it working 'access_width' for PM1A Control Block needs to be 2 (16-b= > > it), but it's=20 > > 1 (8-bit). > > > > The root of the problem seems to be not the commit 66b1ed5aa8dd25 itself, b= > > ut the ACPI > > tables in BIOS where wrong access_width comes from. I fixed problem in FACP= > > table, > > put it in initrd to override FACP table from BIOS. This fixed the issue, > > suspend to RAM is working now again. > > > > But I'm not sure whether is this proper fix for this problem. > > Is there any place in the kernel, where such ACPI quirks are placed? > > Well, if the commit in question caused a problem to happen for you, it also > might cause similar problems to happen elsewhere. > > It looks like we'll need to revert that commit. Hi, or maybe to reset access_width AnyAcc from FACP table only for PM1A control register or even for all registers? This will fix the issue too. diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644 --- a/drivers/acpi/acpica/tbfadt.c +++ b/drivers/acpi/acpica/tbfadt.c @@ -714,7 +714,14 @@ static void acpi_tb_setup_fadt_registers(void) } } } + /* + * Reset access_width in the GAS for PM1A control register to + * undefined value. Because in some cases this field contains + * wrong value. + */ + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; -- Best regards, Andrey Skvortsov [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: acpi: broken suspend to RAM with v4.7-rc1 2016-06-11 10:49 ` Andrey Skvortsov @ 2016-06-11 11:56 ` Rafael J. Wysocki [not found] ` <744357E9AAD1214791ACBA4B0B9092633AA54819@SHSMSX101.ccr.corp.intel.com> 0 siblings, 1 reply; 16+ messages in thread From: Rafael J. Wysocki @ 2016-06-11 11:56 UTC (permalink / raw) To: Andrey Skvortsov Cc: Lv Zheng, Bob Moore, Rafael J. Wysocki, linux-acpi, devel, linux-kernel, Bob Moore [-- Attachment #1: Type: text/plain, Size: 2551 bytes --] On Saturday, June 11, 2016 01:49:22 PM Andrey Skvortsov wrote: > On 10 Jun, Rafael J. Wysocki wrote: > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > > > Hi, > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend to RAM. > > > Laptop doesn't finish suspend to RAM process (disks are off, but WiFi > > > and Power LEDs are still on). The only way to get it out of this > > > state, is to turn the power off. > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_h= > > > w_write()]. > > > > > > If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to RAM is > > > working again. > > > > > > The cause of this problem is that after this commit write to PM1A Control B= > > > lock > > > (16-bit register) is done using two 8-bit writes. If I force this write > > > to be 16-bit, then all is working as before. > > > > > > To get it working 'access_width' for PM1A Control Block needs to be 2 (16-b= > > > it), but it's=20 > > > 1 (8-bit). > > > > > > The root of the problem seems to be not the commit 66b1ed5aa8dd25 itself, b= > > > ut the ACPI > > > tables in BIOS where wrong access_width comes from. I fixed problem in FACP= > > > table, > > > put it in initrd to override FACP table from BIOS. This fixed the issue, > > > suspend to RAM is working now again. > > > > > > But I'm not sure whether is this proper fix for this problem. > > > Is there any place in the kernel, where such ACPI quirks are placed? > > > > Well, if the commit in question caused a problem to happen for you, it also > > might cause similar problems to happen elsewhere. > > > > It looks like we'll need to revert that commit. > Hi, > > or maybe to reset access_width AnyAcc from FACP table only for PM1A control > register or even for all registers? This will fix the issue too. That's a good idea actually. > diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c > index 6208069..a476e94 100644 > --- a/drivers/acpi/acpica/tbfadt.c > +++ b/drivers/acpi/acpica/tbfadt.c > @@ -714,7 +714,14 @@ static void acpi_tb_setup_fadt_registers(void) > } > } > } > > + /* > + * Reset access_width in the GAS for PM1A control register to > + * undefined value. Because in some cases this field contains > + * wrong value. > + */ > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; OK, let's see what Bob and Lv think about that. [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <744357E9AAD1214791ACBA4B0B9092633AA54819@SHSMSX101.ccr.corp.intel.com>]
* RE: acpi: broken suspend to RAM with v4.7-rc1 [not found] ` <744357E9AAD1214791ACBA4B0B9092633AA54819@SHSMSX101.ccr.corp.intel.com> @ 2016-06-13 8:50 ` Zheng, Lv 2016-06-13 10:07 ` Andrey Skvortsov 0 siblings, 1 reply; 16+ messages in thread From: Zheng, Lv @ 2016-06-13 8:50 UTC (permalink / raw) To: Andrey Skvortsov Cc: Moore, Robert, Wysocki, Rafael J, linux-acpi, devel, linux-kernel Hi, Andrey > 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: > > On 10 Jun, Rafael J. Wysocki wrote: > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > > > > Hi, > > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend to RAM. > > > > Laptop doesn't finish suspend to RAM process (disks are off, but > > > > WiFi and Power LEDs are still on). The only way to get it out of > > > > this state, is to turn the power off. > > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support > > > > for acpi_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? > > > > > > > > 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? [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 > > > > > > Well, if the commit in question caused a problem to happen for you, > > > it also might cause similar problems to happen elsewhere. > > > > > > It looks like we'll need to revert that commit. > > Hi, > > > > or maybe to reset access_width AnyAcc from FACP table only for PM1A > > control register or even for all registers? This will fix the issue too. > > That's a good idea actually. > > > diff --git a/drivers/acpi/acpica/tbfadt.c > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644 > > --- a/drivers/acpi/acpica/tbfadt.c > > +++ b/drivers/acpi/acpica/tbfadt.c > > @@ -714,7 +714,14 @@ static void acpi_tb_setup_fadt_registers(void) > > } > > } > > } > > > > + /* > > + * Reset access_width in the GAS for PM1A control register to > > + * undefined value. Because in some cases this field contains > > + * wrong value. > > + */ > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; > > OK, let's see what Bob and Lv think about that. [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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: acpi: broken suspend to RAM with v4.7-rc1 2016-06-13 8:50 ` Zheng, Lv @ 2016-06-13 10:07 ` Andrey Skvortsov 2016-06-15 0:24 ` Rafael J. Wysocki 2016-06-24 1:02 ` Zheng, Lv 0 siblings, 2 replies; 16+ messages in thread From: Andrey Skvortsov @ 2016-06-13 10:07 UTC (permalink / raw) To: Zheng, Lv Cc: Moore, Robert, Wysocki, Rafael J, linux-acpi, devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 3946 bytes --] Hi Lv, On 13 Jun, Zheng, Lv wrote: > > 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: > > > On 10 Jun, Rafael J. Wysocki wrote: > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > > > > > Hi, > > > > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend to RAM. > > > > > Laptop doesn't finish suspend to RAM process (disks are off, but > > > > > WiFi and Power LEDs are still on). The only way to get it out of > > > > > this state, is to turn the power off. > > > > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support > > > > > for acpi_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? Here it is https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpidump.bin > > > > > > > > > > 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? > [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. > 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 > > > > > > > > > Well, if the commit in question caused a problem to happen for you, > > > > it also might cause similar problems to happen elsewhere. > > > > > > > > It looks like we'll need to revert that commit. > > > Hi, > > > > > > or maybe to reset access_width AnyAcc from FACP table only for PM1A > > > control register or even for all registers? This will fix the issue too. > > > > That's a good idea actually. > > > > > diff --git a/drivers/acpi/acpica/tbfadt.c > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644 > > > --- a/drivers/acpi/acpica/tbfadt.c > > > +++ b/drivers/acpi/acpica/tbfadt.c > > > @@ -714,7 +714,14 @@ static void acpi_tb_setup_fadt_registers(void) > > > } > > > } > > > } > > > > > > + /* > > > + * Reset access_width in the GAS for PM1A control register to > > > + * undefined value. Because in some cases this field contains > > > + * wrong value. > > > + */ > > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; > > > > OK, let's see what Bob and Lv think about that. > [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. -- Best regards, Andrey Skvortsov [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: acpi: broken suspend to RAM with v4.7-rc1 2016-06-13 10:07 ` Andrey Skvortsov @ 2016-06-15 0:24 ` Rafael J. Wysocki 2016-06-15 6:05 ` Zheng, Lv 2016-06-24 1:02 ` Zheng, Lv 1 sibling, 1 reply; 16+ messages in thread From: Rafael J. Wysocki @ 2016-06-15 0:24 UTC (permalink / raw) To: Andrey Skvortsov, Zheng, Lv, Moore, Robert, Wysocki, Rafael J, linux-acpi, devel, linux-kernel On Mon, Jun 13, 2016 at 12:07 PM, Andrey Skvortsov <andrej.skvortzov@gmail.com> wrote: > Hi Lv, > > On 13 Jun, Zheng, Lv wrote: >> > 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: >> > > On 10 Jun, Rafael J. Wysocki wrote: >> > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: >> > > > > Hi, >> > > > > >> > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend to RAM. >> > > > > Laptop doesn't finish suspend to RAM process (disks are off, but >> > > > > WiFi and Power LEDs are still on). The only way to get it out of >> > > > > this state, is to turn the power off. >> > > > > >> > > > > I've bisected the issue to commit 66b1ed5aa8dd25 >> > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support >> > > > > for acpi_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? > Here it is > https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpidump.bin > >> > > > > >> > > > > 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? >> [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. > >> 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 >> >> > > > >> > > > Well, if the commit in question caused a problem to happen for you, >> > > > it also might cause similar problems to happen elsewhere. >> > > > >> > > > It looks like we'll need to revert that commit. >> > > Hi, >> > > >> > > or maybe to reset access_width AnyAcc from FACP table only for PM1A >> > > control register or even for all registers? This will fix the issue too. >> > >> > That's a good idea actually. >> > >> > > diff --git a/drivers/acpi/acpica/tbfadt.c >> > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644 >> > > --- a/drivers/acpi/acpica/tbfadt.c >> > > +++ b/drivers/acpi/acpica/tbfadt.c >> > > @@ -714,7 +714,14 @@ static void acpi_tb_setup_fadt_registers(void) >> > > } >> > > } >> > > } >> > > >> > > + /* >> > > + * Reset access_width in the GAS for PM1A control register to >> > > + * undefined value. Because in some cases this field contains >> > > + * wrong value. >> > > + */ >> > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; >> > >> > OK, let's see what Bob and Lv think about that. >> [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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: acpi: broken suspend to RAM with v4.7-rc1 2016-06-15 0:24 ` Rafael J. Wysocki @ 2016-06-15 6:05 ` Zheng, Lv 2016-06-15 20:02 ` Andrey Skvortsov 0 siblings, 1 reply; 16+ messages in thread From: Zheng, Lv @ 2016-06-15 6:05 UTC (permalink / raw) To: Rafael J. Wysocki, Andrey Skvortsov, Moore, Robert, Wysocki, Rafael J, linux-acpi, devel, linux-kernel Hi, Rafael > From: rjwysocki@gmail.com [mailto:rjwysocki@gmail.com] On Behalf Of > Rafael J. Wysocki > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1 > > On Mon, Jun 13, 2016 at 12:07 PM, Andrey Skvortsov > <andrej.skvortzov@gmail.com> wrote: > > Hi Lv, > > > > On 13 Jun, Zheng, Lv wrote: > >> > 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: > >> > > On 10 Jun, Rafael J. Wysocki wrote: > >> > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > >> > > > > Hi, > >> > > > > > >> > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend > to RAM. > >> > > > > Laptop doesn't finish suspend to RAM process (disks are off, but > >> > > > > WiFi and Power LEDs are still on). The only way to get it out of > >> > > > > this state, is to turn the power off. > >> > > > > > >> > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > >> > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset > support > >> > > > > for acpi_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? > > Here it is > > > https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpid > ump.bin > > > >> > > > > > >> > > > > 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? > >> [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. > > > >> 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 > >> > >> > > > > >> > > > Well, if the commit in question caused a problem to happen for > you, > >> > > > it also might cause similar problems to happen elsewhere. > >> > > > > >> > > > It looks like we'll need to revert that commit. > >> > > Hi, > >> > > > >> > > or maybe to reset access_width AnyAcc from FACP table only for > PM1A > >> > > control register or even for all registers? This will fix the issue too. > >> > > >> > That's a good idea actually. > >> > > >> > > diff --git a/drivers/acpi/acpica/tbfadt.c > >> > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644 > >> > > --- a/drivers/acpi/acpica/tbfadt.c > >> > > +++ b/drivers/acpi/acpica/tbfadt.c > >> > > @@ -714,7 +714,14 @@ static void > acpi_tb_setup_fadt_registers(void) > >> > > } > >> > > } > >> > > } > >> > > > >> > > + /* > >> > > + * Reset access_width in the GAS for PM1A control register to > >> > > + * undefined value. Because in some cases this field contains > >> > > + * wrong value. > >> > > + */ > >> > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; > >> > > >> > OK, let's see what Bob and Lv think about that. > >> [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. [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 > > Thanks, > Rafael ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: acpi: broken suspend to RAM with v4.7-rc1 2016-06-15 6:05 ` Zheng, Lv @ 2016-06-15 20:02 ` Andrey Skvortsov 0 siblings, 0 replies; 16+ messages in thread From: Andrey Skvortsov @ 2016-06-15 20:02 UTC (permalink / raw) To: Zheng, Lv Cc: Rafael J. Wysocki, Moore, Robert, Wysocki, Rafael J, linux-acpi, devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 18658 bytes --] On 15 Jun, Zheng, Lv wrote: > Hi, Rafael > > > From: rjwysocki@gmail.com [mailto:rjwysocki@gmail.com] On Behalf Of > > Rafael J. Wysocki > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1 > > > > On Mon, Jun 13, 2016 at 12:07 PM, Andrey Skvortsov > > <andrej.skvortzov@gmail.com> wrote: > > > Hi Lv, > > > > > > On 13 Jun, Zheng, Lv wrote: > > >> > 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: > > >> > > On 10 Jun, Rafael J. Wysocki wrote: > > >> > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > > >> > > > > Hi, > > >> > > > > > > >> > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend > > to RAM. > > >> > > > > Laptop doesn't finish suspend to RAM process (disks are off, but > > >> > > > > WiFi and Power LEDs are still on). The only way to get it out of > > >> > > > > this state, is to turn the power off. > > >> > > > > > > >> > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > > >> > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset > > support > > >> > > > > for acpi_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? > > > Here it is > > > > > https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpid > > ump.bin > > > > > >> > > > > > > >> > > > > 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? > > >> [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. > > > > > >> 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 > > >> > > >> > > > > > >> > > > Well, if the commit in question caused a problem to happen for > > you, > > >> > > > it also might cause similar problems to happen elsewhere. > > >> > > > > > >> > > > It looks like we'll need to revert that commit. > > >> > > Hi, > > >> > > > > >> > > or maybe to reset access_width AnyAcc from FACP table only for > > PM1A > > >> > > control register or even for all registers? This will fix the issue too. > > >> > > > >> > That's a good idea actually. > > >> > > > >> > > diff --git a/drivers/acpi/acpica/tbfadt.c > > >> > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644 > > >> > > --- a/drivers/acpi/acpica/tbfadt.c > > >> > > +++ b/drivers/acpi/acpica/tbfadt.c > > >> > > @@ -714,7 +714,14 @@ static void > > acpi_tb_setup_fadt_registers(void) > > >> > > } > > >> > > } > > >> > > } > > >> > > > > >> > > + /* > > >> > > + * Reset access_width in the GAS for PM1A control register to > > >> > > + * undefined value. Because in some cases this field contains > > >> > > + * wrong value. > > >> > > + */ > > >> > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; > > >> > > > >> > OK, let's see what Bob and Lv think about that. > > >> [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. > [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? > 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 -- Best regards, Andrey Skvortsov [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: acpi: broken suspend to RAM with v4.7-rc1 2016-06-13 10:07 ` Andrey Skvortsov 2016-06-15 0:24 ` Rafael J. Wysocki @ 2016-06-24 1:02 ` Zheng, Lv 2016-06-24 21:32 ` Andrey Skvortsov 1 sibling, 1 reply; 16+ messages in thread From: Zheng, Lv @ 2016-06-24 1:02 UTC (permalink / raw) To: Andrey Skvortsov Cc: Moore, Robert, Wysocki, Rafael J, linux-acpi, devel, linux-kernel Hi, > 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: > > > 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: > > > > On 10 Jun, Rafael J. Wysocki wrote: > > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > > > > > > Hi, > > > > > > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend > to RAM. > > > > > > Laptop doesn't finish suspend to RAM process (disks are off, but > > > > > > WiFi and Power LEDs are still on). The only way to get it out of > > > > > > this state, is to turn the power off. > > > > > > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > > > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset > support > > > > > > for acpi_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? > 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? > > > > > > > > > > > > > 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? > > [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. > > > 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 > > > > > > > > > > > > Well, if the commit in question caused a problem to happen for > you, > > > > > it also might cause similar problems to happen elsewhere. > > > > > > > > > > It looks like we'll need to revert that commit. > > > > Hi, > > > > > > > > or maybe to reset access_width AnyAcc from FACP table only for > PM1A > > > > control register or even for all registers? This will fix the issue too. > > > > > > That's a good idea actually. > > > > > > > diff --git a/drivers/acpi/acpica/tbfadt.c > > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644 > > > > --- a/drivers/acpi/acpica/tbfadt.c > > > > +++ b/drivers/acpi/acpica/tbfadt.c > > > > @@ -714,7 +714,14 @@ static void > acpi_tb_setup_fadt_registers(void) > > > > } > > > > } > > > > } > > > > > > > > + /* > > > > + * Reset access_width in the GAS for PM1A control register to > > > > + * undefined value. Because in some cases this field contains > > > > + * wrong value. > > > > + */ > > > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; > > > > > > OK, let's see what Bob and Lv think about that. > > [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. [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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: acpi: broken suspend to RAM with v4.7-rc1 2016-06-24 1:02 ` Zheng, Lv @ 2016-06-24 21:32 ` Andrey Skvortsov 2016-06-27 1:17 ` Zheng, Lv 2016-08-05 1:06 ` Zheng, Lv 0 siblings, 2 replies; 16+ messages in thread From: Andrey Skvortsov @ 2016-06-24 21:32 UTC (permalink / raw) To: Zheng, Lv Cc: Moore, Robert, Wysocki, Rafael J, linux-acpi, devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 5427 bytes --] On 24 Jun, Zheng, Lv wrote: > Hi, > > > 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: > > > > 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: > > > > > On 10 Jun, Rafael J. Wysocki wrote: > > > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend > > to RAM. > > > > > > > Laptop doesn't finish suspend to RAM process (disks are off, but > > > > > > > WiFi and Power LEDs are still on). The only way to get it out of > > > > > > > this state, is to turn the power off. > > > > > > > > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > > > > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset > > support > > > > > > > for acpi_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? > > 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. > > > > > > > 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? > > > [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. > > > > > 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 > > > > > > > > > > > > > > > Well, if the commit in question caused a problem to happen for > > you, > > > > > > it also might cause similar problems to happen elsewhere. > > > > > > > > > > > > It looks like we'll need to revert that commit. > > > > > Hi, > > > > > > > > > > or maybe to reset access_width AnyAcc from FACP table only for > > PM1A > > > > > control register or even for all registers? This will fix the issue too. > > > > > > > > That's a good idea actually. > > > > > > > > > diff --git a/drivers/acpi/acpica/tbfadt.c > > > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644 > > > > > --- a/drivers/acpi/acpica/tbfadt.c > > > > > +++ b/drivers/acpi/acpica/tbfadt.c > > > > > @@ -714,7 +714,14 @@ static void > > acpi_tb_setup_fadt_registers(void) > > > > > } > > > > > } > > > > > } > > > > > > > > > > + /* > > > > > + * Reset access_width in the GAS for PM1A control register to > > > > > + * undefined value. Because in some cases this field contains > > > > > + * wrong value. > > > > > + */ > > > > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; > > > > > > > > OK, let's see what Bob and Lv think about that. > > > [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. > [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. 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: acpi: broken suspend to RAM with v4.7-rc1 2016-06-24 21:32 ` Andrey Skvortsov @ 2016-06-27 1:17 ` Zheng, Lv 2016-06-27 8:49 ` Andrey Skvortsov 2016-08-05 1:06 ` Zheng, Lv 1 sibling, 1 reply; 16+ messages in thread From: Zheng, Lv @ 2016-06-27 1:17 UTC (permalink / raw) To: Andrey Skvortsov Cc: Moore, Robert, Wysocki, Rafael J, linux-acpi, devel, linux-kernel Hi, > 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: > > Hi, > > > > > 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: > > > > > 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: > > > > > > On 10 Jun, Rafael J. Wysocki wrote: > > > > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken > suspend > > > to RAM. > > > > > > > > Laptop doesn't finish suspend to RAM process (disks are off, > but > > > > > > > > WiFi and Power LEDs are still on). The only way to get it out of > > > > > > > > this state, is to turn the power off. > > > > > > > > > > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > > > > > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset > > > support > > > > > > > > for acpi_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? > > > 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. [Lv Zheng] Maybe this is just because of ISP firewall. > Anyway I resend you all files off-list. [Lv Zheng] Great! > > > > > > > > > > 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? > > > > [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. > > > > > > > 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 > > > > > > > > > > > > > > > > > > Well, if the commit in question caused a problem to happen for > > > you, > > > > > > > it also might cause similar problems to happen elsewhere. > > > > > > > > > > > > > > It looks like we'll need to revert that commit. > > > > > > Hi, > > > > > > > > > > > > or maybe to reset access_width AnyAcc from FACP table only for > > > PM1A > > > > > > control register or even for all registers? This will fix the issue too. > > > > > > > > > > That's a good idea actually. > > > > > > > > > > > diff --git a/drivers/acpi/acpica/tbfadt.c > > > > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644 > > > > > > --- a/drivers/acpi/acpica/tbfadt.c > > > > > > +++ b/drivers/acpi/acpica/tbfadt.c > > > > > > @@ -714,7 +714,14 @@ static void > > > acpi_tb_setup_fadt_registers(void) > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > + /* > > > > > > + * Reset access_width in the GAS for PM1A control register > to > > > > > > + * undefined value. Because in some cases this field contains > > > > > > + * wrong value. > > > > > > + */ > > > > > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; > > > > > > > > > > OK, let's see what Bob and Lv think about that. > > > > [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. > > [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. > > 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. > > > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: acpi: broken suspend to RAM with v4.7-rc1 2016-06-27 1:17 ` Zheng, Lv @ 2016-06-27 8:49 ` Andrey Skvortsov 2016-06-28 5:10 ` Zheng, Lv 0 siblings, 1 reply; 16+ messages in thread From: Andrey Skvortsov @ 2016-06-27 8:49 UTC (permalink / raw) To: Zheng, Lv Cc: Moore, Robert, Wysocki, Rafael J, linux-acpi, devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 7719 bytes --] On 27 Jun, Zheng, Lv wrote: > Hi, > > > 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: > > > Hi, > > > > > > > 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: > > > > > > 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: > > > > > > > On 10 Jun, Rafael J. Wysocki wrote: > > > > > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken > > suspend > > > > to RAM. > > > > > > > > > Laptop doesn't finish suspend to RAM process (disks are off, > > but > > > > > > > > > WiFi and Power LEDs are still on). The only way to get it out of > > > > > > > > > this state, is to turn the power off. > > > > > > > > > > > > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > > > > > > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset > > > > support > > > > > > > > > for acpi_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? > > > > 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. > [Lv Zheng] > Maybe this is just because of ISP firewall. > > > Anyway I resend you all files off-list. > [Lv Zheng] > Great! > > > > > > > > > > > > > > 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? > > > > > [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. > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > Well, if the commit in question caused a problem to happen for > > > > you, > > > > > > > > it also might cause similar problems to happen elsewhere. > > > > > > > > > > > > > > > > It looks like we'll need to revert that commit. > > > > > > > Hi, > > > > > > > > > > > > > > or maybe to reset access_width AnyAcc from FACP table only for > > > > PM1A > > > > > > > control register or even for all registers? This will fix the issue too. > > > > > > > > > > > > That's a good idea actually. > > > > > > > > > > > > > diff --git a/drivers/acpi/acpica/tbfadt.c > > > > > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644 > > > > > > > --- a/drivers/acpi/acpica/tbfadt.c > > > > > > > +++ b/drivers/acpi/acpica/tbfadt.c > > > > > > > @@ -714,7 +714,14 @@ static void > > > > acpi_tb_setup_fadt_registers(void) > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > + /* > > > > > > > + * Reset access_width in the GAS for PM1A control register > > to > > > > > > > + * undefined value. Because in some cases this field contains > > > > > > > + * wrong value. > > > > > > > + */ > > > > > > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; > > > > > > > > > > > > OK, let's see what Bob and Lv think about that. > > > > > [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. > > > [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. > > > > 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. > > 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. -- Best regards, Andrey Skvortsov [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: acpi: broken suspend to RAM with v4.7-rc1 2016-06-27 8:49 ` Andrey Skvortsov @ 2016-06-28 5:10 ` Zheng, Lv 0 siblings, 0 replies; 16+ messages in thread From: Zheng, Lv @ 2016-06-28 5:10 UTC (permalink / raw) To: Andrey Skvortsov Cc: Moore, Robert, Wysocki, Rafael J, linux-acpi, devel, linux-kernel Hi, > From: Andrey Skvortsov [mailto:andrej.skvortzov@gmail.com] > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1 > > On 27 Jun, Zheng, Lv wrote: > > Hi, > > > > > 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: > > > > Hi, > > > > > > > > > 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: > > > > > > > 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: > > > > > > > > On 10 Jun, Rafael J. Wysocki wrote: > > > > > > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov > wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken > > > suspend > > > > > to RAM. > > > > > > > > > > Laptop doesn't finish suspend to RAM process (disks are > off, > > > but > > > > > > > > > > WiFi and Power LEDs are still on). The only way to get it > out of > > > > > > > > > > this state, is to turn the power off. > > > > > > > > > > > > > > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > > > > > > > > > > [ACPICA: ACPI 2.0, Hardware: Add > access_width/bit_offset > > > > > support > > > > > > > > > > for acpi_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? > > > > > 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. > > [Lv Zheng] > > Maybe this is just because of ISP firewall. > > > > > Anyway I resend you all files off-list. > > [Lv Zheng] > > Great! > > > > > > > > > > > > > > > > > > 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? > > > > > > [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. > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > Well, if the commit in question caused a problem to happen > for > > > > > you, > > > > > > > > > it also might cause similar problems to happen elsewhere. > > > > > > > > > > > > > > > > > > It looks like we'll need to revert that commit. > > > > > > > > Hi, > > > > > > > > > > > > > > > > or maybe to reset access_width AnyAcc from FACP table only > for > > > > > PM1A > > > > > > > > control register or even for all registers? This will fix the issue > too. > > > > > > > > > > > > > > That's a good idea actually. > > > > > > > > > > > > > > > diff --git a/drivers/acpi/acpica/tbfadt.c > > > > > > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 > 100644 > > > > > > > > --- a/drivers/acpi/acpica/tbfadt.c > > > > > > > > +++ b/drivers/acpi/acpica/tbfadt.c > > > > > > > > @@ -714,7 +714,14 @@ static void > > > > > acpi_tb_setup_fadt_registers(void) > > > > > > > > } > > > > > > > > } > > > > > > > > } > > > > > > > > > > > > > > > > + /* > > > > > > > > + * Reset access_width in the GAS for PM1A control > register > > > to > > > > > > > > + * undefined value. Because in some cases this field > contains > > > > > > > > + * wrong value. > > > > > > > > + */ > > > > > > > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; > > > > > > > > > > > > > > OK, let's see what Bob and Lv think about that. > > > > > > [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. > > > > [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. > > > > > > 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. > > > > > 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. [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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: acpi: broken suspend to RAM with v4.7-rc1 2016-06-24 21:32 ` Andrey Skvortsov 2016-06-27 1:17 ` Zheng, Lv @ 2016-08-05 1:06 ` Zheng, Lv 2016-08-10 17:51 ` Andrey Skvortsov 1 sibling, 1 reply; 16+ messages in thread From: Zheng, Lv @ 2016-08-05 1:06 UTC (permalink / raw) To: Andrey Skvortsov Cc: Moore, Robert, Wysocki, Rafael J, linux-acpi, devel, linux-kernel Hi, Andrey > 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: > > Hi, > > > > > 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: > > > > > 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: > > > > > > On 10 Jun, Rafael J. Wysocki wrote: > > > > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken > suspend > > > to RAM. > > > > > > > > Laptop doesn't finish suspend to RAM process (disks are off, > but > > > > > > > > WiFi and Power LEDs are still on). The only way to get it out of > > > > > > > > this state, is to turn the power off. > > > > > > > > > > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > > > > > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset > > > support > > > > > > > > for acpi_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? > > > 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. > > > > > > > > > > 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? > > > > [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. > > > > > > > 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 > > > > > > > > > > > > > > > > > > Well, if the commit in question caused a problem to happen for > > > you, > > > > > > > it also might cause similar problems to happen elsewhere. > > > > > > > > > > > > > > It looks like we'll need to revert that commit. > > > > > > Hi, > > > > > > > > > > > > or maybe to reset access_width AnyAcc from FACP table only for > > > PM1A > > > > > > control register or even for all registers? This will fix the issue too. > > > > > > > > > > That's a good idea actually. > > > > > > > > > > > diff --git a/drivers/acpi/acpica/tbfadt.c > > > > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644 > > > > > > --- a/drivers/acpi/acpica/tbfadt.c > > > > > > +++ b/drivers/acpi/acpica/tbfadt.c > > > > > > @@ -714,7 +714,14 @@ static void > > > acpi_tb_setup_fadt_registers(void) > > > > > > } > > > > > > } > > > > > > } > > > > > > > > > > > > + /* > > > > > > + * Reset access_width in the GAS for PM1A control register > to > > > > > > + * undefined value. Because in some cases this field contains > > > > > > + * wrong value. > > > > > > + */ > > > > > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; > > > > > > > > > > OK, let's see what Bob and Lv think about that. > > > > [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. > > [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 Thanks in advance. Best regards Lv > > 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 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: acpi: broken suspend to RAM with v4.7-rc1 2016-08-05 1:06 ` Zheng, Lv @ 2016-08-10 17:51 ` Andrey Skvortsov 0 siblings, 0 replies; 16+ messages in thread From: Andrey Skvortsov @ 2016-08-10 17:51 UTC (permalink / raw) To: Zheng, Lv Cc: Moore, Robert, Wysocki, Rafael J, linux-acpi, devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 6340 bytes --] On 05 Aug, Zheng, Lv wrote: > Hi, Andrey > > > 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: > > > Hi, > > > > > > > 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: > > > > > > 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: > > > > > > > On 10 Jun, Rafael J. Wysocki wrote: > > > > > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken > > suspend > > > > to RAM. > > > > > > > > > Laptop doesn't finish suspend to RAM process (disks are off, > > but > > > > > > > > > WiFi and Power LEDs are still on). The only way to get it out of > > > > > > > > > this state, is to turn the power off. > > > > > > > > > > > > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25 > > > > > > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset > > > > support > > > > > > > > > for acpi_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? > > > > 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. > > > > > > > > > > > > > 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? > > > > > [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. > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > Well, if the commit in question caused a problem to happen for > > > > you, > > > > > > > > it also might cause similar problems to happen elsewhere. > > > > > > > > > > > > > > > > It looks like we'll need to revert that commit. > > > > > > > Hi, > > > > > > > > > > > > > > or maybe to reset access_width AnyAcc from FACP table only for > > > > PM1A > > > > > > > control register or even for all registers? This will fix the issue too. > > > > > > > > > > > > That's a good idea actually. > > > > > > > > > > > > > diff --git a/drivers/acpi/acpica/tbfadt.c > > > > > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644 > > > > > > > --- a/drivers/acpi/acpica/tbfadt.c > > > > > > > +++ b/drivers/acpi/acpica/tbfadt.c > > > > > > > @@ -714,7 +714,14 @@ static void > > > > acpi_tb_setup_fadt_registers(void) > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > + /* > > > > > > > + * Reset access_width in the GAS for PM1A control register > > to > > > > > > > + * undefined value. Because in some cases this field contains > > > > > > > + * wrong value. > > > > > > > + */ > > > > > > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0; > > > > > > > > > > > > OK, let's see what Bob and Lv think about that. > > > > > [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. > > > [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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2016-08-10 20:43 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-10 20:32 acpi: broken suspend to RAM with v4.7-rc1 Andrey Skvortsov 2016-06-10 21:24 ` Rafael J. Wysocki 2016-06-11 10:49 ` Andrey Skvortsov 2016-06-11 11:56 ` Rafael J. Wysocki [not found] ` <744357E9AAD1214791ACBA4B0B9092633AA54819@SHSMSX101.ccr.corp.intel.com> 2016-06-13 8:50 ` Zheng, Lv 2016-06-13 10:07 ` Andrey Skvortsov 2016-06-15 0:24 ` Rafael J. Wysocki 2016-06-15 6:05 ` Zheng, Lv 2016-06-15 20:02 ` Andrey Skvortsov 2016-06-24 1:02 ` Zheng, Lv 2016-06-24 21:32 ` Andrey Skvortsov 2016-06-27 1:17 ` Zheng, Lv 2016-06-27 8:49 ` Andrey Skvortsov 2016-06-28 5:10 ` Zheng, Lv 2016-08-05 1:06 ` Zheng, Lv 2016-08-10 17:51 ` Andrey Skvortsov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).