Bug 189431

What does "on second attempt" mean, exactly?
Does this mean that you can suspend and resume once and it works?

Is it possible for you to try an older BIOS to confirm that this issue is related to the BIOS patch?

Is it possible to identify, via git-bisect, what in Linux changed between 3.16 and 3.17 that causes it to run into this failure?

Thanks fo the reply.

"On second attempt" means that first suspend via "systemctl suspend" is working as expected (hdd is off, power(online) led is blinking, screen is off, fan is off - coputer is suspended), machine after that resumes olso without any problems, but when laptop is resumed and I try to repeat "systemctl suspend" command, then it is trying to suspend as normal, but it takes little more time (1-3s) to see message (yellow bright text) from UEFI firmware on screen saying: "Warning!!! Boot script table is modified. Please contact your vendor.", and laptop boots as to be just powered on. During second process hdd doesnt turning off, power led doesnt blinking (it is "on" whole the time as laptop was to be online), fan is on, and backlight is on. After displaing the message for 3s machine reset itself.

As to BIOS downgrade - I dont think it is possible for me to downgrade it. Maby my Google fu is to weak but I cannot find trusted source of bios file. Lenovo page doesnt have one (I suppose it was removed by them), and I dont have backup of previous version.

But, on bugzilla there is other bug report which treats about hibernation problem, bios not recognized by ACPI and identical laptop:

https://bugzilla.kernel.org/show_bug.cgi?id=186861

Laptop in that bug report has bios A2CN34WW which is lower version, and the owner states that he can use kernels up to 4.6 on that machine.

Moreover there is another - newer verions of BIOS form Lenovo which suppose to resolve "SMM callout vulnerability"  dated 2016/08/05.

https://support.lenovo.com/pl/pl/product_security/smm_attack

https://download.lenovo.com/consumer/mobiles/a2cn45ww.txt

Here the quesion arise.
Should I upgrade BIOS to version A2CN45WW and proced to trying git-bisect kernel 3.17 ( I havent done it once ), an if so which version should I start with.

(In reply to Len Brown from comment #2)
> Is it possible to identify, via git-bisect, what in Linux changed between
> 3.16 and 3.17 that causes it to run into this failure?

Hi,
I have started bisecting(from 3.17-rc1 to 3.17-rc5), and encountered problem that I cannot resolve. When first kernel compiled by git-bisect (I had to compile gcc4.9 from AUR specially for that operation, alternatively add a pach for compiler-gcc5.h into the kernel tree.) is trying to boot it freezes with message printed on screen "setup_efi_pci() failed". I have to power off laptop by power switch, ctrl+alt+backspace doesnt work.

I'am using initramfs because of LVM on LUKS.  

So I have a question, is there somewhere pach putted upstream that I could eventually manually apply before compilation to resolve this (freeze on boot time error), because kernel compiled from AUR (3.16 LTS - 3.16.39) works perfect.

thnx.
Przemek

Created attachment 250341 [details]
Bisect log

Bisect log

Never mind ...

Bisect log attached.

The first bad commit was:

 [821d6f0359b0614792ab8e2fb93b503e25a65079] ACPI / sleep: Do not save NVS for new machines to accelerate S3


ACPI / sleep: Do not save NVS for new machines to accelerate S3

NVS region is saved and restored unconditionally for machines without
nvs_nosave quirk during S3. Tested some new machines and the operation
is not necessary. Saving NVS region also affects S2RAM speed. The time of
NVS saving and restoring depends on the size of NVS region and it consumes
7~10ms normally.

This patch is to make machines produced from 2012 to now not saving NVS region
to accelerate S3.

Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

I can confirm that this commit made problems on my machine.

I reversed this patch [821d6f0359b0614792ab8e2fb93b503e25a65079] on kernel 4.9 - mainline with config from Archlinux testing repo and my machine can suspend and resume as many times in a row as I want to.

Maby bios upgrade to version A2CN40WW(V2.08) is forcing EFI to read tables from saved NVS memory and so this commit is invalid to my netbook.

please attach the full dmidecode and I will generate a quirk patch for you to force enable nvs saving.

Created attachment 250911 [details]
output from dmidecode

Thank you very much.
Output from dmidecode attached.

Created attachment 251031 [details]
patch to save NVS memory for Lenovo G50-45

please check if this patch helps or not

Unfortunately patch doesn't help at all.
I have appiled it and compiled kernel 4.9.2. Result was the same as with kernel without reversed commit - yelow sign and reset.

I've look inside the patch and quirk is refereeing to "init_nvs_nosave" which is related to "nvs_nosave" and "acpi_nvs_nosave" (sleep.c) . With commit 821d6f0359b0614792ab8e2fb93b503e25a65079 in sleep.c appears "acpi_nvs_nosave_s3" which is called out after quirk section of "static struct dmi_system_id acpisleep_dmi_table[] __initdata" and related to "nvs_nosave_s3" The "init_nvs_nosave_s3" does not exist in the code.

Please forgive me but I am not a programmer so I could be totally wrong.

Once again thanks for your time.
Przemek

Created attachment 251161 [details]
patch V2

please check if this patch helps or not

Created attachment 251241 [details]
patch v3

Yes, finally. 

Patch v2 helped a lot. 
However with original version during compilation I had makefile error:

" CC      drivers/acpi/sleep.o
drivers/acpi/sleep.c:338:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  .callback = acpi_nvs_save_s3,
              ^~~~~~~~~~~~~~~~
drivers/acpi/sleep.c:338:14: note: (near initialization for ‘acpisleep_dmi_table[21].callback’)
cc1: some warnings being treated as errors",

So I made little modification. I have added function "static int __init init_nvs_save_s3" and made changes in quirk section accordingly.

I don't know if I didn't messed up something with the original commit, and if my changes are correct in accordance with coding rules, but on my side with patch v3 everything works as expected. That means I can suspend and resume netbook many times in a row without resetting the system.

Thank you very much for your help.
Przemek

Created attachment 251311 [details]
v4

thanks for your patch, and I think this is the version targeted for upstream, please confirm it works for you.

Created attachment 251361 [details]
patch v5

No, unfortunately this version of patch doesn't compile neither.

Once again compiler yells about incompatible pointer type "init_nvs_save_s3"

I think we have lost part of our previous work during merging versions of patches.

In this version - 5 - I gathered everything together and in accordance to your revision I changed "return 1" to --> "return 0" in function "static int __init init_nvs_save_s3" (BTW I don't know why I have put "1" there, I really apologize for that, it was unintentional).

Applied, compiled kernel 4.9.2 and rebooted. Everything works.

Thanks,
Przemek

This version is okay with me. Just one comment, we should put init_nvs_save_s3() right after acpi_nvs_save_s3().

Will you send the patch upstream, or do you like me to send the patch?

Created attachment 251431 [details]
patch V6: save NVS memory for Lenovo G50-45

please confirm this one works for you and I will send it out soon.

This patch, from my side is working on my Lenovo, so when you think it is ready than it is ready.
Thanks,
Przemek

Patch has been sent out and it's available at
https://patchwork.kernel.org/patch/9517999/

Hello,

I have exactly same problem on a Lenovo G70-35, with Debian 4.19 kernel.
Just removing the 2012 check for enabling nvs save in drivers/acpi/sleep.c resolved this.

Googling around, I also found description of exact same symptoms on Lenovo G40-45, Lenovo G45-50 and HP ENVY m6-k010dx. Found nothing about mine. I suspect much more machines are impacted.

Rather than listing them all, would it be possible to detect the problematic BIOS vendor/versions ? Or being more conservative with this 2012 limit ?