[TRACKING] Framework AMD Ryzen 7040 Series lid wakeup behavior feedback

Framework Laptop 13
41

Isn’t that controlled by a BIOS setting on the 11 gen? On this 11 gen system for example (Fedora 38 with BIOS 3.17 and the that wake on AC option disabled), I’ve never seen this behavior.

Editing: I hadn’t used the power on when AC attached option and had mis-remembered what it does. It doesn’t apply to resuming.

Anyway, just for posterity, the steps below are the same, so resume-on-AC-attach does not appear to be a thing on 11th gen (and more recent comments below suggest it can be traced to AMD-specific EC source code anyway - so, misunderstanding corrected).

Just tested now:

  • Unplug charger (from the machine’s USB-C port)
  • Suspend (power button or lid close)
  • Plug charger in
  • Still suspended
  • Unplug, wait, plug in
  • Still suspended (when suspend was byby lid close, “verified” by observing WLAN reconnect on lid open, so timed consistent with laptop suspended throughout the lid closed time)

(Suspend is configured to s2idle on this machine)

42

Just out of curiosity, what does /proc/acpi/wakeup look like on the AMD system?

FWIW I use this, run from a systemd unit, to disable wakeups from my external keyboard on a gen 11 system:

#!/usr/bin/bash

for device in `tail -n +2 /proc/acpi/wakeup |egrep -v 'PWRB|PXSX' |grep enabled |cut -f 1`; do
  echo "disabling $device"
  sh -c "echo $device > /proc/acpi/wakeup"
done
43

Disabling everything in /proc/acpi/wakeup didn’t fix the lid issue but here’s the print out

> enzi@ultraportable: ~/projects/ec-patches  
$ cat /proc/acpi/wakeup 
Device  S-state   Status   Sysfs node
GPP0      S4    *disabled
GPP1      S4    *disabled
GPP2      S4    *disabled
GPP5      S4    *disabled
GPP6      S4    *enabled   pci:0000:00:02.2
GPP7      S4    *disabled
GP11      S4    *enabled   pci:0000:00:03.1
SWUS      S4    *disabled
GP12      S4    *enabled   pci:0000:00:04.1
SWUS      S4    *disabled
XHC0      S3    *enabled   pci:0000:c1:00.3
XHC1      S3    *enabled   pci:0000:c1:00.4
XHC2      S3    *enabled   pci:0000:c3:00.0
NHI0      S4    *enabled   pci:0000:c3:00.5
XHC3      S3    *enabled   pci:0000:c3:00.3
NHI1      S4    *enabled   pci:0000:c3:00.6
XHC4      S3    *enabled   pci:0000:c3:00.4
44

One theory I have is that this code in the EC may be causing an additional interrupt to the host on wake:

When we go from S0i3 to S0ix, the EC will send some dummy key presses to the host so the keyboard will keep working. This may cause the host to wake up to screen on, and stay there.

5 Likes
45

I think you’re right! I fixed most of my issues with the wakeups using the following rules that I put in the /dev/rules.d/ folder:

/etc/udev/rules.d/20-suspend-fixes.rules

ACTION=="add", SUBSYSTEM=="acpi", DRIVERS=="button", ATTRS{hid}=="PNP0C0D", ATTR{power/wakeup}="disabled"
ACTION=="add", SUBSYSTEM=="serio", DRIVERS=="atkbd", ATTR{power/wakeup}="disabled

The second line disables the keyboard from waking the PC, which fixes the lid waking the machine (along with the first line) AND the AC being plugged in (which sends a keyboard wakeup as well). You lose the keyboard wake-ups but the touchpad and everything else work fine.

I noticed you linked to your GitHub. Is there a guide for consumers to customize and flash their own EC? I haven’t done the research yet.

13 Likes
46

Seems like it kills lid open wake up too for me.

2 Likes
47

Try removing the first line and see if it disables wake-on-close but not wake-on-open.

48

As an aside, how did you track down the particular identifiers to use for the rules? Especially PNP0C0D for the lid?

1 Like
49

Is there anything like this that can be configured for Windows 11? I’m having an issue with my new laptop where it’s waking up from sleep on its own…

50 
sudo udevadm info -p -a /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:44/PNP0C09:00/PNP0C0D:00

I found the device by creating a script that tests disabling every result of:

find /sys -wholename "**/power/wakeup"

No clue.

3 Likes
51

Thank you for this! Using the second rule makes suspend work as expected on Debian Testing. That is, I can close the lid, automatically suspend, unplug and plug power without waking, then open the lid and have the machine wake.

I can also sleep from menu, close the lid and the machine will not wake, just from the second rule. It seems plug/unplug sending keycodes is the problem here.

2 Likes
52

No such luck here with those udev rules. Plugging in my power adapter still wakes the laptop :confused:

53

I missed something! There’s a missing quote at the end of the udev rule here and I totally didn’t catch it last night

The full rule is

ACTION=="add", SUBSYSTEM=="acpi", DRIVERS=="button", ATTRS{hid}=="PNP0C0D", ATTR{power/wakeup}="disabled"
ACTION=="add", SUBSYSTEM=="serio", DRIVERS=="atkbd", ATTR{power/wakeup}="disabled"
7 Likes
54

Echoing the success of others in this thread - adding the second udev rule listed above to disable waking by keyboard keeps the laptop from fully waking up from power plug/unplug. Is this function in the EC necessary for all systems, or is it just a workaround for a specific setup? I ask because I think that this side-effect (waking for power events unnecessarily) is undesirable and am curious if it may be properly fixable further down the line so that we don’t have to just disable waking by keyboard (not the end of the world, but I’d rather have it than not).

4 Likes
55

I can confirm that @Enzious’ approach works

/etc/udev/rules.d/20-suspend-fixes.rules

ACTION=="add", SUBSYSTEM=="serio", DRIVERS=="atkbd", ATTR{power/wakeup}="disabled"

fixes the problem for me.

Thanks a lot.

4 Likes
56

The second udev rule by @Enzious seems to be working around the wake up from plugging/unplugging power as well as waking up by closing the lid when already in standby for me.
udevadm control --reload-rules && udevadm trigger was seemingly not enough to apply it instantly, a reboot did the trick on Arch.

2 Likes
57

If I may ask — has there been any movement on this fix landing upstream?

I am aware that there is a udev workaround, and a user workaround whereby I don’t suspend the laptop before closing the lid.

The problem for me is that I don’t trust my machines to do that. I’ve used linux for over 10 years, and I have a deep-seated mistrust of suspend just not working properly on lid close.

But I will try to overcome it :joy:

3 Likes
58

I’ve sent this patch series to the mailing list to add a workaround in the kernel for the EC behavior (at least with BIOS 03.03). I would expect there is no need for a udev rule with this in place.

[PATCH 0/4] Add a workaround for Framework 13 spurious IRQ1 (kernel.org)

If you prefer the old behavior (which allows “real” wake from keyboard to work) and have this patch, there is a module parameter you can put on your kernel command line amd_pmc.disable_workarounds=1.

16 Likes
59

I received and installed my new AMD mainboard/RAM/Wificard, and lid closing going to suspend seemed to work fine until today I think. Fedora 39, might be the new kernel? Either way, not a huge deal to suspend then close the lid, but still.

60

Turns out when swapping mainboards I broke the little latch for the audio board (thankfully on that site and not the mainboard) so I ordered a new one. I bet that’ll fix it, since I think the lid sensor is on that lil board.

EDIT: And it was. New audioboard fixed it.

2 Likes