Suspend fails every second time on some laptops in UEFI mode

[David Cameron Staples]

Fresh install of Xubuntu 14.04.3, replacing existing OEM Windows 10. Install detected UEFI, and installed in UEFI mode. (I have attempted to change to legacy boot, and got it to a state where it was booting without /sys/firmware/efi/ being present, but behaviour persisted.)

Suspending the laptop, whether by closing the lid, choosing the suspend option from the menu, or directly typing "sudo pm-suspend" works perfectly well... once.

The second attempt to suspend, whether immediately or hours later, suspends the laptop (I can see the screen turn off, and hear the disk and fans stop, but a moment later the screen shows bright yellow console text declaring "Warning!!! Boot script table modified!!! Please contact your vendor.", and then it hard reboots.

This appears to be a weird interaction between suspend and UEFI protection, but others have reported that they have had working suspend when installed alone (and presumably in legacy from the start), but this behaviour appeared when reinstalled as dual-boot (when presumably UEFI would have had to be on). (http://askubuntu.com/questions/675683/suspend-does-not-work-more-than-once-after-reboot-ubuntu-15-04-dual-boot/712232 and earlier http://askubuntu.com/questions/651481/boot-script-table-modified-please-contact-vendor, from different people.)

Beyond the investigations I have done, I know next to nothing about UEFI, or how Suspend might be interacting with it. Much less why it appears to work perfectly exactly once.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: pm-utils 1.4.1-13ubuntu0.1
ProcVersionSignature: Ubuntu 4.2.0-22.27~14.04.1-generic 4.2.6
Uname: Linux 4.2.0-22-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.19
Architecture: amd64
CurrentDesktop: XFCE
Date: Wed Dec 23 13:27:11 2015
InstallationDate: Installed on 2015-12-19 (3 days ago)
InstallationMedia: Xubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805)
PackageArchitecture: all
SourcePackage: pm-utils
UpgradeStatus: No upgrade log present (probably fresh install)

[David Cameron Staples (catsidhe)]

Just updated to 4.2.0-27-generic #32~14.04.1-Ubuntu SMP, and this is still an issue.

This may not actually be directly related to pm-suspend, but I put it here for lack of a better proximate cause. This may need to be transferred to be a kernel bug.

I suspect it may be related to a reaction to http://www.intelsecurity.com/advanced-threat-research/content/WP_Intel_ATR_S3_ResBS_Vuln.pdf

It can be reproduced by putting Ubuntu of just about any recent version onto a Lenovo G50-45, and suspending it twice.

[VaclavSynacek (evasek)]

I have the same problem on Lenovo S435 and ubuntu-mate 15.10 on 4.2.0-30-generic x86_64 dual boot with Windows 8.1.
But this problem started only after bios update from BBCN16WW(V1.03) to BBCN16WW(V1.07). With the previous bios V1.03 this never happened, even with the same kernel.

[Julius Eckert (eckert-julius)]

Same problem on Lenovo G70. Ubuntu 14.04 on 4.2.0-35-generic. Replaced OEM Win10 with Ubuntu.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Brad (bbaker6212)]

I'm seeing this problem on various versions of Linux Mint from v17.3 Cinnamon with kernel 3.19 to v18 Mate with kernel 4.4 or 4.7. Apart from the OP problem description of symptoms with yellow text console warning message, I have suspicion that this problem is also causing the more severe problem with kernel 4.7 that even the first suspend/resume results in a system lockup/freeze upon attempting to resume. I think it may be important to first determine if this problem is specific to a machine and it's BIOS version. In this case I believe we are talking mostly, if not only, about Lenovo machines (like mine). I think it is possible this is a result of a BIOS update by Lenovo to fix a security hole described below. That said, my notebook's info is below. Note the BIOS version and date. Also note that the security hole (UEFI implementations do not properly secure the EFI S3 Resume Boot Path boot script) is not specific to Lenovo and MANY vendors would have had to make a similar patch - which might explain suspend/resume problems reported by various people with other notebook brands. More info can be found on my LM formum thread: https://forums.linuxmint.com/viewtopic.php?f=46&t=227168#p1199128

System: Host: G50 Kernel: 4.7.0-040700-generic x86_64 (64 bit gcc: 5.4.0)
           Desktop: MATE 1.14.1 (Gtk 3.18.9-1ubuntu3.1)
           Distro: Linux Mint 18 Sarah
Machine: System: LENOVO product: 80E3 v: Lenovo G50-45
           Mobo: LENOVO model: Lancer 5B2 v: 31900058 STD
           Bios: LENOVO v: A2CN38WW(V2.06) date: 07/15/2015

Lenovo Advisory: https://support.lenovo.com/br/en/product_security/s3_boot_protect

Vulnerability Note VU#976132 http://www.kb.cert.org/vuls/id/976132
UEFI implementations do not properly secure the EFI S3 Resume Boot Path boot script

[Brad (bbaker6212)]

This thread is indicating that it is not specific to Lenovo machines, as I suspected:
https://forums.linuxmint.com/viewtopic.php?t=212044

