Open nakato opened 3 years ago
Seems like LID0 might be triggering something via KIP (is that keyboard?).
I'm not entirely sure what that target category is for exactly. In part at least it is for enabling events (e.g. base-battery on the SB3) and it seems that this may also be related to management for hot-pluggable devices. I can see the same event you describe on the Surface Pro X when I close the typecover. But I can also see that when I fold it back or when I disconnect it (in that case there are also a bunch of other events). So I don't think that's an event for the lid, rather one for notifying that the keyboard device has been disconnected or re-connected (or in your case probably turned off and turned back on again or something like this).
As far as I can tell, the lid should be notified in pretty much the same way as on the SL3:
I.e. both are handled via GPIO-signaled ACPI events. This is essentially a part of the AMDI0031
controller in ACPI and as far as I can tell should be handled in the gpiolib kernel subsystem when gpiochip_add_data()
is called in pinctrl-amd.c
.
Might be possible that setting up the GPIO fails somehow...
Could also be that it's crashing somewhere during resume, that'd probably fit with the power consumption.
So I checked the event you mentioned again and it seems to indicate the keyboard/typecover state (it has a one byte payload that seems to be some event), so it indicates if it is attached, folded back, or closed. So it does also report the lid state. I still think that the switch should be handled via ACPI though.
BTW, I've extended the debug interface for SAM if you want to do some logging (e.g. look at the event values). See e.g. this script. You'll need to run modprobe surface_aggregator_cdev
before running that script (and use the latest Surface kernel).
@nakato
I recently purchased a new Surface Laptop 4 (AMD) and installed linux-surface and have started running into this exact issue.
Did you make any progress on debugging or resolving it? Also do you noticing random crashes after screen tearing?
I could try applying the patches mentioned in this comment to our builds, that should at least fix the amdgpu driver, right? Or are there more patches required?
Did you make any progress on debugging or resolving it?
I haven't had much free time lately, so I haven't been able to attempt looking into this further yet.
All my testing has been with 5.13 RC builds, there were a handful of patches that caught my eye with respect to problems I was having with this laptop, but I can't say how much each one helped as I haven't been methodical about figuring out exactly what is and is not needed.
Also do you noticing random crashes after screen tearing?
After a suspend with the S0ix patches? Yes, sometimes, usually when trying to kick the GPU into high gear. I've only managed to fully lock the system up once, and I was trying to reload the amdgpu module after the amdgpu module deadlocked.
I could try applying the patches mentioned in this comment to our builds, that should at least fix the amdgpu driver, right?
These, with the previous AMD0005 ID should at least allow amdgpu to usually successfully reactivate the display, the system is only sometimes stable after this however.
I have only found one way to actually trigger a proper wakeup however, and that's with something plugged into the USB port.
There are numerous ways to half-wake the system though, which puts it into a rather awake state consuming a fair bit of power and putting out a fair of heat with the display off. I absolutely would not sleep my laptop and put it into my backpack with this behavior being regular. The wall adapter will show 8.5W in this state, which is significant, the laptop will after being actually woken up will consume 6W with the display on at minimum brightness.
Or are there more patches required?
It is possible that there are patches in the 5.13-rc branch that are improving the situation in addition to applying the S0ix patches, I'm not sure right now.
Thanks! I've tracked down a couple more patches that may (or may not) be useful from the linked discussion (and repos linked therein) and added them: https://github.com/linux-surface/kernel/pull/102. Let's hope this improves things.
Okay, new releases with those patches should be available now.
@qzed Awesome! Thanks for getting this done so swiftly. I'll pull in the changes and test them out after work (In about 8-10 hours)
Hey @qzed,
Sorry for the delay, work was pretty hectic yesterday.
So I was able to pull in the latest version of linux-surface 5.12.12-surface
and I observed that the amdgpu doesn't screen glitch anymore and I've not observed any crashes 🥳 .
Also the S0ix suspension problem where the screen is not responsive after an automatic suspension is still there. Just confirming were the recent changes meant to fix that?
Thanks
Also the S0ix suspension problem where the screen is not responsive after an automatic suspension is still there. Just confirming were the recent changes meant to fix that?
I had hoped that they'd fix it. Do you mean actual suspending or just the screen going black? Might be a good idea to open up a new issue for that.
So I can't manually trigger a suspension as setting the suspension upon clicking the power button doesn't take affect in ubuntu with linux-surface. However, I was able to set automatic suspensions upon 15 minutes of no activity and test it that way.
Any chance you can confirm this @nakato ?
Also the S0ix suspension problem where the screen is not responsive after an automatic suspension is still there. Just confirming were the recent changes meant to fix that?
Do you mean the screen display wakes up and you can see the lock screen (or whatever it wakes up to) and then it locks up?
Can you SSH the machine? Is amdgpu complaining of a lockup? (Any AMD Vi:
event messages? I expect not.)
I won't be able to get a copy of this from my system for a couple of weeks, so if you want to attach it, put it in a collapse.
<details><summary>"dmesg" output</summary>
```
Contents here
```
</details>
Or do you mean the laptop never wakes for suspend, but starts sucking down power? You need a fully charged laptop and some way of measuring power draw to confirm this easily. There's many way's to trigger this, such as opening the lid (LID0 is broken as a wake source), touching the keyboard, touching the trackpad, other forms of input that wakes up the EC.
So I can't manually trigger a suspension as setting the suspension upon clicking the power button doesn't take affect in ubuntu with linux-surface. However, I was able to set automatic suspensions upon 15 minutes of no activity and test it that way.
No clue here, I don't use Ubuntu. I can sleep the system with systemctl suspend
, and from the KDE user interface.
Or do you mean the laptop never wakes for suspend, but starts sucking down power?
The computers screen doesn't respond, it's just black. However the keyboards lights and internal components (fans) are awake.
Or do you mean the laptop never wakes for suspend, but starts sucking down power?
The computers screen doesn't respond, it's just black. However the keyboards lights and internal components (fans) are awake.
Sounds like the kernel's still asleep. See the initial message to this issue as well as issue #80.
@qzed after hours of watching videos the amdgpu finally froze up, is there any additional tweaks we could make?
@nakato that thread had a lot of information to digest. Was there any resolutions?
@qzed after hours of watching videos the amdgpu finally froze up, is there any additional tweaks we could make?
I'm not aware of any. Let me know in case you find more patches and I'll have a look at integrating those. I think your best bet at fixing this is looking somewhere more AMD focused, e.g. the freedesktop gitlab.
@nakato I can suspend using systemctl suspend
and that replicates the problem.
so when I run systemctl suspend
the computer suspends but the screen doesn't turn back on.
Here is the dmesg @nakato
Here is the dmesg @nakato
Please edit the this comment as described in the above comment https://github.com/linux-surface/linux-surface/issues/458#issuecomment-865478319 so it doesn't make the issue so long.
That dmesg doesn't actually show the problem, so removing the output is fine as well.
@LordLalwani you'll have to get a log from the time when the issue occurs, the one you've provided looks like a fresh boot. So you probably want to use something like journalctl -k -b -1
. That command returns the log from the last boot, so do something like suspend, reboot, get the log from the suspend via that command. Or ssh into the machine if you've got a second one around to do that and get the log via that.
So I super + l
my computer which replicated the problem and got the logs on the next boot
The computer froze up again upon changing workspaces
My laptop crashed again when just moving a window to the left side pane with super + left
@qzed I think this amdgpu issue is quite serious now, I'm using this laptop for work and it's froze up 8ish times throughout the day and I can't lock or log out my screen. Also when unplugging my dock the computer freezes.
Your logs still don't show the actual issue, they're still from the current boot and not the last one/the one that caused the issue. You do need to specify -b +/-<offset>
(e.g. -b -1
to get the previous boot) explicitly. You could check if the timestmaps make sense to verify that you have the correct log.
This does show some warning, but I'm not sure if that's related to any crashes, as that occurs directly after boot.
Someone mentioned that they had better luck with amd_iommu=off iommu=off
instead of amd_iommu=force_isolation
, so you could try that as well.
@qzed Sorry about that! I thought I was giving you the correct logs!
I'll trial the amd_iommu=off iommu=off
settings over the weekend and see how I go.
If it crashes/freezes again i'll try get you the correct logs.
Thanks so much for your help with this project! everyone appreciates yours support :)
No worries. Let's hope the parameters work, otherwise you'll probably have to contact the AMD folks, I'm really out of my depth with this GPU stuff (and they probably know a bit more about this).
I was able to replicate it by hitting suspend
from the power management gui tools in the top right
Hmm, so I think this time around it looks like the correct log (from the timestamps at least), but there's still no error visible. It's possible that some stuff got dropped due to the unclean shutdown afterwards (i.e. buffers haven't been flushed to disk). Interestingly there isn't even a suspend entry message, but I think that doesn't have to mean anything.
You could try to disable console suspend via echo N | sudo tee /sys/module/printk/parameters/console_suspend
, that might give us some more info, but there's also no guarantee that it will. Suspend stuff is unfortunately hard to debug.
Edit: the evdi
lines are a bit weird but I think that should have something to do with DisplayLink rather than amdgpu.
Hey @qzed I did a lot of research and finally resorting to just disabling the suspension and hibernation modes in Ubuntu.
I followed this article: https://www.tecmint.com/disable-suspend-and-hibernation-in-linux/
It seems to have resolved the problem. It's not a permanent solution but it's good enough for me haha
Right, that should be a decent workaround for now. Kinda defeats the purpose of a laptop a bit, but I hope the AMD/drm guys will get this fixed.
Yeah I agree with you. It's not ideal but it's better then closing the lid and having to restart the computer every time haha 😅
Is there any where I can escalate this too? e.g the amd/drm guys?
Is there any where I can escalate this too? e.g the amd/drm guys?
I think since (as far as I can tell) this seems to be a GPU issue, https://gitlab.freedesktop.org/drm/amd should be the place to go (DRM as in Direct Rendering Manager). Otherwise maybe the amd-gfx@lists.freedesktop.org mailing list (source).
Since I couldn't find it pasted anywhere explicitly, I wanted to share the kernel log error message seen when closing the lid:
Jul 08 16:31:55 surface-laptop-4 kernel: Uhhuh. NMI received for unknown reason 2d on CPU 0.
Jul 08 16:31:55 surface-laptop-4 kernel: Do you have a strange power saving mode enabled?
Jul 08 16:31:55 surface-laptop-4 kernel: Dazed and confused, but trying to continue
This part I have no idea what's causing. It should be noted that I set the cpu scaling governor to a non-default setting. And then immediately after:
Jul 08 16:46:49 surface-laptop-4 kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!
Jul 08 16:46:49 surface-laptop-4 kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered
Hopefully I'm not leaving out any important context by just showing these parts. This bug would often come up when entering hibernation. I haven't experienced it again after applying the suggestion from #480, though the former error message still remains. It also used to crash the system when using WebGL, or doing certain actions in the GNOME that relied on hardware acceleration. Seems to be mostly worked around though.
All considered, I've only experienced one freeze / black screen when trying to hibernate since disabling the iommu, and it displayed the NMI error message. I'll see if it persists.
After much teeth gnashing trying to trigger a wakeup via the surface aggregator any time the interrupt was high, I ended up looking at the GPIO driver and worked out it wasn't configured for wake ups, and following that found the patches in https://github.com/linux-surface/kernel/pull/104 almost immediately.
With these patches applied, I was able to trigger a system resume via opening the laptop lid. I suspect this is also relevant to #80, as I think the SL3A's lid switch is configured similarly, and AMDI0030 and AMDI0031 use the same driver.
I am however still seeing high power utilization in suspend in some circumstances, so I still do not consider suspend to be usable on this laptop.
The high power utilization in sleep mode appears to occur anytime I perform an event that triggers the SSAM interrupt, so I'm attempting to understand what is required to clear out the events and bring the interrupt low again as a means to see what impact that has on power consumption while in suspended.
From drivers/platform/surface/aggregator/controller.c
ssam_irq_handle()
/* * Note: Proper wakeup detection is currently unimplemented. * When the EC is in display-off or any other non-D0 state, it * does not send events/notifications to the host. Instead it * signals that there are events available via the wakeup IRQ. * This driver is responsible for calling back to the EC to * release these events one-by-one. * * This IRQ should not cause a full system resume by its own. * Instead, events should be handled by their respective subsystem * drivers, which in turn should signal whether a full system * resume should be performed. * * TODO: Send GPIO callback command repeatedly to EC until callback * returns 0x00. Return flag of callback is "has more events". * Each time the command is sent, one event is "released". Once * all events have been released (return = 0x00), the GPIO is * re-armed. Detect wakeup events during this process, go back to * sleep if no wakeup event has been received. */
I presume the GPIO callback is a synchronous request sent to the EC, however I'm not sure I'm correct in that assumption, and I can't find any details on what target, command, etc is appropriate for this callback.
@qzed do you know if this callback is a synchronous request, and any details about it such as the target_id or command?
Glad you managed to track that down!
That's quite interesting. The IRQ should be disabled by default and only be enabled during suspend. However, it should only be marked as wakeup source if the power/wakeup
attribute is set to enabled
(which is by default not): https://elixir.bootlin.com/linux/latest/source/drivers/platform/surface/aggregator/controller.c#L2749. If I'm not mistaken and if the IRQ is not marked as wakeup source, that triggering shouldn't be recognized until the system is awake (so shouldn't cause an increase in power consumption), so maybe there's a bug in the AMD IRQ/GPIO driver? It might also be possible to move the enable_irq()
call inside that if-statement (the only difference should be that we don't get a message when the IRQ has been triggered, but I that's not really a big deal).
With regards to actually implementing that function: I've never managed to make that work properly, but do feel free to try. This is the command you're looking for. It is synchronous as it essentially returns a bool, but events are released in the normal/async way (more on that below).
How this all works is essentially: During display-off states (AFAICT, not sure if that has changed on newer devices which support also D0/non-D0 state in addition to those) events are not sent directly (NB: that state must be entered/exited manually via the 0x15/0x16 commands, the EC doesn't know the actual display power state). Instead, the IRQ is asserted (and held). This should then bring up/wake up the device and driver into a state where it can process those events (more or less) normally. The critical point is that it should not wake up the device completely. In that state the IRQ handler should run.
The IRQ handler then needs to request/release each pending event one by one (note that multiple events just keep the IRQ asserted). To do that it calls the "GPIO wake IRQ callback" request. This will do three things: a) release the next pending event (if there is any), b) return either 0x01 or 0x00 indicating whether there is any pending event remaining after this call (i.e. if it's 0x01 you should call this function again to release the next event and if it's 0x00 there are no more events), and c) de-assert the IRQ if there are no more events (i.e. the request returned 0x00).
By "release the next pending event" I really mean that. The event is not returned as response to the request, but really sent as a single event down the normal event channel. So the IRQ handler might need to do some synchronization, i.e. request/release the event and then wait until the event has been received by the event handler. Events should (AFAICT) be processed normally by the respective subsystem (e.g. battery driver) which should then only wake up on certain conditions (e.g. battery low but not battery percentage changed).
The problem I've had so far is that I can't get the device to go into this semi-wake state where everything for handling the event is ready but the device isn't on a non-stop path to being fully woken up. Meaning I haven't managed for the driver to receive an event, process it, and then go back to sleep. During my tries (quite a few kernel versions back so things may be different now) the device either woke up fully or not at all. This processing and going back to sleep is crucial, however, as there are a ton of "random" events (mostly some sort of battery state change). So if all of those trigger a full wakeup the device is basically unable to stay suspended for more than a couple of minutes (at best, more like 1 to 2 minutes IIRC). On the other hand we're incapable of waking up when the battery is low if we ignore the IRQ... Ideally users should be able to control on which conditions they want to be woken via the normal power/wakeup
attributes of the client devices.
You could, as a first step, maybe try to get the device into the semi-wake state, discard the events (e.g. via some flag in the event handler) and then have the device go back to sleep. If you can manage to get that working reliably that'd definitely be a step further than I got.
I've sent a patch to pinctrl to address spurious wakeups in 5.15 and greater, it will address high power consumption, but not wakeup in 5.14 and less. 5.15 will resume on certain events, such as lid, with https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=acd47b9f28e5 https://lore.kernel.org/linux-gpio/20211001161714.2053597-1-nakato@nakato.io/T/#t
It is likely that the pinctrl patch is not enough though, as I've only tested it with the ACPI ID patches I had stuck in my local tree. I've pushed them just now. https://lore.kernel.org/linux-kernel/20211002041840.2058647-1-nakato@nakato.io/T/#t
I've never sent a kernel patch in before, so hopefully I'm not making any egregious mistakes.
Nice work!
So with the backports from v5.15 and the ACPI ID patches suspend works now with acceptable power consumption and the device can be woken via lid and/or power button?
I've never sent a kernel patch in before, so hopefully I'm not making any egregious mistakes.
Patches look good to me. According to ./scripts/get_maintainer.pl
you might be missing some CCs on the pinctrl patch though (like Linus Walleij as pinctrl maintainer). All of those should be on the linux-gpio list though so I guess it's not a big deal.
Nice work!
Thanks!
So with the backports from v5.15 and the ACPI ID patches suspend works now with acceptable power consumption
I haven't taken a look at the long-term power consumption, but I can't trigger increased power consumption without actually waking the device anymore.
and the device can be woken via lid and/or power button?
Power button doesn't work, but lid open, lid close, and plugging or unplugging the device will wake it. I expect there's some other wakeup sources I don't know about as well, such as those listed in ssdt9 I think 0x17 is power cable. 0x05 is probably lid. The rest I'm not sure about. Do you think 0x02 is actually wifi, as in 802.11 wifi?
Power button doesn't work, but lid open, lid close, and plugging or unplugging the device will wake it.
Interesting, on the Intel variants, the wakeup signals for plugging/unplugging are sent through the SAM event system (and thus currently don't wake the device up), so not handled explicitly like it seems the case here.
Seems like the power button might need a patch. Looks like the same MSHW0040 device as the other models, which should be handled by the soc_button_array
driver. That internally makes use of gpio_keys
, which should set up the power-button IRQ as wake. Does pressing that in the on-state work?
Do you think 0x02 is actually wifi, as in 802.11 wifi?
That's possible. IIRC wake-on-(w?)lan is supposed to work if the device is suspended and configured correctly. I think I've seen wakeup GPIOs for that on other devices as well.
on the Intel variants, the wakeup signals for plugging/unplugging are sent through the SAM event system
I'm pretty sure the plug/unplug events are being reported via the SAM in addition to the ACPI, or maybe actually via pinctrl-amd. I'll have to verify they're coming in on the SAM eventually, but before that I want to understand the interaction between the ACPI interrupt and the pinctrl-amd, because I get the feeling something is not right there.
I think the device wakeup on LID and power-plug are actually being generated by the pinctrl-amd driver, and I think it should actually be sowing up from the SCI interrupt, IRQ-9 in the SL4A case, but /proc/interrupts
doesn't show any events on that IRQ.
I set kernel option pm_debug_messages
, and the LID and power-plug wakeups are: PM: Wakeup unrelated to ACPI SCI
, which I think means they're not coming from ACPI, and as far as I can tell, having wake set on an interrupt results in pm_wakeup_pending() being true
, and thus a full wakeup happening regardless of what the interrupt is actually about, it's too late to stop it at this point.
I think pinctrl-intel does some special casing on any pin that is used with ACPI, as it looks like it does not set irq_enable_wake on its own IRQ if the pin is used for ACPI. I expect more than ACPI pins will be configured though, which would set irq_enable_wake anyways, and I don't know how it would differentiate between waking up for one of those interrupts as opposed to an ACPI pin. I would be really interested what an Intel using s0ix and pinctrl-intel shows in /proc/interrupts before and after suspend and wakeup with a ACPI event after a fresh boot.
Seems like the power button might need a patch. Looks like the same MSHW0040 device as the other models, which should be handled by the soc_button_array driver. That internally makes use of gpio_keys, which should set up the power-button IRQ as wake. Does pressing that in the on-state work?
I hadn't noticed the soc_button_array
driver at all yet. For some reason I was under the impression that the power button was going to be part of the _AEI section, clearly it's not.
It doesn't register at all, and looking at that section of the ACPI it looks like it should be showing up on GPIO pin 11 (0x0b), and that's not configured at all, so it looks like that's where I'll start.
I'm pretty sure the plug/unplug events are being reported via the SAM in addition to the ACPI, or maybe actually via pinctrl-amd.
Yeah there have to be some SAM events for the plug/unplug update to work. So looks like the ACPI events are an additional thing to that.
I think the device wakeup on LID and power-plug are actually being generated by the pinctrl-amd driver, and I think it should actually be sowing up from the SCI interrupt, IRQ-9 in the SL4A case, but
/proc/interrupts
doesn't show any events on that IRQ. [...] I set kernel option pm_debug_messages, and the LID and power-plug wakeups are: PM: Wakeup unrelated to ACPI SCI, which I think means they're not coming from ACPI, and as far as I can tell, having wake set on an interrupt results in pm_wakeup_pending() being true, and thus a full wakeup happening regardless of what the interrupt is actually about, it's too late to stop it at this point.
Yeah, I think something like this would explain it.
I would be really interested what an Intel using s0ix and pinctrl-intel shows in /proc/interrupts before and after suspend and wakeup with a ACPI event after a fresh boot.
I'll post that in a sec, let me know if you need more.
Okay, here's /proc/interrupts
before and after suspend:
Okay, here's /proc/interrupts before and after suspend:
That helps, thanks for sharing that.
The Surface Laptop 4 AMD cannot reliably resume from suspend as it only support S0ix.
Support for S0ix is currently missing from mainline, and the device does not support S3.
As far as I can tell, at least part of this issue is relevant to the SL3A, as it also only support S0ix and no S3. The SL3A has the hardware ID AMD0004, so the amd-pmc loads without needing a patch.
Behavior
Device after resume from suspend will appear to be unresponsive, the screen is blank without backlight. If you actually manage to wake the device up, and have remote access you can find the amdgpu driver dying.
Issues
There are a couple of issues.
My dmesg logs have rotated out, so I don't have a copy on hand at the moment, and I don't have a kernel ready to roll back to at this moment.
Amdgpu will complain of "Fences timed out".
LID0
Seems like LID0 might be triggering something via KIP (is that keyboard?).
Unique to suspend with lid, resume with opening lid then triggering wakeup with pre-plugged external input.
Have I missed something with the LID switch here? I have not yet worked out how to determine if it has an interrupt assigned. I'm not seeing any in the dsdt.dsl.
/proc/interrupts
``` CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 3: 0 0 0 0 0 0 0 0 0 0 99869 0 0 0 0 0 IR-IO-APIC 3-edge ttyS4 4: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 4-edge AMDI0010:02 7: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 7-fasteoi pinctrl_amd 8: 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 IR-IO-APIC 8-edge rtc0 9: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 9-fasteoi acpi 10: 0 24 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 10-edge AMDI0010:00 11: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 11-edge AMDI0010:01 25: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IOMMU-MSI 0-edge AMD-Vi 26: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 34816-edge PCIe PME 27: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 36864-edge PCIe PME 28: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 133120-edge PCIe PME 30: 0 0 0 0 0 0 0 0 0 40 0 0 0 0 0 0 IR-PCI-MSI 524288-edge nvme0q0 31: 1507 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 524289-edge nvme0q1 32: 0 1267 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 524290-edge nvme0q2 33: 0 0 1385 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 524291-edge nvme0q3 34: 0 0 0 1270 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 524292-edge nvme0q4 35: 0 0 0 0 650 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 524293-edge nvme0q5 36: 0 0 0 0 0 780 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 524294-edge nvme0q6 37: 0 0 0 0 0 0 672 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 524295-edge nvme0q7 38: 0 0 0 0 0 0 0 725 0 0 0 0 0 0 0 0 IR-PCI-MSI 524296-edge nvme0q8 39: 0 0 0 0 0 0 0 0 1735 0 0 0 0 0 0 0 IR-PCI-MSI 524297-edge nvme0q9 40: 0 0 0 0 0 0 0 0 0 1391 0 0 0 0 0 0 IR-PCI-MSI 524298-edge nvme0q10 41: 0 0 0 0 0 0 0 0 0 0 847 0 0 0 0 0 IR-PCI-MSI 524299-edge nvme0q11 42: 0 0 0 0 0 0 0 0 0 0 0 1385 0 0 0 0 IR-PCI-MSI 524300-edge nvme0q12 43: 0 0 0 0 0 0 0 0 0 0 0 0 687 0 0 0 IR-PCI-MSI 524301-edge nvme0q13 44: 0 0 0 0 0 0 0 0 0 0 0 0 0 1056 0 0 IR-PCI-MSI 524302-edge nvme0q14 45: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 650 0 IR-PCI-MSI 524303-edge nvme0q15 46: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 697 IR-PCI-MSI 524304-edge nvme0q16 47: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 2 ACPI:Event 48: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 61 ACPI:Event 49: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 62 ACPI:Event 50: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 58 ACPI:Event 51: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 59 ACPI:Event 52: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 5 ACPI:Event 53: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 23 ACPI:Event 54: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 7 ssam_wakeup 57: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1576960-edge psp-1 59: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1579008-edge xhci_hcd 60: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1579009-edge xhci_hcd 61: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1579010-edge xhci_hcd 62: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1579011-edge xhci_hcd 63: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1579012-edge xhci_hcd 64: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1579013-edge xhci_hcd 65: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1579014-edge xhci_hcd 66: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1579015-edge xhci_hcd 68: 0 0 0 0 0 6608 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1581056-edge xhci_hcd 69: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1581057-edge xhci_hcd 70: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1581058-edge xhci_hcd 71: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1581059-edge xhci_hcd 72: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1581060-edge xhci_hcd 73: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1581061-edge xhci_hcd 74: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1581062-edge xhci_hcd 75: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1581063-edge xhci_hcd 77: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 8 apds9960_event 78: 0 0 0 0 0 0 0 0 0 0 0 0 0 12364 0 0 IR-PCI-MSI 1048576-edge iwlwifi: default queue 79: 552 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1048577-edge iwlwifi: queue 1 80: 0 534 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1048578-edge iwlwifi: queue 2 81: 0 0 565 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1048579-edge iwlwifi: queue 3 82: 0 0 0 476 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1048580-edge iwlwifi: queue 4 83: 0 0 0 0 618 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1048581-edge iwlwifi: queue 5 84: 0 0 0 0 0 469 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1048582-edge iwlwifi: queue 6 85: 0 0 0 0 0 0 1198 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 1048583-edge iwlwifi: queue 7 86: 0 0 0 0 0 0 0 624 0 0 0 0 0 0 0 0 IR-PCI-MSI 1048584-edge iwlwifi: queue 8 87: 0 0 0 0 0 0 0 0 583 0 0 0 0 0 0 0 IR-PCI-MSI 1048585-edge iwlwifi: queue 9 88: 0 0 0 0 0 0 0 0 0 330 0 0 0 0 0 0 IR-PCI-MSI 1048586-edge iwlwifi: queue 10 89: 0 0 0 0 0 0 0 0 0 0 618 0 0 0 0 0 IR-PCI-MSI 1048587-edge iwlwifi: queue 11 90: 0 0 0 0 0 0 0 0 0 0 0 357 0 0 0 0 IR-PCI-MSI 1048588-edge iwlwifi: queue 12 91: 0 0 0 0 0 0 0 0 0 0 0 0 981 0 0 0 IR-PCI-MSI 1048589-edge iwlwifi: queue 13 92: 0 0 0 0 0 0 0 0 0 0 0 0 0 744 0 0 IR-PCI-MSI 1048590-edge iwlwifi: queue 14 93: 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 IR-PCI-MSI 1048591-edge iwlwifi: exception 95: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 485 0 IR-PCI-MSI 1574912-edge snd_hda_intel:card0 96: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 917 IR-PCI-MSI 1585152-edge snd_hda_intel:card1 97: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 348316 0 IR-PCI-MSI 1572864-edge amdgpu NMI: 5 5 5 4 26 12 6 8 4 4 6 4 6 6 9 30 Non-maskable interrupts LOC: 46578 41168 51577 40420 1032587 360918 165644 87496 44263 42916 116108 38935 60192 76739 73680 406567 Local timer interrupts SPU: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Spurious interrupts PMI: 5 5 5 4 26 12 6 8 4 4 6 4 6 6 9 30 Performance monitoring interrupts IWI: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 IRQ work interrupts RTR: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 APIC ICR read retries RES: 97588 103338 94546 94512 561062 345854 174626 134826 95064 88611 70716 99181 141665 151804 155564 960024 Rescheduling interrupts CAL: 213819 103898 97711 91550 127538 107752 72810 81118 84565 83662 114858 131339 114830 65912 91408 90784 Function call interrupts TLB: 16065 15530 15801 16674 27381 26795 13059 18425 16819 18372 15502 18646 15795 14139 17889 8882 TLB shootdowns TRM: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Threshold APIC interrupts DFR: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Deferred Error APIC interrupts MCE: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Machine check exceptions MCP: 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 Machine check polls ERR: 0 MIS: 0 PIN: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Posted-interrupt notification event NPI: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Nested posted-interrupt event PIW: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Posted-interrupt wakeup event ```/proc/acpi/wakeup
``` Device S-state Status Sysfs node GPP9 S0 *disabled GP17 S4 *enabled pci:0000:00:08.1 HDAU S0 *disabled pci:0000:03:00.1 ACP S0 *disabled pci:0000:03:00.5 AZAL S0 *disabled pci:0000:03:00.6 ```Power Consumption
Not sure if I should break this out into another issue, but I'll add this here for now. Power consumption seems to be acting strange with resume.
I'll try to describe the issue as best I can for now, but I need to take better notes so I can describe it more accurately.
Using a power meter at the AC side of the OEM power supply, the device shows a draw of about 13W with a desktop environment up, brightness full, and a rather power hungry external keyboard.
Once suspended with s2idle with the AMD PMC and the 6 S0ix patches the power meter reports a consumption of ~1.1W.
If the lid was closed, opening the lid will see a jump in consumption to ~8.5W.
Suspending the machine via an interactive means,
rtcwake -s 30 -m freeze
rtcwake -s 30 -m mem
KDE-Menu->Suspend
orsystemctl suspend
then touching the laptop keyboard sees the machine jump to ~8.5W consumption as well.The 8.5W of power consumption seems exceptionally high, as the keyboard has it's LED's turned off at this stage, which when re-testing with the desktop environment open, and external keyboard LEDs off, power consumption drops to 9.7W with the screen at full brightness, and 6.0w with the display at minimum brightness.
I haven't slept the device for an extended period of time to see if the power consumption shows up without human input.
It seems like the platform might be waking up some hardware in preparation for us to receive an event and do something with it, but I'm not sure yet.