Laptop reboots when lid is opened

Bruce Ediger

My Arch Linux laptop started rebooting when I closed the lid and re-opened it.

As Ben Franklin noted, “Men and nations behave wisely when they have exhausted all other resources”. So it was with this problem.

Last Saturday, 2024-05-18, I noticed that my Dell Latitude E7470 laptop, which I’ve had since 2021-08-01, would reboot when I pulled it out and opened the lid.

I had to close and re-open it several times to understand what was going on. This involved many reboots, so it was time consuming.

This was complicated by a couple of other issues. First, this laptop has Intel e1000e network hardware. The latest Linux kernel has a bug that causes things like dhcpcd, ip and other invaluable networking commands to hang.

Every time I tried to use cabled networking, things started to hang. Firefox web browser, ssh, slowly things stooped working. I had to manually reboot to clear those problems. During the manual reboots, I noticed a short, red line of text that appeared momentarily just before the screen went black. To read that, I had to modify the file /boot/grub/grub.cfg, removing the word “quiet” from Linux kernel command line arguments. I discovered that the systemd service wpa_supplicant#wlp0s20f0u1 was enabled. wpa_supplicant is the daemon that manages WiFi connections. wlp0s20f0u1 is the name Linux gave to any WiFi USB dongle I plugged in to the USB port on the right hand side of my laptop while I was figuring out the Kea DHCP daemon. I disabled wpa_supplicant#wlp0s20f0u1 and immediately got a reboot that was 90 seconds faster.

The second problem in understanding when the laptop rebooted was that if I had the charger plugged in, closing the lid and re-opening would not cause a reboot. Wrestling with the inadvertently enabled wpa_supplicant service, and changing kernel boot command line parameters left me with a confusing system journal. I learned how to get journalctl to show me time ranges of system logs, instead of spewing the entire multi-year log.

journalctl --since 2024-05-10T11:30:00 --until 2024-05-10T20:30:00

I learned how to suspend my laptop from the command line with Runningsudo systemctl suspend

Pushing the power button when the charger was plugged in resumed from suspend just fine. I could unplug the charger, then plug it back in, but then the laptop didn’t resume, it rebooted. Something got set while Linux was suspended, which should be a big clue.

1110 % cat /sys/power/mem_sleep
s2idle [deep]

I have an impression the above means that “deep” suspension is what will happen, which is suspend to RAM. If you do some further work, you can make a suspend do an S2, which is suspend-to-idle. I think I probably should have tried to get to my laptop doing suspend-to-idle, but I’m not going to futz around with that new.

I looked up which kernel I installed when in /var/log/pacman.log. That was kind of confusing since I had fiddled with kernels because of the Intel e1000e ethernet bug.

I backed off on the kernel version to linux-zen 6.8.4. That didn’t help.

I realized that Linux headers, linux-firmware and intel-ucode packages might be involved, so I reinstalled a coherent set of those packages.

linux-zen 6.8.4.zen1-1
linux-zen-headers 6.8.4.zen1-1
intel-ucode 20240312-1
linux-firmware 20240312.3b128b60-1

No luck. Laptop still reboots when recovering from a suspend.

I’ve had mediocre luck with Dell laptop batteries, in that I’ve replaced a battery in the last 3 laptops I’ve owned, plus one of my kid’s laptops.

I posted to the Arch Linux forum to see if they were any help. Someone there thought that a battery really wouldn’t cause this kind of problem if it was only a year old.

I found two people asserting different things about similar-sounding problems:

  1. If swap space is smaller than memory, suspend to memory doesn’t work right.
  2. Upgrading BIOS firmware solved it.

free tells me that my laptop has 16183392 units free, and 8388604 units of swap, about half the memory, but extending the swap partition would be extremely painful.

I bit the bullet and upgraded the BIOS firmware, from v1.19.4, 04/20/2018 to v1.36.3, 09/18/2022 . This was quite a side quest. Really ugly. Some group at Dell should be ashamed.

Upgrading BIOS firmware Side Quest

  1. Read Arch linux wiki on flashing BIOS firmware
  2. Find and download firmware file from dell.com
  3. Downloading AUR package builder for unetbootin
  4. Build unetbootin Arch Linux package
  5. Install dependencies of unetbootin
  6. Finish building unetbootin Arch Linux package
  7. Using unetbootin to put a bootable FreeDOS 1.3 installation on a USB thumb drive
  8. Finding out that unetbootin needs to install a particular OS, not run on a particular OS.
  9. Put FreeDOS 1.3 on a USB thumb with unetbootin
  10. Find out that FreeDOS 1.3 doesn’t boot
  11. Find FreeDOS 1 ISO file
  12. Play the ancient Riddle Game with a bug eyed monster in a cave.
  13. Use unetbootin to put FreeDOS 1 on USB thumb drive
  14. Add firmware flashing .exe file to USB thumb drive
  15. Find out that FreeDOS 1 doesn’t boot
  16. Add menu.c32, libutil.c32, libcom32.c32 from /usr/lib/syslinux/bios/ to FAT filesystem USB
  17. Boot FreeDOS 1
  18. Can’t find the BIOS firmware flashing .exe file from step 14
  19. Boot Linux, try to figure out how to put that .exe file where FreeDOS can find it.
  20. Reboot FreeDOS 1. Take a chance that the .exe is on B: or C:
  21. It’s on B: “drive”. Run it.

In retrospect, I think I could have used FreeDOS 1.3. The missing menu.c32 file was a red herring that made me believe that FreeDOS 1.3 would not work (step 10).

Finale

This seems to have solved the problem. I can close the laptop lid, let it sit for a while and re-open. It recovers from suspend, with or without the power cord plugged in. Similarly, running sudo systemctl suspend from the command line while not plugged in, waiting a while, then pressing the power button, no longer causes my laptop to reboot.

I’m not entirely happy with this. Before upgrading the BIOS firmware, I booted using linux-lts, kernel 6.6.31, which is quite a few revisions back, and still experienced the problem.

This implies that either:

  1. I hadn’t noticed the problem for many months of pacman revisions or
  2. The BIOS firmware experienced something like an age-related change, a.k.a. “bitrot”. Of course, some software might have fiddled with BIOS settings somehow.