I have a FW16 Gen 1 ordered Nov 2023 with OG battery. I was flying today, closed laptop as usual and stuck it in bag after checking that the fans died and it appeared to be asleep. In the airplane I felt the bag was warm so I went to check it - apparently it woke up and didn’t go back to sleep. It was smoking hot with fans blaring. I also noticed that the battery has puffed up distorting the mouse pad. Thankfully I was able to shut it off hard, let it cool off and arrived at the destination safely.
I’m on Fedora 43, with latest BIOS and keyboard firmware and these spurious wakeups HAVE TO BE FIXED. They are extremely dangerous as when that happens and the laptop fails to go back to sleep the system can easily overheat causing battery fire.
So now I’m down 1 battery, 1 bowed out central plate (the battery has distorted it) and a whole bunch of nerves because the problem of spurious wakeups hasn’t been treated seriously since the inception.
There MUST be an external indicator of successfully entering sleep mode (you can’t see the power button light pulsation when the lid is closed!). There has to be a way to prevent the laptop from waking up when the lid is closed and is less than 15 degrees from horizontal and no key presses in that position should register for wakeups. This is a solved problem. All laptops I have used have somehow not had that issue (keyboard activation while closed) since decades ago.
The waking while closed issue was supposed to be fixed in bios 4.0.2 or 4.0.3 and keyboard firmware 0.3.1. Can you see in the logs what triggered the wakeup? I am curious if it was the keyboard or the touchpad. Thankfully you caught it in time, but that’s a drag about the battery. You might try reaching out to Support to see if they will replace it and the bent midplate (?) under warranty.
I generally don’t trust standby mode. Windows wakes up to do updates, and various bugs or hardware failure can cause wakeup.
To be safe, i would suggest power off instead of standby on planes.
In this case, the problem is less the wakeup, and more the overheating. Maybe some EC improvements could detect the “overheating while in bag” scenario, and power off the laptop to prevent damage.
Nope, the journal got corrupted due to hard power off on the plane.
Jan 23 07:58:37 hostname systemd[1]: Reached target sleep.target - Sleep.
░░ Subject: A start job for unit sleep.target has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit sleep.target has finished successfully.
░░
░░ The job identifier is 66660.
Jan 23 07:58:37 hostname systemd[1]: Starting systemd-suspend.service - System Suspend...
░░ Subject: A start job for unit systemd-suspend.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit systemd-suspend.service has begun execution.
░░
░░ The job identifier is 66657.
Jan 23 07:58:37 hostname systemd-logind[2611]: Session c25 logged out. Waiting for processes to exit.
Jan 23 07:58:37 hostname systemd-logind[2611]: Removed session c25.
░░ Subject: Session c25 has been terminated
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ Documentation: sd-login(3)
░░
░░ A session with the ID c25 has been terminated.
Jan 23 07:58:37 hostname systemd[1]: user-0.slice: Unit now frozen-by-parent.
Jan 23 07:58:37 hostname systemd[1]: user@1000.service: Unit now frozen-by-parent.
Jan 23 07:58:37 hostname systemd[1]: session-2.scope: Unit now frozen-by-parent.
Jan 23 07:58:37 hostname systemd[1]: user-1000.slice: Unit now frozen-by-parent.
Jan 23 07:58:37 hostname systemd[1]: user.slice: Unit now frozen.
Jan 23 07:58:37 hostname systemd-sleep[2674166]: Successfully froze unit 'user.slice'.
Jan 23 07:58:37 hostname systemd-sleep[2674166]: Performing sleep operation 'suspend'...
░░ Subject: System sleep state suspend entered
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ The system has now entered the suspend sleep state.
Jan 23 07:58:37 hostname kernel: PM: suspend entry (s2idle)
Jan 23 07:58:37 hostname kernel: Filesystems sync: 0.100 seconds
Jan 23 07:58:37 hostname kernel: Freezing user space processes
Jan 23 07:58:37 hostname kernel: Freezing user space processes aborted after 0.002 seconds (158 tasks refusing to freeze, wq_busy=0):
Jan 23 07:58:37 hostname kernel: OOM killer enabled.
Jan 23 07:58:37 hostname kernel: Restarting tasks: Starting
Jan 23 07:58:37 hostname kernel: Restarting tasks: Done
Jan 23 07:58:37 hostname kernel: efivarfs: resyncing variable state
Jan 23 07:58:37 hostname kernel: efivarfs: finished resyncing variable state
Jan 23 07:58:37 hostname kernel: random: crng reseeded on system resumption
Jan 23 07:58:37 hostname kernel: PM: suspend exit
Jan 23 07:58:37 hostname kernel: PM: suspend entry (s2idle)
Jan 23 07:58:37 hostname kernel: Filesystems sync: 0.007 seconds
Catching it in time would have been before it destroyed the battery and warped the case lol.
It should have fixed it, but there are other bugs remaining that still wake it up. For example, plugging/unplugging a power adapter can also wake it up. There are many many bugs and issues with the Framework firmware. I don’t know why they aren’t prioritizing fixing them.
Also, if you have a usb mouse connected it will still wake it up if moved.
You are lucky it didn’t cause a big issue on the plane.
Unless it’s only going in a bag for a few minutes, I always completely shut down my laptop before putting it in a bag. I’ve had a few incidents of laptops either turning back on when in the bag or just not properly going to sleep, including a MacBook and a Dell laptop. I’ve also actually had one laptop turn on when completely off due to the design of the power button… (a Gigabyte Aero 16 XE5).
So it’s not just a Framework problem, especially with the new S0 sleep (i.e. “modern standby”).
Indeed, but worse would have been if the battery caught fire. Ideally it would not have happened at all. Next best, discovery before any damage occurred. Avoiding disaster, discovery before combustion.
This reminds me of a time where sleep mode was useful, I remember being able to put a PC in “Sleep” and it wouldn’t be on the next day until you pushed the power button or a key on the keyboard.
Now it seems every PC wakes up for a million different reasons, windows updates, something pinged it on the network, slight shift in the earths magnetic field.
It would be cool if Framework could add a “deep sleep” mode that is more like the old school sleep states, requiring a physical interaction being the only way it will wake the device, not just opening the lid, something like actually pressing a key.
I have never trusted sleep, hybrid sleep, or even suspend for anything other than a lower power state while in a desktop situation. I do use suspend but only when I am plugged in and not mobile. The second it goes into a pack or bag it is getting powered off completely. Your story is not new, and is definitely not restricted to Framework laptops.
For windows, I’ve read that microsoft dictates rules for sleep states, including support for “modern standby”. PC makers have to do this in order to get certified by microsoft, for one thing or another. And of course microsoft programs windows to always use their “modern standby” whenever present, and just not to give PC owners any choice. “Deep sleep” might be there, microsoft has made it so it doesn’t matter.
The whole problem is just that microsoft abuses their operating system market share dominance to exert control.
What wakes up a laptop from sleep can be configured on Linux.
For example, I have configured that the only think to wake up my FW16 laptop is the Power button press.
So, I open the lid, and its still sleeping, the power light fading in/out.
I press the keyboard or touchpad, no wake.
Only pressing the power button wakes it up.
This seems to prevent the laptop waking up while in a bag, for me at least.
I would expect it to be configurable also in Windows, I just don’t know how.
well that depends,
If bios has a bug for power mangament or so or that OS itself has a bug that causes a process to wake the laptop up with lid closed.
I store the following file called “keyboard-mouse-disable-sleep” in the folder “/usr/lib/systemd/system-sleep”
It stops the keyboard, mouse and lid open from waking the laptop.
One uses the power button to wake it.
The script is not perfect though. There are other things that wake up the laptop. For example, if it gets to 3% battery charge, it will wake in order to hibernate or power off, because below 3% damages the battery.
#!/bin/sh
# This file should be placed in: /usr/lib/systemd/system-sleep
PATH=/sbin:/usr/sbin:/bin:/usr/bin
case "$1" in
pre) #echo AMDI0010:03 >/sys/bus/platform/drivers/i2c_designware/unbind
#echo 1-4 >/sys/bus/usb/drivers/usb/unbind
/home/jcd/computer/framework/qmk_hid/target/debug/qmk_hid via --backlight 0
echo disabled > /sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.3/usb1/1-4/1-4.3/power/wakeup
echo disabled > /sys/devices/platform/AMDI0010:03/i2c-1/i2c-PIXA3854:00/power/wakeup
echo disabled >/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4b/PNP0C09:00/PNP0C0D:00/power/wakeup
exit 0
;;
post) #echo AMDI0010:03 >/sys/bus/platform/drivers/i2c_designware/bind
#echo 1-4 >/sys/bus/usb/drivers/usb/bind
exit 0
;;
*) exit 1
;;
esac
Elegant solution! I use a much more inelegant one, a four-minute cron combined with a shell script testing whether the lid is closed:
#!/usr/bin/bash
set -e
set -u
set -o pipefail
LOG_PREFIX=‘/var/log/sleep_script.log.’
LOG=“${LOG_PREFIX}/usr/bin/date +%A”
RAW_STATE=/usr/bin/cat /proc/acpi/button/lid/LID0/state
matched_value=/usr/bin/expr match "$RAW_STATE" 'state:\s*\(.*\)'
date=/usr/bin/date "+%D %T"
if ( [[ $matched_value == ‘closed’ ]] )
then
echo “$date: LID CLOSED, FORCING SUSPEND” >> $LOG
/usr/sbin/pm-suspend
else
echo “$date: LID OPEN, SLEEPING” >> $LOG
fi
(I do try to remember to shut down my Gen 1 before putting it in a bag, but I’m only human and sometimes forget. The above is my version of suspenders plus belt.)
Hey @Arcadiy_Ivanov1 Sorry to hear that this has happened. Have you contacted support? If not, please do so and then shoot the email address you used to me via DM. We’d like to investigate this.
