Alright, this one is probably easy to fix, low priority, but driving me crazy.
Closing the lid triggers a wake-up. If you put the computer into suspend and close it on something thin so you can see past the screen gasket… the screen turns on.
The lid close event/signal is waking the computer. I think that’s incorrect behavior. I’ve disabled all ACPI wake-up devices but it’s still doing this, it makes sense that this is probably being handled by the BIOS. No DE/WM, at a plain vt, it’s still doing this behavior.
I think two changes would help here and honestly all machines where Framework is customizing BIOSes:
Only wake-up on lid open and ignore lid close while suspended (if it’s possible with the BIOS)
Ability* to disable the lid completely as a wake-up source via BIOS
Please
> enzi@ultraportable: ~
$ dmesg | grep -i -C 1 -e fail -e error -e bug -e issue -e crash -e oops
[ 0.003281] ACPI: FACP 0x000000005AFEF000 00010C (v05 INSYDE EDK2 00000002 ACPI 00040000)
[ 0.003284] ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x0000000000000000/0x1 (20230331/tbfadt-615)
[ 0.003286] ACPI: DSDT 0x000000005AFDF000 0093A6 (v02 INSYDE EDK2 00000002 ACPI 00040000)
--
[ 0.361843] PCI: not using MMCONFIG
[ 0.361845] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.361847] PCI: Ignoring E820 reservations for host bridge windows
--
[ 0.441676] usbcore: registered new interface driver usbtv
[ 0.441965] fail to initialize ptp_kvm
[ 0.442063] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@redhat.com
--
[ 0.479083] Btrfs loaded, zoned=no, fsverity=no
[ 0.479425] pstore: Using crash dump compression: deflate
[ 0.479912] PM: Magic number: 11:63:177
--
[ 0.483010] Loading firmware: regulatory.db
[ 0.483276] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 0.483552] cfg80211: failed to load regulatory.db
[ 0.484032] clk: Disabling unused clocks
--
[ 1.471042] clocksource: Switched to clocksource tsc
[ 8.255081] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[ 13.375080] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[ 18.494506] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[ 19.245170] exFAT-fs (dm-0): invalid boot record signature
[ 19.245174] exFAT-fs (dm-0): failed to read boot sector
[ 19.245175] exFAT-fs (dm-0): failed to recognize exfat type
[ 19.249545] BTRFS: device fsid 9e95fabc-0b33-4819-b2cd-c7598f5e1c9e devid 1 transid 29021 /dev/mapper/root scanned by exe (2196)
--
[ 54.276254] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 54.276262] printk: Suspending console(s) (use no_console_suspend to debug)
[ 54.454865] ACPI: EC: interrupt blocked
--
[ 66.331833] nvme nvme0: 16/0/0 default/read/poll queues
[ 66.461744] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=14
[ 66.461808] [drm:amdgpu_mes_reg_write_reg_wait [amdgpu]] *ERROR* failed to reg_write_reg_wait
[ 66.463889] [drm] PCIE GART of 512M enabled (table at 0x000000801FD00000).
--
[ 70.187918] wlp1s0: Limiting TX power to 0 (-128 - 0) dBm as advertised by 86:c0:8f:b9:12:51
[ 71.654785] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[ 71.769606] ------------[ cut here ]------------
--
[ 71.769762] ? rcu_note_context_switch+0x49c/0x4e0
[ 71.769766] ? report_bug+0x189/0x1c0
[ 71.769773] ? handle_bug+0x36/0x70
[ 71.769778] ? exc_invalid_op+0x13/0x60
--
[ 71.770014] ---[ end trace 0000000000000000 ]---
[ 77.286751] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[ 93.487931] elogind-daemon[3675]: Power key pressed.
--
[ 94.077480] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 94.077490] printk: Suspending console(s) (use no_console_suspend to debug)
[ 94.262707] ACPI: EC: interrupt blocked
--
[ 98.784022] nvme nvme0: 16/0/0 default/read/poll queues
[ 98.923463] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=14
[ 98.923548] [drm:amdgpu_mes_reg_write_reg_wait [amdgpu]] *ERROR* failed to reg_write_reg_wait
[ 98.925525] [drm] PCIE GART of 512M enabled (table at 0x000000801FD00000).
--
[ 102.182375] wlp1s0: Limiting TX power to 0 (-128 - 0) dBm as advertised by 86:3f:70:b9:12:51
[ 104.251222] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[ 109.883208] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[ 127.210913] warning: `kded5' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211
--
[ 139.495639] Freezing remaining freezable tasks completed (elapsed 0.000 seconds)
[ 139.495642] printk: Suspending console(s) (use no_console_suspend to debug)
[ 139.503993] queueing ieee80211 work while going to suspend
--
[ 1107.007488] nvme nvme0: 16/0/0 default/read/poll queues
[ 1107.146946] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=14
[ 1107.147033] [drm:amdgpu_mes_reg_write_reg_wait [amdgpu]] *ERROR* failed to reg_write_reg_wait
[ 1107.149051] [drm] PCIE GART of 512M enabled (table at 0x000000801FD00000).
--
[ 1110.306441] usb 1-4: reset full-speed USB device number 2 using xhci_hcd
[ 1112.465146] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[ 1118.097122] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[ 1150.492745] wlp1s0: authenticate with 2a:0f:74:4c:6c:8e
I’ll drop some more interesting findings later tonight
So this is also effecting the UFI menus where even in the bootloader performance lags. I don’t want to use fedora, Seeing how this is effecting both environments (In windows I updated to the latest driver package and these issues still persist)
I have a similar problem, when I close the lid while it’s still connected to the charger and it goes to suspend, and I then unplug the charger, it then also wakes up again (I can also see the screen light turning on through a thin gap). It’s only the charger connected and then unplugged, not a dock.
I’m still on the old BIOS, and I can also reproduce your wake-on-close problem there, so that’s both nothing really related to the new BIOS version (I assume that the wake-on-unplug also still happens with the new BIOS?). But both shouldn’t happen, the laptop shouldn’t wake up when closed.
Noticed this today too on ubuntu22.04 oem kernel.
(also,resuming from suspend lead to a white screen, no way to recover from it, only the cursor is visible)
Alright, status update. It’s an EC bug. I thought I read once that the Framework EC firmware was/would-be open-source? I think the EC should be more configurable.
This fixes the problem but then you can’t wake the PC up again
echo "Y" | sudo tee /sys/module/acpi/parameters/ec_no_wakeup
Disabling everything in /proc/acpi/wakeup doesn’t prevent wakeups, only ec_no_wakeup but that disables everything including the power button
We’re getting ready to pull this out of beta, so I need to make sure I have everything straight.
Those seeing suspend wakeups (as I am not on either of my AMD Ryzen 7040 laptops), what is attached and what was running? On my test machines, lid close is suspend to RAM (on our tested and recommended distributions) and resume takes place on lid open events.
We expect default behavior for the default config. The default config and the config we test is lid close suspend, lid open resume.
You indicated you changed the default behavior. You changed the behavior to lid close null and are experiencing the new behavior if lid close resume when you have suspended this laptop using the non-default method. Is this not correct?
While I understand this isn’t ideal behavior and certainly not what is intended. The default action and purpose of the lid is to suspend it at this time unless it has been changed. In this case, it has.
Ideally, this would not be the case and it’s certainly valuable feedback on having the ability to disable the lid behavior entirely.
But, at this time, we are focused on default expected out of the box behavior at this time. Not custom tweaks made to HandleLidSwitch=.
Moving on, feedback received and appreciated.
Does anyone have feedback on other issues that they are experiencing?
Overall, for out of the box behavior, this appears to be a significant improvement over 3.02 and we will be releasing this out of beta tomorrow.
Only issue I’ve encountered is suspend seeming to break entirely with the kernel param “nvme.noacpi=1” set. Fedora 39 beta, 64GB DDR5-5600,WD SN850x, kernel version 6.5.8. This isn’t particularly surprising given this kernel option disables a workaround for suspend related to nvme drives, but as far as im aware it worked fine on the intel boards.
@Matt_Hartley@Kieran_Levin Any feedback on the charging issues with BIOS 3.03? Not only about the Steam Deck Chargers not working at all, but also about showing a battery full LED when the battery isn’t completely charged.
I had the same issue earlier in the thread, as long as you have the 4 green checkmarks in the bottom right, you can press the power button to turn off. You will want to re-run the BIOS update to properly downgrade the PD firmwares, which didn’t work for me until I used the official Framework charger during the BIOS update.
For some reason, when using my apple charger, the BIOS update would hang at that exact spot.
While it should charge with compatible chargers, my focus is does it work as expected with Framework chargers with this particular release. It does with Framework chargers.
If there issues with other compatible chargers, feel free to open or add to a thread and we can get this to the engineering team.
