Tried to self immolate for the second time

Ubuntu Resolute Raccoon 26.04

7.0.0-22-generic Kernel

BIOS 3.06
Keyboard and Multifunction Pad had firmware flashed as well to halt keypresses

Framework 16 AI 300 series board with a 1st gen GPU all 1st gen other than board and wifi Chip 2nd gen

Sleep doesn’t work reliably I thought I had it solved by moving to the new kernel on Resolute raccoon after it had woken closed in the backpack and nearly killed itself running through a full battery overheating itself for no apparent reason (the wifi chip wasn’t playing nice with the older kernel on 24.04) but it just did it again under Resolute Raccoon after working since launch. Nearly burned my hand on the laptop trying to remove it from the bag the heat sinks were too hot to touch battery had gone from full to 6% on my commute. The OS was in a bare desktop state with no user requested programs left running prior to sleep.

Any ideas/tips on where to start with this? As it stands the new MOBO has been a massive downgrade that shouldn’t have been released as far as I’m concerned would have already moved back to my 7040 if I hadn’t given it away (foolish I know). It isn’t any faster I have yet to make use of the NPU and have a much greater need for reliable sleep like I had on my 7040 than for an NPU any day.

Hey @Jared_C_Strong this is a user-to-user forum. Sometimes Framework staff are lurking but that’s not a given.

Seems like you’re running a supported distro. It might be productive to open a support ticket. I’m sure they’ll be able to tell you if your issue is out of scope for support.

1 Like

I’m not sure if this will fix your problem, but my problem with sleep was that every possible thing (like breathing on the touchpad) was waking the device up. Then, of course, it would not have any air in the bag to cool down the CPU even at idle. So on my AMD FW13 with Lubuntu (you may need to modify it a little), I have created this script (service file). It basically disables all events and leaves just the power button. So every time I want to wake up the device, I have to physically click the power button. Minor inconvenience compared to just opening the laptop up, but I don’t mind.
Create the following file at /etc/systemd/system/disable-wakeup.service, then sudo systemctl enable disable-wakeup, restart computer and put it to sleep. Power button (if mapping is the same on FW16) wakes it up. If it doesn’t wake up, hold power button to turn the computer off and disable the service, fix the script and re-enable.

[Unit]
Description=Disable Wakeup on Devices
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c "echo disabled > /sys/devices/platform/AMDI0010:03/i2c-1/i2c-PIXA3854:00/power/wakeup"
ExecStartPost=/bin/bash -c "for device in /sys/bus/usb/devices/*/power/wakeup; do echo disabled > \"$device\"; done"
ExecStartPost=/bin/bash -c "find /sys/devices -type f -name 'wakeup' | awk '{print \"echo disabled | sudo tee \" $0}' | bash"
ExecStartPost=/bin/bash -c "echo -n 'enabled' > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/power/wakeup"

[Install]
WantedBy=multi-user.target
3 Likes

My admittedly less-elegant solution to undesired wakes on my Framework 16 was to write a script that checks the value of /proc/acpi/button/lid/LID0/state, paired with a four-minute cron. If it comes back as closed, then the laptop is obviously awake with the lid shut and the script calls /usr/sbin/pm-suspend to put it back to sleep.

Caveat: I never have a use case for deliberately running my machine with the lid closed, so this solution works for me.

Oh, cron jobs seem overkill :smiley: I think you can put a script in /usr/lib/systemd/system-sleep/ directory and it will call it on every suspend/unsuspend action and provide ‘pre’ or ‘post’ arguments, to know which action is performed.

2 Likes

I swat mosquitoes with a sledgehammer, too.

5 Likes

What is this?! Amateur hour? Obviously you need to use one of those new fangled devices that uses a laser to burn them alive where they fly (this is a real product and I want one)

2 Likes

I think it would be preferable to have an option in the BIOS settings to choose which input devices are allowed to wake the machine from sleep/suspend, if possible. Then nobody would have to rely on software solutions to implement functionality the computer arguably should have had from the beginning, i.e. a sleep/suspend mode that actually functions as expected and doesn’t suffer from random wakeups. Just my two cents.

Framework team, if you ever read this thread: please consider implementing a BIOS option along the lines of what I’ve just said. Having a laptop nearly immolate itself in someone’s bag due to a random wakeup from sleep mode should never happen, especially not at the price point of the Laptop 16. In my (admittedly amateur) opinion, this is a serious design flaw, and should be corrected as soon as humanly possible.

2 Likes

Don’t quote me on this, but I think that sleep/suspend is an OS feature? Not sure how this works, but they are even called differently (sleep vs suspend). These events are modified definitely OS level and I’m not sure if BIOS could easily achieve this.

I saw one of those that demonstrated years ago when it was a just a research experiment! I wanted one then. I had no idea someone made a product you could buy.

After looking it up. (click to show)

Holy @#$% why are they using a 445nm blue laser? In a little tabletop gadget? With pictures of it setup in people’s homes?!


I was expecting a device for commercial use, only to be mounted where it would never be line-of-sight of any people. Using an IR laser at a frequency that doesn’t penetrate corneas and vitreous fluid well.

Even if their thing is technically within permissible exposure levels, I wouldn’t one using 445nm near me or my family.

Well no, from what I can see, a large part of the problem isn’t with sleep/suspend itself; it’s the fact that input devices such as the keyboard and touchpad are seemingly kept alive during sleep/suspend instead of being disabled, which, it seems, is part of why the random wakeups happen. In my opinion, if modifications can be made to the BIOS or whichever other low-level system controls which devices are able to listen for inputs while the hardware is in the sleep state, so that the keyboard, touchpad, etc. are either fully disabled or the user is able to choose whether they should be enabled or disabled in said sleep state, then the Framework team needs to perform those modifications as soon as possible. I don’t have a whole lot of understanding of how everything works at the hardware or firmware level, but regardless, this seems like an obvious flaw that’s been overlooked up to this point.

(Sorry if that’s not very understandable; I’m not great at choosing words.)

I wonder if it comes with with a remote app that allows me to watch insects getting swatted while I’m abroad on vacation?

My understanding was that they already tried something along those lines with the input device firmware updates and that it was a large improvement but uh apparently hasn’t solved all my issues. So it isn’t like the framework team has completely ignored the issue.

Please open a ticket with our support team if you haven’t already. You’re welcome to DM me the ticket number and I can bring it to the team. Thanks!

I guess I wasn’t aware of that. I’m glad they’re at least trying.