It happened to me recently when I closed the laptop’s lid and put it in my backpack. Unfortunately it hadn’t suspended successfully and this caused overheating, draining the battery and risking potential hardware damage.
I always check if I can hear the fans after closing the lid, but the laptop was silent.
In this case some kind of kernel issue probably occured and the system got completely stuck before actually going to sleep. If I could tell, I would have force-shutdown the machine.
Does the laptop not have any LEDs on the side to provide feedback?
I just ordered my first FW (the 16.25 batch 7) and this sounds extremely frustrating. I’ve had it happen to me with Lenovo laptops, which is why I always check the LED on the power button at the side to make sure the Lenovo has suspended properly…
I can think of at least one instance where your OS is definitely responsible. Please include the necessary information. OS and also what bios version you are on.
On older FW13 an FW16, there have been reports of the laptop waking while in a backpack.
There are work arounds. For example on my FW16, i have disabled all wakeup except with power button.
In that way, even opening the lid does not wake it. I open lid, see it still asleep, and press the power button to wake it.
FW will fix all the wake problems eventually, but the work around is acceptable to me.
BIOS version is 03.04. I’ll edit the description and add it. (EDIT: can’t edit the description…)
As I wrote, the kernel most likely crashed while suspending. Why does it matter if it’s Linux (it is) or Windows? This thread is not about fixing the OS from crashing (has happened only once so far), but for figuring out the state of the machine without opening the lid.
Will try peeking from the side to see if the light around the fingerprint reader is visible, as @2disbetter mentioned.
Little known fact if you are on Linux (which I am as well) and you are on one of the two most likely suspects Fedora or Ubuntu (since they receive full support)…you are 1. very likely on a systemd based distro and 2. also likely on Gnome…in which case you will experience the following: systemd defaults to allowing the desktop environment to handle power events such as suspend and since gnome removed certain values from dconf specifically related to lid closing it is now difficult→impossible to hand that back off to systemd without breaking a ton of stuff that is handled correctly by the desktop environment and making it something you need to manage. So while I ran into this wonderful gnome dev decision, and began working through the process of having systemd handle it … I lost motivation since the easy work around is to manually suspend, then close the lid, and move on.
So that is why the OS matters in conjunction with the desktop environment being used.