| Message ID | 1373888637-20737-1-git-send-email-oliver@neukum.org (mailing list archive) |
|---|---|
| State | Deferred, archived |
| Headers | show |
On Monday, July 15, 2013 01:43:57 PM oliver@neukum.org wrote: > From: Oliver Neukum <oneukum@suse.de> > > Some BIOSes change hardware based on the state of > a laptop's lid. If the lid is closed, the touchpad is > disabled and the checksum changes. Windows 8 no longer > aborts resume if the checksum has changed. I expect more machines will show up and ignore s4_hardware_signature if Windows does not check it and we should do the same. So no objections from my side. Rafael: If you agree, could you queue this one up, please? Thanks, Thomas > > Signed-off-by: Oliver Neukum <oneukum@suse.de> > --- > drivers/acpi/sleep.c | 8 +++----- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c > index 9c1a435..14744e5 100644 > --- a/drivers/acpi/sleep.c > +++ b/drivers/acpi/sleep.c > @@ -664,11 +664,9 @@ static void acpi_hibernation_leave(void) > /* Reprogram control registers */ > acpi_leave_sleep_state_prep(ACPI_STATE_S4); > /* Check the hardware signature */ > - if (facs && s4_hardware_signature != facs->hardware_signature) { > - printk(KERN_EMERG "ACPI: Hardware changed while hibernated, " > - "cannot resume!\n"); > - panic("ACPI S4 hardware signature mismatch"); > - } > + if (facs && s4_hardware_signature != facs->hardware_signature) > + printk(KERN_CRIT "ACPI: Hardware changed while hibernated, " > + "success doubtful!\n"); > /* Restore the NVS memory area */ > suspend_nvs_restore(); > /* Allow EC transactions to happen. */ -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday, July 15, 2013 01:55:56 PM Thomas Renninger wrote: > On Monday, July 15, 2013 01:43:57 PM oliver@neukum.org wrote: > > From: Oliver Neukum <oneukum@suse.de> > > > > Some BIOSes change hardware based on the state of > > a laptop's lid. If the lid is closed, the touchpad is > > disabled and the checksum changes. Windows 8 no longer > > aborts resume if the checksum has changed. > I expect more machines will show up and ignore s4_hardware_signature > if Windows does not check it and we should do the same. > > So no objections from my side. > > Rafael: If you agree, could you queue this one up, please? Yes, I'm going to do that, although for 3.11 only, not for -stable. If you need it in -stable, please send a separate inclusion request. Thanks, Rafael > > > > Signed-off-by: Oliver Neukum <oneukum@suse.de> > > --- > > drivers/acpi/sleep.c | 8 +++----- > > 1 file changed, 3 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c > > index 9c1a435..14744e5 100644 > > --- a/drivers/acpi/sleep.c > > +++ b/drivers/acpi/sleep.c > > @@ -664,11 +664,9 @@ static void acpi_hibernation_leave(void) > > /* Reprogram control registers */ > > acpi_leave_sleep_state_prep(ACPI_STATE_S4); > > /* Check the hardware signature */ > > - if (facs && s4_hardware_signature != facs->hardware_signature) { > > - printk(KERN_EMERG "ACPI: Hardware changed while hibernated, " > > - "cannot resume!\n"); > > - panic("ACPI S4 hardware signature mismatch"); > > - } > > + if (facs && s4_hardware_signature != facs->hardware_signature) > > + printk(KERN_CRIT "ACPI: Hardware changed while hibernated, " > > + "success doubtful!\n"); > > /* Restore the NVS memory area */ > > suspend_nvs_restore(); > > /* Allow EC transactions to happen. */
On Mon, 15 Jul 2013, Thomas Renninger wrote: > On Monday, July 15, 2013 01:43:57 PM oliver@neukum.org wrote: > > Some BIOSes change hardware based on the state of > > a laptop's lid. If the lid is closed, the touchpad is > > disabled and the checksum changes. Windows 8 no longer > > aborts resume if the checksum has changed. > I expect more machines will show up and ignore s4_hardware_signature > if Windows does not check it and we should do the same. Windows *8* does not check. But what about older versions? Maybe this needs to be guarded by verifying the firmware requested windows-8 mode?
On Monday, July 15, 2013 09:31:27 AM Henrique de Moraes Holschuh wrote: > On Mon, 15 Jul 2013, Thomas Renninger wrote: > > On Monday, July 15, 2013 01:43:57 PM oliver@neukum.org wrote: > > > Some BIOSes change hardware based on the state of > > > a laptop's lid. If the lid is closed, the touchpad is > > > disabled and the checksum changes. Windows 8 no longer > > > aborts resume if the checksum has changed. > > > > I expect more machines will show up and ignore s4_hardware_signature > > if Windows does not check it and we should do the same. > > Windows *8* does not check. But what about older versions? Maybe this > needs to be guarded by verifying the firmware requested windows-8 mode? I would not make it too complicated. Sticking to the latest Windows version should be enough for this one. What bad should happen if we still try to resume and fail... Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 15 Jul 2013, Thomas Renninger wrote: > On Monday, July 15, 2013 09:31:27 AM Henrique de Moraes Holschuh wrote: > > On Mon, 15 Jul 2013, Thomas Renninger wrote: > > > On Monday, July 15, 2013 01:43:57 PM oliver@neukum.org wrote: > > > > Some BIOSes change hardware based on the state of > > > > a laptop's lid. If the lid is closed, the touchpad is > > > > disabled and the checksum changes. Windows 8 no longer > > > > aborts resume if the checksum has changed. > > > > > > I expect more machines will show up and ignore s4_hardware_signature > > > if Windows does not check it and we should do the same. > > > > Windows *8* does not check. But what about older versions? Maybe this > > needs to be guarded by verifying the firmware requested windows-8 mode? > > I would not make it too complicated. > Sticking to the latest Windows version should be enough for this one. > What bad should happen if we still try to resume and fail... Hmm, why was that check added in the first place? If it is useless, removing it for good is fine. If it is _not_ useless, we should still do the checking when not operating in windows-8 firmware mode.
On Monday 15 July 2013 12:06:11 Henrique de Moraes Holschuh wrote: > On Mon, 15 Jul 2013, Thomas Renninger wrote: > > I would not make it too complicated. > > Sticking to the latest Windows version should be enough for this one. > > What bad should happen if we still try to resume and fail... > > Hmm, why was that check added in the first place? Safety. > If it is useless, > removing it for good is fine. If it is _not_ useless, we should still do > the checking when not operating in windows-8 firmware mode. Firmware will only be tested against Windows 8 pretty soon. We'd end up with a gigantic list of exceptions. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 15 Jul 2013, Oliver Neukum wrote: > On Monday 15 July 2013 12:06:11 Henrique de Moraes Holschuh wrote: > > On Mon, 15 Jul 2013, Thomas Renninger wrote: > > > I would not make it too complicated. > > > Sticking to the latest Windows version should be enough for this one. > > > What bad should happen if we still try to resume and fail... > > > > Hmm, why was that check added in the first place? > > Safety. > > > If it is useless, > > removing it for good is fine. If it is _not_ useless, we should still do > > the checking when not operating in windows-8 firmware mode. > > Firmware will only be tested against Windows 8 pretty soon. > We'd end up with a gigantic list of exceptions. No, we won't. We can query the ACPI core for the OSI compatibility level requested by the firmware, and ignore the test only for win8. We still have 10 to 15 years worth of users using non-win8 firmware boxes on x86/x86-64.
On Monday, July 15, 2013 01:34:27 PM Henrique de Moraes Holschuh wrote: > On Mon, 15 Jul 2013, Oliver Neukum wrote: > > On Monday 15 July 2013 12:06:11 Henrique de Moraes Holschuh wrote: > > > On Mon, 15 Jul 2013, Thomas Renninger wrote: > > > > I would not make it too complicated. > > > > Sticking to the latest Windows version should be enough for this one. > > > > What bad should happen if we still try to resume and fail... > > > > > > Hmm, why was that check added in the first place? > > > > Safety. > > > > > If it is useless, > > > removing it for good is fine. If it is _not_ useless, we should still do > > > the checking when not operating in windows-8 firmware mode. > > > > Firmware will only be tested against Windows 8 pretty soon. > > We'd end up with a gigantic list of exceptions. > > No, we won't. We can query the ACPI core for the OSI compatibility level > requested by the firmware, and ignore the test only for win8. > > We still have 10 to 15 years worth of users using non-win8 firmware boxes on > x86/x86-64. But what's the risk from removing the check exactly for those systems? Rafael
On Tuesday, July 16, 2013 01:56:49 AM Rafael J. Wysocki wrote: > On Monday, July 15, 2013 01:34:27 PM Henrique de Moraes Holschuh wrote: ... > > We still have 10 to 15 years worth of users using non-win8 firmware boxes > > on x86/x86-64. > > But what's the risk from removing the check exactly for those systems? Yeah, I guess this is the point. Is there a security or data corruption issue that might show up? And even if.., if you exchange HW you should do a real reboot, otherwise you have to blame yourself. The check is/was nice to at least give a hint and remember the user where the failure might have come from. But this does not work if Windows does not check for it. Maybe Windows never checked for it, but it's not worth trying out different versions, just for the sake of absolute Windows version compatibility. Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
? ??2013-07-15 ? 13:43 +0200?oliver@neukum.org ??? > From: Oliver Neukum <oneukum@suse.de> > > Some BIOSes change hardware based on the state of > a laptop's lid. If the lid is closed, the touchpad is > disabled and the checksum changes. Windows 8 no longer > aborts resume if the checksum has changed. > > Signed-off-by: Oliver Neukum <oneukum@suse.de> > --- > drivers/acpi/sleep.c | 8 +++----- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c > index 9c1a435..14744e5 100644 > --- a/drivers/acpi/sleep.c > +++ b/drivers/acpi/sleep.c > @@ -664,11 +664,9 @@ static void acpi_hibernation_leave(void) > /* Reprogram control registers */ > acpi_leave_sleep_state_prep(ACPI_STATE_S4); > /* Check the hardware signature */ > - if (facs && s4_hardware_signature != facs->hardware_signature) { > - printk(KERN_EMERG "ACPI: Hardware changed while hibernated, " > - "cannot resume!\n"); > - panic("ACPI S4 hardware signature mismatch"); > - } > + if (facs && s4_hardware_signature != facs->hardware_signature) > + printk(KERN_CRIT "ACPI: Hardware changed while hibernated, " > + "success doubtful!\n"); > /* Restore the NVS memory area */ > suspend_nvs_restore(); > /* Allow EC transactions to happen. */ This morning I tried to reproduce the hardware_signature change on my Acer notebook, I hope can monitor the change on Linux then use Windows 8 to check the behavior. Unfortunately I can not reproduce the hardware_signature change by remove memory or PCI device(wifi module) with Linux kernel. For PCI device, as ACPI spec's declare, it didn't causes hardware_signature change, I print out in acpi_hibernation_leave() to confirm it. For memory size, before the S4 resume path run to acpi_hibernation_leave(), kernel check the physical memory pages number in snapshot_write_next() then -EPERM if physical pages change . So, it doesn't have chance to check the hardware_signature changed. Base on the above testing, correct my originally thinking, the hardware_signature check could not detect the change of memory size because it's too late. Sorry for I didn't find out the actual behavior of Windows 8 to confirm it ignore hardware_signature change. At least could not verify on my machine. Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday, July 16, 2013 03:32:01 PM joeyli wrote: > ? ??2013-07-15 ? 13:43 +0200?oliver@neukum.org ??? > > From: Oliver Neukum <oneukum@suse.de> > > > > Some BIOSes change hardware based on the state of > > a laptop's lid. If the lid is closed, the touchpad is > > disabled and the checksum changes. Windows 8 no longer > > aborts resume if the checksum has changed. > > > > Signed-off-by: Oliver Neukum <oneukum@suse.de> > > --- > > drivers/acpi/sleep.c | 8 +++----- > > 1 file changed, 3 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c > > index 9c1a435..14744e5 100644 > > --- a/drivers/acpi/sleep.c > > +++ b/drivers/acpi/sleep.c > > @@ -664,11 +664,9 @@ static void acpi_hibernation_leave(void) > > /* Reprogram control registers */ > > acpi_leave_sleep_state_prep(ACPI_STATE_S4); > > /* Check the hardware signature */ > > - if (facs && s4_hardware_signature != facs->hardware_signature) { > > - printk(KERN_EMERG "ACPI: Hardware changed while hibernated, " > > - "cannot resume!\n"); > > - panic("ACPI S4 hardware signature mismatch"); > > - } > > + if (facs && s4_hardware_signature != facs->hardware_signature) > > + printk(KERN_CRIT "ACPI: Hardware changed while hibernated, " > > + "success doubtful!\n"); > > /* Restore the NVS memory area */ > > suspend_nvs_restore(); > > /* Allow EC transactions to happen. */ > > This morning I tried to reproduce the hardware_signature change on my > Acer notebook, I hope can monitor the change on Linux then use Windows 8 > to check the behavior. > Unfortunately I can not reproduce the hardware_signature change by > remove memory or PCI device(wifi module) with Linux kernel. > > For PCI device, as ACPI spec's declare, it didn't causes > hardware_signature change, I print out in acpi_hibernation_leave() to > confirm it. > > For memory size, before the S4 resume path run to > acpi_hibernation_leave(), kernel check the physical memory pages number > in snapshot_write_next() then -EPERM if physical pages change . So, it > doesn't have chance to check the hardware_signature changed. > > Base on the above testing, correct my originally thinking, the > hardware_signature check could not detect the change of memory size > because it's too late. > > Sorry for I didn't find out the actual behavior of Windows 8 to confirm > it ignore hardware_signature change. At least could not verify on my > machine. OK, so it looks like we still need somebody to confirm that indeed Windows 8 doesn't check the hardware signature during resume from hibernation, right? It is kind of important, because the *reason* for doing that change is the reported Windows 8 compatibility issue. Thanks, Rafael
On Monday, July 15, 2013 05:35:23 PM Oliver Neukum wrote: > On Monday 15 July 2013 12:06:11 Henrique de Moraes Holschuh wrote: > > On Mon, 15 Jul 2013, Thomas Renninger wrote: > > > I would not make it too complicated. > > > Sticking to the latest Windows version should be enough for this one. > > > What bad should happen if we still try to resume and fail... > > > > Hmm, why was that check added in the first place? > > Safety. I expect it is there, because it is stated rather clear in the specs. > > If it is useless, > > removing it for good is fine. If it is _not_ useless, we should still do > > the checking when not operating in windows-8 firmware mode. > > Firmware will only be tested against Windows 8 pretty soon. > We'd end up with a gigantic list of exceptions. Joey found an interessting paper about Win8 behavior: http://bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c03654081/c03654081.pdf It looks like Win8 behaves rather different compared to Linux and is providing "Hybrid Boot" where the user has to end all his apps. They have no big problem when resume fails as the user will not lose any data or work he had done before. Joey also found the rather hidden acpi_sleep=s4_nohwsig boot option which helps as well. So Linux could do: 1) Invalidate suspend image and reboot (disadvantage: message is gone) 2) Panic (current behavior) -> above boot param helps 3) Still try to resume with a "not so offending message" 4) ? 1. seem to be what Win8 is doing 3. sounds best to me. It could be ugly if suspend fails and it always worked before and all your work/data is gone. So trying hard to resume sounds like a good idea I guess this still needs some discussion? At least some facts came up already and people have an idea what happens... Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday, July 17, 2013 04:58:34 PM Thomas Renninger wrote: > On Monday, July 15, 2013 05:35:23 PM Oliver Neukum wrote: > > On Monday 15 July 2013 12:06:11 Henrique de Moraes Holschuh wrote: > > > On Mon, 15 Jul 2013, Thomas Renninger wrote: > > > > I would not make it too complicated. > > > > Sticking to the latest Windows version should be enough for this one. > > > > What bad should happen if we still try to resume and fail... > > > > > > Hmm, why was that check added in the first place? > > > > Safety. > > I expect it is there, because it is stated rather clear in the specs. > > > > If it is useless, > > > removing it for good is fine. If it is _not_ useless, we should still do > > > the checking when not operating in windows-8 firmware mode. > > > > Firmware will only be tested against Windows 8 pretty soon. > > We'd end up with a gigantic list of exceptions. > > Joey found an interessting paper about Win8 behavior: > http://bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c03654081/c03654081.pdf > > It looks like Win8 behaves rather different compared to Linux and is providing > "Hybrid Boot" where the user has to end all his apps. They have no big problem > when resume fails as the user will not lose any data or work he had done > before. > > Joey also found the rather hidden acpi_sleep=s4_nohwsig boot option > which helps as well. > So Linux could do: > 1) Invalidate suspend image and reboot (disadvantage: message is gone) > 2) Panic (current behavior) -> above boot param helps > 3) Still try to resume with a "not so offending message" > 4) ? > > 1. seem to be what Win8 is doing > 3. sounds best to me. It could be ugly if suspend fails and > it always worked before and all your work/data is gone. So trying > hard to resume sounds like a good idea We can also blacklist systems that need acpi_sleep=s4_nohwsig due to idiotic hardware/BIOS design choices. In any case, if we remove the panic, we should also drop s4_nohwsig and since we have that (which I forgot about, by bad), the whole issue isn't so urgent, so I'm dropping the patch for the time being. Thanks, Rafael
Hi all experts, ? ??2013-07-18 ? 00:09 +0200?Rafael J. Wysocki ??? > On Wednesday, July 17, 2013 04:58:34 PM Thomas Renninger wrote: > > On Monday, July 15, 2013 05:35:23 PM Oliver Neukum wrote: > > > On Monday 15 July 2013 12:06:11 Henrique de Moraes Holschuh wrote: > > > > On Mon, 15 Jul 2013, Thomas Renninger wrote: > > > > > I would not make it too complicated. > > > > > Sticking to the latest Windows version should be enough for this one. > > > > > What bad should happen if we still try to resume and fail... > > > > > > > > Hmm, why was that check added in the first place? > > > > > > Safety. > > > > I expect it is there, because it is stated rather clear in the specs. > > > > > > If it is useless, > > > > removing it for good is fine. If it is _not_ useless, we should still do > > > > the checking when not operating in windows-8 firmware mode. > > > > > > Firmware will only be tested against Windows 8 pretty soon. > > > We'd end up with a gigantic list of exceptions. > > > > Joey found an interessting paper about Win8 behavior: > > http://bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c03654081/c03654081.pdf > > > > It looks like Win8 behaves rather different compared to Linux and is providing > > "Hybrid Boot" where the user has to end all his apps. They have no big problem > > when resume fails as the user will not lose any data or work he had done > > before. > > > > Joey also found the rather hidden acpi_sleep=s4_nohwsig boot option > > which helps as well. > > So Linux could do: > > 1) Invalidate suspend image and reboot (disadvantage: message is gone) > > 2) Panic (current behavior) -> above boot param helps > > 3) Still try to resume with a "not so offending message" > > 4) ? > > > > 1. seem to be what Win8 is doing > > 3. sounds best to me. It could be ugly if suspend fails and > > it always worked before and all your work/data is gone. So trying > > hard to resume sounds like a good idea > > We can also blacklist systems that need acpi_sleep=s4_nohwsig due to idiotic > hardware/BIOS design choices. > > In any case, if we remove the panic, we should also drop s4_nohwsig and since > we have that (which I forgot about, by bad), the whole issue isn't so urgent, > so I'm dropping the patch for the time being. > > Thanks, > Rafael > > About the testing on real machine to capture the Windows behavior of hardware_signature... We confirm the behavior on fast boot and _REAL_ S4 are different on Windows. First, on Windows 8, user could not see S4 option on default UI, they need enable it in setup UI when user really want to use it. Windows 8's default shutdown is fast boot but not real S5. We found a notebook that has a buggy BIOS that changed the hardware_signature in 3 times S4 cycles. With Linux kernel, normally we can reproduced the FACS hardware signature fail at second time S4. My friend, Max Lin help to install Windows 7 and Windows 8 on this buggy machine to run S4 and fast boot testing, the result as following: + Linux v3.10 Kernel: Can reproduce error of hardware_signature changed in 3 times S4. + Windows 8 _REAL_ S4: Run more then 10 S4 cycles, always resume like normally. Didn't see any problem. + Windows 8 fast boot: Random happened blue screen as the attached picture (sorry for the chinese message), the error is: PAGE_FAULT_IN_NONPAGED_AREA. Then Windows 8 reboot and try to recover error. We are not sure this error is caused by hardware_signature changed, but it only reproduced on fast boot but not S4. + Windows 7 _REAL_ S4: Run more then 10 S4 cycles, always resume like normally. Didn't see any problem. Base on the above testing result, our conclusion is: + The _REAL_ S4 on Windows 7/8 ignored FACS hardware signature change. It just result like normally, didn't lost any user data. + The fast boot resume on Windows 8, happen blue screen, but we are not sure it reflect to FACS hardware signature change. Even that, Windows 8 didn't lost any user data because user already close all applications before fast boot shutdown. Due to Linux kernel is running REAL S4, so I suggest we can just ignore the FACS hardware signature changed, means accept Oliver's patch. Just let machine try to restore the S4 snapshot, if lucky, then user can get their user data back. Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c index 9c1a435..14744e5 100644 --- a/drivers/acpi/sleep.c +++ b/drivers/acpi/sleep.c @@ -664,11 +664,9 @@ static void acpi_hibernation_leave(void) /* Reprogram control registers */ acpi_leave_sleep_state_prep(ACPI_STATE_S4); /* Check the hardware signature */ - if (facs && s4_hardware_signature != facs->hardware_signature) { - printk(KERN_EMERG "ACPI: Hardware changed while hibernated, " - "cannot resume!\n"); - panic("ACPI S4 hardware signature mismatch"); - } + if (facs && s4_hardware_signature != facs->hardware_signature) + printk(KERN_CRIT "ACPI: Hardware changed while hibernated, " + "success doubtful!\n"); /* Restore the NVS memory area */ suspend_nvs_restore(); /* Allow EC transactions to happen. */