Bug 2502089

1. Please describe the problem:

On a Framework Laptop 16 (AMD Ryzen 7040 Series with Radeon 780M
integrated graphics, BIOS 04.04) running Fedora 43 KDE Plasma on
Wayland, suspend can hang while entering s2idle when a Dell P2725QE
USB-C hub monitor is connected. The USB-C connection carries
DisplayPort Alt Mode, the monitor's USB hub (a keyboard and trackball currently connected), and up to 90 W Power
Delivery.

After I select Sleep, both displays blank, but the Framework
power-button LED remains continuously illuminated instead of changing
to its normal breathing pattern (The monitor's power-button LED does change to the expected breathing pattern). The computer becomes completely
unresponsive. Pressing the power button or keyboard keys does not wake
it, and disconnecting the USB-C monitor does not recover it. A forced
power-off is required, creating a risk of losing unsaved data.

With the same 7.1.3 kernel but the monitor disconnected before
selecting Sleep, suspend completes normally, the LED breathes, and the
computer wakes normally. With the same monitor and peripherals
connected while booted into kernel 7.0.12-101.fc43.x86_64, three
consecutive suspend/resume cycles completed successfully.

The configured sleep mode is s2idle
(`/sys/power/mem_sleep` reports `[s2idle]`). In both failed attempts,
the final kernel message is:

  PM: suspend entry (s2idle)

There is no subsequent record of completed device suspension, entry
into the low-power state, resume, or `PM: suspend exit`. This indicates
that the failure occurs while entering suspend, rather than after a
completed suspend during wake-up.

The controlled reproduction also recorded:

  ucsi_acpi USBC000:00: unknown error 256

and USB hub disconnect/re-enumeration involving the monitor's Realtek
RTL8153 Ethernet function. However, the original failure occurred after
ordinary long-term use, not immediately after connecting the monitor,
so suspending during initial USB enumeration is not a complete
explanation.

The Ethernet connection actually in use is a separate adapter connected
directly to the laptop. No Ethernet cable is connected to the monitor,
although its RTL8153 USB function still enumerates.

The same non-default kernel parameters were present for the good and
bad kernel tests:

  amdgpu.dcdebugmask=0x410 amdgpu.sg_display=0

Expected result: the laptop should enter s2idle and wake normally with
the USB-C monitor connected.


2. What is the Version-Release number of the kernel:

7.1.3-101.fc43.x86_64


3. Did it work previously in Fedora? If so, what kernel version did the
   issue *first* appear?

Yes. Kernel 7.0.12-101.fc43.x86_64 completed three consecutive
suspend/resume cycles with the same USB-C monitor and peripherals.

The problem was first observed on 7.1.3-101.fc43.x86_64. Kernel
7.1.3-100.fc43.x86_64 is installed but has not been tested, so the
precise first failing build within the interval from 7.0.12-101 to
7.1.3-101 has not yet been established.


4. Can you reproduce this issue? If so, please provide the steps to
   reproduce the issue below:

Yes. It has occurred twice with kernel 7.1.3-101 and the monitor
connected, including once after ordinary use and once in a controlled
reproduction.

Steps:

1. Boot Fedora 43 KDE on the Framework Laptop 16 using kernel
   7.1.3-101.fc43.x86_64.
2. Connect the Dell P2725QE directly by USB-C and wait until its display
   and USB hub devices are available.
3. Select Sleep from KDE.
4. Observe that the displays blank but the power-button LED stays
   steadily illuminated rather than breathing.
5. Attempt to wake the laptop, then (optionally - doesn't make a difference) disconnect the monitor. The machine remains unresponsive and requires a forced power-off.

Control results:

* 7.1.3-101 with the USB-C monitor connected: failed on two observed
  attempts.
* 7.1.3-101 with the monitor disconnected before Sleep: one controlled
  suspend/resume completed normally.
* 7.0.12-101 with the same monitor connected: three consecutive
  suspend/resume cycles completed normally.


5. Does this problem occur with the latest Rawhide kernel?

Not tested. Reproducing the failure requires a forced power-off and
risks data loss, so I have not installed or tested a Rawhide kernel at
this point.


6. Are you running any modules that not shipped with directly Fedora's
   kernel?

No


7. Please attach the kernel logs.

The supplied diagnostic output contains the relevant failure evidence
but is not a complete boot journal. I am attaching these sanitized
supplemental excerpts:

* kernel-7.1.3-original-failure-tail-sanitized.txt — last 220 kernel
  messages from the original failure boot, including several successful
  earlier suspend/resume cycles and the final failed attempt.
* kernel-7.1.3-controlled-failure-filtered-sanitized.txt —
  keyword-filtered kernel journal from the controlled reproduction,
  including a successful suspend without the monitor, monitor USB
  enumeration, and the final failed attempt.

If the complete journals are still retained, I will also attach
complete bad-boot kernel logs exported with:

  journalctl --no-hostname -k -b BOOT_ID --no-pager

Reproducible: Intermittent, with the USB-C monitor/hub connected. Several successful cycles may occur before failure.

Additional reproductions and correction regarding affected kernel versions:

The failure originally reported occurred on kernel 7.1.3-101.fc43.x86_64.

Since filing the report, I have reproduced the same externally visible failure twice more:

1. Kernel 7.1.5-101.fc43.x86_64
2. Kernel 7.0.12-101.fc43.x86_64

In both new cases:

* the Dell P2725QE USB-C monitor/hub was connected
* suspend was requested
* the laptop’s power-button LED remained solid instead of entering its normal breathing pattern
* the system would not wake, including after disconnecting the monitor
* a forced power-off was required

For both new failures, systemd initiated suspend and the final recorded kernel message was:

```
PM: suspend entry (s2idle)
```

There was no subsequent “PM: suspend exit” message or completion of systemd-suspend.service.

The 7.1.5 failure is a new reproduction on a newer kernel than the originally reported 7.1.3 failure.

Before the 7.0.12 failure, I had successfully completed three consecutive suspend/resume tests on 7.0.12 and therefore provisionally considered it a known-good workaround. The problem has now occurred on 7.0.12 as well, so that conclusion was incorrect. The issue is intermittent: multiple suspend/resume cycles may succeed before a later attempt hangs.

Confirmed affected kernels are now:

* 7.0.12-101.fc43.x86_64
* 7.1.3-101.fc43.x86_64
* 7.1.5-101.fc43.x86_64

Consequently, the available evidence does not isolate this to a regression introduced between 7.0.12 and 7.1.3, and no known-good kernel has currently been established.

The original 7.1.3 failure occurred with BIOS 04.04. The two newer failures occurred with BIOS 04.05, so the BIOS update did not eliminate the problem.

Suspend continues to work normally in my testing when the USB-C monitor is disconnected before requesting suspend.

I am attaching sanitized kernel and suspend-context logs from the new 7.1.5 and 7.0.12 failures, together with a summary of those two events. The original report and its earlier logs cover the 7.1.3 failure.

08/08/2026 update:
Correction and additional reproduction on kernel 7.1.6:

My preceding comment interpreted the final “PM: suspend entry (s2idle)” message as evidence that the newer failures hung while entering suspend. Based on closer recollection of the laptop’s power LED, that conclusion was too definite.

For the newest failure, on kernel 7.1.6-101.fc43.x86_64, the laptop’s power LED was breathing normally before I attempted to wake it. This indicates that it had entered s2idle. When I pressed a key on the laptop keyboard, the machine did not return to the existing session; it instead proceeded to Fedora’s kernel-selection boot menu without my pressing the power button.

The Dell P2725QE remained connected over USB-C throughout suspend and wake and was providing display, USB hub functionality, and power delivery. Ethernet was connected directly to the laptop.

The failed 7.1.6 boot is boot ID:

```
6fad2baacb454d73aa4700b94fe6ee74
```

Six suspend/resume cycles completed successfully earlier during the same boot. The sixth successful suspension lasted approximately 5½ hours. Fifteen minutes after that successful resume, another suspend was requested at 2026-08-07 19:29:39. The final recorded message was:

```
PM: suspend entry (s2idle)
```

No resume messages were recorded after that attempt. The following boot began with the same kernel and reported:

```
x86/amd: Previous system reset reason [0x01000800]: system failed to boot before failed boot timer expired
```

There was no pstore record of a kernel panic.

Kernel 7.1.6 can suspend and resume successfully multiple times, so the problem is intermittent, but this event shows that 7.1.6 is not a complete fix.

I also want to qualify my description of the earlier 7.0.12 and 7.1.5 incidents. I believe that at least some—and probably most—of those incidents also involved the LED breathing normally, followed by a reboot or reset when wake was attempted. I am not sufficiently certain about the LED state in each earlier event to classify every one conclusively. The initial deliberately reproduced incidents did include failure to enter suspend, with a solid LED.

Therefore, the evidence currently suggests two observed symptom variants:

1. Failure to enter suspend, with the power LED remaining solid.
2. Apparently successful suspend, with a breathing LED, followed by an intermittent reset or fresh boot when wake is attempted.

A journal ending at “PM: suspend entry (s2idle)” is compatible with either case if the machine resets before the resumed kernel can write additional messages.

The 7.1.6 logs also contain recurring amdgpu display warnings involving dcn31_program_compbuf_size and UCSI errors, but there is not enough evidence to identify either as the cause of the final reset. I will attach sanitized kernel logs from the failed boot and the immediately following boot.