Message-ID: <a242799a-d427-48e1-85ef-923f34df843a@gmail.com>
Date: Wed, 26 Nov 2025 01:08:51 -0800
From: Tabby Kitten <nyanpasu256@...il.com>
To: ulf.hansson@...aro.org
Cc: linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: rtsx_pci_sdmmc aborts suspend when /sys/power/wakeup_count is enabled

On a PC with a Realtek PCI Express SD reader, when you sleep with
`wakeup_count` active (eg. sleeping from KDE's lock screen), the MMC
driver wakes up the system and aborts suspend.

I've found a sleep failure bug in the rtsx_pci and mmc_core drivers. 
After userspace writes a number to `/sys/power/wakeup_count` (eg. KDE 
Plasma does it to distinguish user wakes from timers and Wake-on-LAN), 
if it attempts a mem suspend it will be aborted when 
rtsx_pci_runtime_resume() -> mmc_detect_change() emits a 
pm_wakeup_ws_event(). This breaks sleep on some hardware and desktop 
environments.

The detailed description:
The recently released Plasma 6.5.0 writes to `/sys/power/wakeup_count`
before sleeping. On my computer this caused the sleep attempt to fail
with dmesg error "PM: Some devices failed to suspend, or early wake
event detected". I got this error on both Arch Linux and Fedora, and
replicated it on Fedora with the mainline kernel COPR. KDE is tracking
this error at https://bugs.kde.org/show_bug.cgi?id=510992, and have
disabled writing to wakeup_count on Plasma 6.5.3 to work around this
issue.

I've written a standalone shell script to reproduce this sleep failure 
(save as badsleep.sh):

#!/bin/bash
read wakeup_count < /sys/power/wakeup_count
if [[ $? -ne 0 ]]; then
    e=$?
    echo "Failed to open wakeup_count, suspend maybe already in progress"
    exit $e
fi
echo $wakeup_count > /sys/power/wakeup_count
if [[ $? -ne 0 ]]; then
    e=$?
    echo "Failed to write wakeup_count, wakeup_count may have changed in between"
    exit $e
fi
echo mem > /sys/power/state

Running `sudo ./badsleep.sh` reproduces failed sleeps on my computer.
(sudo is needed to write to `/sys/power/wakeup_count` on Fedora.)

* If I run the script unaltered, the screen turns off and on, and the 
  terminal outputs
  `./badsleep.sh: line 14: echo: write error: Device or resource busy`
  indicating the mem sleep failed.

* If I edit the script and comment out `echo $wakeup_count > 
  /sys/power/wakeup_count`, the sleep succeeds, and waking the computer 
  skips the lock screen and resumes where I left off.

* If I run `sudo rmmod rtsx_pci_sdmmc` to disable the faulty module, the 
  sleep succeeds, and waking the computer skips the lock screen and 
  resumes where I left off.

I think this problem happens in general when a driver spawns a wakeup 
event from its suspend callback. On my system, the driver in question 
lies in the MMC subsystem.

## Code debugging

If I run `echo 1 > /sys/power/pm_debug_messages` to enable verbose 
logging, then attempt a failed sleep, I see output:

    PM: Wakeup pending, aborting suspend
    PM: active wakeup source: mmc0
    PM: suspend of devices aborted after 151.615 msecs
    PM: start suspend of devices aborted after 169.797 msecs
    PM: Some devices failed to suspend, or early wake event detected

The "Wakeup pending, aborting suspend" message comes from function 
`pm_wakeup_pending()`. This function checks if event checks are enabled, 
and if some counters have changed aborts suspend and calls 
`pm_print_active_wakeup_sources()`, which prints `wakeup_sources`. 
Tracing the code that modifies `wakeup_sources`, I found that 
`pm_wakeup_ws_event()` would activate an event and 
`wakeup_source_register() → wakeup_source_add()` would add a new one.

To find who changed wakeup events, I used my stacksnoop fork at 
https://github.com/nyanpasu64/bcc/blob/local/examples/tracing/stacksnoop
.py to trace a failed suspend:

nyanpasu64@...en ~/code/bcc (local)> sudo ./examples/tracing/stacksnoop.py pm_wakeup_ws_event wakeup_source_register
TIME(s)            FUNCTION
7.254676819:
0: ret_from_fork_asm [kernel]
1: ret_from_fork [kernel]
2: kthread [kernel]
3: worker_thread [kernel]
4: process_one_work [kernel]
5: async_run_entry_fn [kernel]
6: async_suspend [kernel]
7: device_suspend [kernel]
8: dpm_run_callback [kernel]
9: mmc_bus_suspend [mmc_core]
10: mmc_blk_suspend [mmc_block]
11: mmc_queue_suspend [mmc_block]
12: __mmc_claim_host [mmc_core]
13: __pm_runtime_resume [kernel]
14: rpm_resume [kernel]
15: rpm_resume [kernel]
16: rpm_callback [kernel]
17: __rpm_callback [kernel]
18: rtsx_pci_runtime_resume [rtsx_pci]
19: mmc_detect_change [mmc_core]
20: pm_wakeup_ws_event [kernel]

On a previous kernel, lines 9-12 were replaced by a single call to 
`pci_pm_suspend`. I've posted my detailed debugging on the older kernel 
at https://bugs.kde.org/show_bug.cgi?id=510992#c26. There I found that 
`pci_pm_suspend()` wakes PCI(e) devices before sending them into a full 
sleep state, but in the process, `_mmc_detect_change()` will "Prevent 
system sleep for 5s to allow user space to consume the\n corresponding 
uevent"... which interrupts a system sleep in progress.

On my current kernel, the same logic applies, but reading the source I
can't tell where `__mmc_claim_host()` is actually calling
`__pm_runtime_resume()`. Nonetheless the problem remains that
`rpm_resume()` is called during system suspend, `mmc_detect_change()`
wakes the system when called, and this will abort system sleep when
`/sys/power/wakeup_count` is active.

## Next steps

How would this problem be addressed? Off the top of my head, perhaps you 
could not call `__pm_runtime_resume()` on a SD card reader during the 
`device_suspend()` process, not call `pm_wakeup_ws_event()` when the SD 
card status changes, not call  `pm_wakeup_ws_event()` *specifically* 
when system suspend is temporarily waking up a SD card reader, or 
disable pm_wakeup_ws_event() entirely during the suspend process (does 
this defeat the purpose of the function?).

Are there other drivers which cause the same symptoms? I don't know. I 
asked on the KDE bug tracker for other users to attempt a failed sleep 
with `echo 1 > /sys/power/pm_debug_messages` active, to identify which 
driver broke suspend in their system; so far nobody has replied with 
logs.

Given that this bug is related to `/sys/power/wakeup_count` 
(https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-power), I 
was considering CCing Rafael J. Wysocki <rafael@...nel.org> and 
linux-pm@...r.kernel.org, but have decided to only message the MMC 
maintainers for now. If necessary we may have to forward this message 
there to get their attention.

----

System information:

* I have an Intel NUC8i7BEH mini PC, with CPU 8 × Intel® Core™ i7-8559U 
  CPU @ 2.70GHz.

    * uname -mi prints `x86_64 unknown`.

* `lspci -nn` prints
  "6e:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader [10ec:522a] (rev 01)".

* I am running kernel 6.18.0-0.rc7.357.vanilla.fc43.x86_64 from the Fedora COPRs 
  (https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories).

* dmesg at https://gist.github.com/nyanpasu64/ab5d3d1565aafe6c1c08cbcaf074e44a#file-dmesg-2025-11-25-txt

* Fully resolved config at https://gist.github.com/nyanpasu64/ab5d3d1565aafe6c1c08cbcaf074e44a#file-config-6-18-0-0-rc7-357-vanilla-fc43-x86_64,
  source at https://download.copr.fedorainfracloud.org/results/@kernel-vanilla/mainline-wo-mergew/fedora-43-x86_64/09831015-mainline-womergew-releases/kernel-6.18.0-0.rc7.357.vanilla.fc43.src.rpm

Powered by blists - more mailing lists