Random window resizing on MSI MS-158K laptops: a Rocky Linux fix

1. Problem

On MSI gaming laptops built on the MS-158K motherboard and running Rocky Linux 9 or 10, all open windows shrink briefly at random intervals and then snap back to their original size. There is no obvious trigger and the timing is irregular. The board carries two AMD GPUs: a Radeon Vega (Cezanne) integrated GPU at 0000:07:00.0 which drives the built-in screen, and a discrete Radeon RX 5500M (Navi 14) at 0000:03:00.0 which has no connected display output. The only trace left in the kernel log is:

[19809.613998] [drm] kiq ring mec 2 pipe 1 q 0
[19809.616987] amdgpu 0000:03:00.0: [drm] Cannot find any crtc or sizes
[19809.617003] amdgpu 0000:03:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
... (full ring reinitialization output)
[19809.620157] amdgpu 0000:03:00.0: [drm] Cannot find any crtc or sizes

2. Diagnosis

Step 1: Identify which GPU owns the display

The MS-158K board carries two AMD GPUs: a Radeon RX 5500M discrete GPU and a Radeon Vega integrated GPU. Check which DRM card has a connected output:

for card in /sys/class/drm/card*/; do
  echo "$card: $(cat ${card}*/status 2>/dev/null | sort -u)"
done

The output should look like this:

/sys/class/drm/card0/: disconnected   ← Radeon RX 5500M, PCI 0000:03:00.0, no display
/sys/class/drm/card1/: connected      ← Radeon Vega, PCI 0000:07:00.0, eDP-1 built-in screen

card0 is the Radeon RX 5500M with no connected output. card1 is the Radeon Vega driving the laptop's built-in screen.

Step 2: Correlate the log pattern

Expanding the dmesg context around each occurrence of the log message reveals a consistent pattern appearing immediately before every window disruption:

sudo dmesg | grep -B 20 "kiq ring mec"

Every occurrence follows this sequence:

[  55.515940] pci_bus 0000:03: Allocating resources        ← dGPU waking from suspend
[  55.515971] amdgpu 0000:03:00.0: amdgpu: PSP is resuming...
[  55.753346] amdgpu 0000:03:00.0: amdgpu: SMU is resumed successfully!
[  55.754555] [drm] kiq ring mec 2 pipe 1 q 0              ← full GPU reinit
[  55.757627] amdgpu 0000:03:00.0: [drm] Cannot find any crtc or sizes
...

The line pci_bus 0000:03: Allocating resources appears immediately before every resume cycle, confirming that the kernel PCI bus is repeatedly reallocating resources as the dGPU wakes from the D3 (powered-off) power state.

Step 3: Confirm the power management state

cat /sys/bus/pci/devices/0000:03:00.0/power/control
cat /sys/bus/pci/devices/0000:03:00.0/power/runtime_status

This confirms the dGPU is under auto runtime power management, causing it to cycle between suspended and active states repeatedly.

3. Root cause

The Radeon RX 5500M at PCI address 0000:03:00.0 is repeatedly suspended and resumed by the kernel's PCI runtime power management. Each time it resumes, the kernel fires a DRM hotplug event. The Wayland compositor (GNOME Shell) reacts to that hotplug event by briefly reconfiguring the display state — which causes all windows to shrink momentarily and then restore once the compositor determines that no display change has actually taken place.

The Cannot find any crtc or sizes message is a consequence, not the cause: the Radeon RX 5500M has no connected display outputs on the MS-158K, so every time the driver queries for CRTCs after resuming, it finds none.

4. Solution

Stop the Radeon RX 5500M from entering runtime suspend by setting its power control to on.

Step 1: Test immediately (no reboot required)

echo "on" > /sys/bus/pci/devices/0000:03:00.0/power/control

If the window shrinking stops after running this command, the diagnosis is confirmed.

Step 2: Make the fix permanent via udev

A udev rule ensures the setting is applied automatically on every boot. Using the vendor ID (0x1002, AMD) and device ID (0x7340, Navi 14) is more reliable than matching on the PCI address alone, as the address can vary between kernels and firmware revisions:

cat > /etc/udev/rules.d/99-dgpu-pm.rules << 'EOF'
SUBSYSTEM=="pci", ATTR{vendor}=="0x1002", ATTR{device}=="0x7340", ATTR{power/control}="on"
EOF

Apply the rule without rebooting:

udevadm control --reload-rules
udevadm trigger

Step 3: Verify

cat /sys/bus/pci/devices/0000:03:00.0/power/control

Expected output:

on

Watch dmesg to confirm the resume cycles have stopped:

sudo dmesg -w | grep -E "Allocating resources|PSP is resuming|kiq ring"

No further output should appear once the fix is in place.

5. Notes

  • This issue has been observed on MSI gaming laptops based on the MS-158K motherboard running Rocky Linux 9 and 10. The board pairs a Radeon Vega (Cezanne) integrated GPU with a Radeon RX 5500M (Navi 14) discrete GPU. The discrete GPU has no connected display output and is left under automatic PCI power management by default, which triggers the problem.
  • The udev rule matches on the AMD vendor ID (0x1002) and the Navi 14 device ID (0x7340). This is more dependable than matching on the PCI address 0000:03:00.0, which could in principle shift between firmware updates. To find the correct IDs on another machine, run lspci -nn | grep -i vga and read the [vendor:device] values from the output.
  • Setting power control to on stops the Radeon RX 5500M from sleeping, which raises idle power consumption slightly and may reduce battery life a little. If this is a concern and the GPU is never used for rendering, blacklisting the amdgpu module for that device is an alternative — though this requires some care to avoid affecting the Radeon Vega.
  • If tlp or power-profiles-daemon is installed, it may override the udev rule after boot. Check with systemctl status tlp power-profiles-daemon. Should overriding occur, a systemd service with After=tlp.service (or the relevant daemon) can re-apply the setting, following the same approach described in the Bluetooth dongle fix post.
  • The symptom — all windows shrinking briefly then snapping back — is easy to mistake for a window manager fault, a compositor bug, or a monitoring tool accidentally resizing windows. The key diagnostic clue is the pci_bus: Allocating resources line in dmesg appearing immediately before each window disruption.