[RESPONDED] dGPU lockup from rear USB port

[Daniel_I]

Thanks for the response @Matt_Hartley , just getting back from vacation, and I’d like to clarify my understanding of the information you’ve provided.

My understanding is that tools like nvtop, tickling the dGPU sysfs files, etc all serve to bring the dGPU out of sleep/D3Cold. If that’s related to the bug you’ve mentioned, then I think I’ve worked around it by adding amdgpu.runpm=0 to GRUB_CMDLINE_LINUX_DEFAULT to prevent the dGPU from sleeping… that said I can see how your solution/workaround could be attractive to @jared_kidd who didn;t want to disable dGPU sleep entirely.

Is the bug currently directly relayed to the dGPU sleep, or only when using the FW HDMI/DP modules to plug into the dGPU port? Just trying to understand what you are referring to as “slow”.

I have picked up a USB-C to DP cable (and have ordered a USB-C to HDMI cable as my monitor’s DP port recently died) which hopefully works around the bug you mentioned (cable not being “slow” like the module); however, I’m currently avoiding the dGPU USB-C port as games do not render properly (or at all) when connected to it.

@Daniel_I

So from this point forward, I’d like to focus on the initial issue… dGPU port has issues when I try connect my DP monitor to it.

1. Within an x11 session, it’s output appears to be forced to the left and working within an invisible box equal to the DP monitor width (the dimensions of the monitor connected to it)… move the game to the right, and it stops rendering at the right edge of that invisible box. When my DP monitor was on the left this worked out… but once I moved the DP monitor to the right, forcing left was revealed, and is a problem (in X11).
2. Within a Wayland session it appears that steam games (run via proton) load blank/black. based on the journal entries provided, this starts with a kwin_wayland_drmerror immediately when a connection is made on the dGPU port, after you launch a game that loads blank, the journal fills with additional kwin_wayland_drm and drm:amdgpu_dm_plane_helper_prepare_fb [amdgpu] messages.

Regardless of which session is launched, the issue can be worked-around by moving the DP cannection to the side iGPU port… which is not a solution to using the dGPU port directly and suffers (based on what I read) a 10% performance hit.

That said I have yet to retest the state of things with my recent plasma6 update and/or latest 6.8/6.9 kernels… the joys of bleeding edge hardware with linux.

EDIT: My new USB-C HDMI cable arrived today so I thought I’d try scenario #1 above… same issue under plasma 6 as plasma 5 with the cable plugged directy to the dGPU; no issues plugged into side USB-C module (iGPU).

Didn’t test under wayland as it has problems with gamescope, so not an option for me at this time.

[Matt_Hartley]

@Matt_Hartley

Connecting dGPU to the external display using dGPU port on the back? If this is what you are looking to do, there is a bug where the external display remains black ONLY when connected to the dGPU USB-C slow (HDMI or DP expansion card).

@Daniel_I

My understanding is that tools like nvtop, tickling the dGPU sysfs files, etc all serve to bring the dGPU out of sleep/D3Cold. If that’s related to the bug you’ve mentioned, then I think I’ve worked around it by adding amdgpu.runpm=0 to GRUB_CMDLINE_LINUX_DEFAULT to prevent the dGPU from sleeping… that said I can see how your solution/workaround could be attractive to @jared_kidd who didn;t want to disable dGPU sleep entirely.

Appreciate the update. Need to clarify this is what we are doing, correct? Where is this being plugged into. My script was ONLY for the very back where the dGPU is attached. If it is for this area only, then yes, it wakes the dGPU up for use.

For any other ports, you would follow the outline here. And if using those supported ports as shown, it would be with expansion cards.

It’s also very important to note that you do not need to connect directly to the dGPU in the back to activate the dGPU. DRI_PRIME=1 will do that for you in any of the supported expansion bays.

Honestly, the absolute dead simplest approach here is to use Bazzite. GPU switching is just handled. It has a KDE option, too. We work closely with the developers there and this may make for a far, far easier experience for you.

[jared_kidd]

@Matt_Hartley

My script was ONLY for the very back where the dGPU is attached. If it is for this area only, then yes, it wakes the dGPU up for use.

Your script has been working fine as a workaround for me. Still have to reboot after I disconnect if I want the dGPU to ever go asleep again. But it’s at least usable.

Could you provide any update on when we will receive a fix for the actual bug?

[Mango]

I have almost the same issue, but instead of an external display I have… The Framework power adapter! In my case the adapter is plugged into rear left or rear right(1 and 4 on the FW16 port sheet) ports. If I plug the adapter in while the dGPU is in D3cold, the dGPU fails, producing a lot of logs about the crash. From my understanding, the dGPU times out.

If I boot with the power adapter plugged in, then the GPU stays in D0 until I unplug the adapter and fails again when the adapter is back in.

If, before plugging the adapter in(in any of the two three? cases), I force the dGPU into D0, then everything works like it should. I.E. the power adapter does not cause my GPU to fail.

Edit: The dGPU stays in D0 while the adapter is plugged in no matter what.

Edit 2: Plugging in my multipurpose adapter into these ports does not crash the GPU

This works

Edit 3: Plugging the power adapter into my multipurpose adapter does crash the GPU

This doesn’t

Edit 4: Fedora 40 doesn’t have this problem somehow…

[jared_kidd]

Posting in here again so it doesn’t get auto-locked.

This is still an issue and causes my laptop to lock on occasion when i disconnect/connect external monitors. Does Framework have any plans to work on this bug?