Re: Crash upon suspend. Message: Boot Script Table modified.
Postby syeager » Mon Jun 13, 2016 2:27 am

"I have been installing different linux distros on my HP Envy and all have the same problem: sleep once, fine; sleep again, and it will not recover with a black screen, where upon on reboot (the only option with a hardware reboot) i get the error message 'boot script table modified'. Not only does this happen to linux distros, i have had it happen to windows 10 clean install. I just installed windows 10 to an ssd and added bodhi linux as a uefi boot. Just put windows to sleep (for the first time after rebooting) after playing an old XP game (Neverwinter Nights) and it gave the same problem. Does that help you analyze it? I can test theories, if anyone has one.

OK, i tried ubuntu, thinking that i heard they paid microsoft for uefi, so maybe it would handle awaking from sleep better. No it doesn't. Then i tried robolinux, which is a debian release but also booted up with the cd with a legacy boot instead of uefi booting from the cd, and it can sleep just fine. i am assuming it is the legacy boot. Thoughts?"

[Brad (bbaker6212)]

OK, I just tested with a Live-USB disk of Linux Mint 17.2 Cinnamon (kernel 3.16) newly burned from the ISO file and suspend/resume works great. Multiple times in a row, from the shutdown icon, from the power button, and from the notebook lid close/open. So this is either Kernel or distro dependant and perhaps not related to the BIOS version as I thought. I tested this from a Live-USB of Linux Mint 18 Cinnamon (kernel 4.4) and it DOES NOT work, it has the same problem - first suspend/resume works fine, then upon second suspend it displays the yellow text warning and reboots the system at the BIOS level.

[Brad (bbaker6212)]

Next I'll test with a fresh live-USB version of Linux Mint 17.3 (kernel 3.19) to try to narrow down the problem. I'm not expecting it to work since I've already reproduced the problem on LM 17.3 installed to HD.

[VaclavSynacek (evasek)]

I also upgraded several times since my report on 2016-02-24. I am convinced the bug is a combination of
  1) BIOS version (possible due to security fix of Vulnerability Note VU#976132 mentioned above)
  2) Linux kernel in general (regardless of kernel version or distribution)
  3) boot in UEFI mode

Tests of various combinations of BIOS, distribution and kernel underneath. "Cannot suspend" means can suspend once, but freezes on second suspend and after hard restart prints "Warning!!! Boot script table modified" boot message and freezes.

Lenovo S435, all boots in UEFI mode
  - BIOS BBCN16WW(V1.03)
      - Ubuntu mate 15.10 with kernel 4.2.0 => can suspend
      - Windows 8.1 => can suspend

  - since BIOS upgrade to BBCN16WW(V1.07)
      - Windows 8.1 => is unaffected and still can suspend
      - Ubuntu mate 15.10
          - with kernel 4.2.x => cannot suspend
      - Debian testing
          - with kernel 4.3.x => cannot suspend
          - with kernel 4.4.x => cannot suspend
          - with kernel 4.5.x => cannot suspend
          - with kernel 4.6.x => cannot suspend
      - OpenBSD 5.9 => completely fails to suspend even the first time, possibly due to unrelated issues or my incompetence (I will report progress if I manage to get it to suspend at least once)

[Brad (bbaker6212)]

to summarize my findings with Linux Mint (LM), all with UEFI booting and
the latest Lenovo BIOS: A2CN38WW(V2.06) 07/15/2015

I created fresh, default Live-USB boot disks using the 64bit Cinnamon ISO's and here was my result:

LM18 Cinnamon (kernel 4.4) FAIL: fails on menu icon suspend. First attempt works OK, second attempt displays a bright yellow text message on black screen "Warning! boot script table is modified! Please contact your vendor." followed by auto cold-booting the system.
LM17.3 Cinnamon (kernel 3.19) FAIL - same as LM18
LM17.2 Cinnamon (kernel 3.16) SUCCESS - Works great! everything - menu icon click, power button, notebook lid open/close

[Brad (bbaker6212)]

@VaclavSynacek, someone needs to change the subject of this bug or merge it into another/new one because it might get assumed that this problem is specific to a Lenovo G50-45 or even Lenovo devices in general, and hence not get the attention it deserves. I don't believe that it is specific to just Lenovo. I've seen the exact problem symptoms (yellow text warning on second suspend) reported on an HP Notebook and there's prob others.

[Brad (bbaker6212)]

In a nutshell, it looks to me like this feature was broken somewhere between kernel releases 3.16 (working) and 3.19 (not working), POSSIBLY in combination with having a machine that has a BIOS version newer than mid-2015 when vendors updated their BIOS with the VU#976132 fix.
  I'll try to reproduce the problem on kernels v3.17.1-utopic and v3.18-vivid.

[Brad (bbaker6212)]

Further kernel testing on my Lenovo G50-45 with Linux Mint 17.2 Cinnamon, reveals:

PASS - 3.16.0-38-generic #52~14.04.1-Ubuntu
PASS - 3.16.0-77-generic #99~14.04.1-Ubuntu
FAIL - 3.17.0-031700rc4-generic #201409071935 *diff symptom - lockup, fast cpu fan on first resume.
FAIL - 3.17.0-031700rc6-generic #201409211935
FAIL - 3.17.0-031700-generic #201410060605
FAIL - 3.17.4-031704-generic #201411211317

* It also fails on later LM 17.3 (kernel 3.19) and LM 18 kernels 4.4 and 4.7

NOTE that my Lenovo G50 BIOS release A2CN38WW(V2.06) was July 2015
and the other above mentioned Lenovo S435 BIOS release BBCN16WW(V1.07) was June 2015
His PASS on Ubuntu mate 15.10 w/kernel 4.2.0 was due to older BIOS BBCN16WW(V1.03).

Hypothesis is still strong that this is due to a BIOS change in mid 2015 to fix VU#976132.
Kernel versions released after mid 2015 need to be patched. This is likely true for MANY different computer vendors which use common BIOS suppliers' code.

[Brad (bbaker6212)]

Also, this is all UEFI booting and 64bit, I have testing nothing using legacy.

[Brad (bbaker6212)]

It's even worse with kernel 4.8-rc1. It now fails on first resume attempt - shows screen with time and logo but no login prompt and requires hard reboot.

System: Host: G50 Kernel: 4.8.0-040800rc1-generic x86_64 (64 bit gcc: 6.1.1)
           Desktop: MATE 1.14.1 (Gtk 3.18.9-1ubuntu3.1) Distro: Linux Mint 18 Sarah
Machine: System: LENOVO product: 80E3 v: Lenovo G50-45
           Mobo: LENOVO model: Lancer 5B2 v: 31900058 STD Bios: LENOVO v: A2CN38WW(V2.06) date: 07/15/2015
CPU: Quad core AMD A6-6310 APU with AMD Radeon R4 Graphics (-MCP-) cache: 8192 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm) bmips: 14372
           clock speeds: max: 1800 MHz 1: 1800 MHz 2: 1600 MHz 3: 1800 MHz 4: 1800 MHz
Graphics: Card: Advanced Micro Devices [AMD/ATI] Mullins [Radeon R4/R5 Graphics] bus-ID: 00:01.0
           Display Server: X.Org 1.18.3 drivers: ati,radeon (unloaded: fbdev,vesa) Resolution: 1366x768@59.99hz
           GLX Renderer: Gallium 0.4 on AMD MULLINS (DRM 2.46.0, LLVM 3.8.0)
           GLX Version: 3.0 Mesa 11.2.0 Direct Rendering: Yes

[Brad (bbaker6212)]

what log files could I supply that would help debugging this problem? Is there some kinda tutorial on how to do this?

[Brad (bbaker6212)]

c'mon guys, at least tell me what log files I can collect to see where the problem is?

[David Cameron Staples (catsidhe)]

There are no logs. Unless UEFI is keeping any,I don't think there can be any logs, because the OS is suspended at the time it happens.

[Brad (bbaker6212)]

But isn't there kernel logs, or others, that log events up-to the suspend event and then potentially during/after the resume attempt? Sorta same as logging driver events during bootup, reboot, shutdown, etc.

[David Cameron Staples (catsidhe)]

Leading up to the suspend, I don't think the OS can tell that there's anything different... Or else if it can it's not looking for it. Afterwards it's not getting as far as the kernel before UEFI kills it, at which point the kernel can only tell that it was rebooted while in a suspended state. All I have seen in the logs is a normal "suspending" set of messages. Maybe there's a kernel flag to turn on verbose ACPI logging?

[VaclavSynacek (evasek)]

Similarly Brad's findings I also confirm, that upgrade to kernel 4.8 actually made things worse in my configuration. Now the system is broken not after second suspend, but right after the first suspend and resume. The screen comes back on, but keyboard and mouse are dead, visible processes are dead (no way to type ps, but clock and other visible things in X windows are not updating). Requires hard reboot.

To recap my configuration:
Lenovo S435
UEFI mode
BIOS upgraded to BBCN16WW(V1.07)
Debian Stretch (testing)
kernel 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) x86_64 GNU/Linux

[carloslp (carloslp)]

It seems some hardware needs the OS to store/restore the NVS state when entering/exiting S3 (suspend to ram).

On bug https://bugzilla.kernel.org/show_bug.cgi?id=189431 a quirk was added to the Linux Kernel to do this for the Lenovo G50-45. If you have a similar issue on hardware other than this Lenovo laptop please say that on the previous linked kernel bug.

[David Cameron Staples (catsidhe)]

So given that this bug has been confirmed, found to be a bug in the kernel code, and a patch created for it... is it possible to get this bug moved to the Kernel, and generally find out if there's a timeline for the patch being ported to the usual set of kernels?

It would be nice to have full functionality of my computer at some point before it needs replacing from old age.

[Christian Ehrhardt  (paelzer)]

So far the only kernel tag with that fix is v4.11-rc1, I haven't seen it being sent to stable trees.
Neither were there other platforms added - I see the G70 and S435 in the bug here.
You might want to follow the kernel bug link and mention your platoform showing the issue there as recommended by Carloslp in comment #23.

Adding a task for the kernel Team to consider a fix.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1528735

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.