Confirming this regression with a second, distinct manifestation and a
reproducible trigger.

Same environment:
- linux-firmware 0ubuntu2.29 (regressed) vs 0ubuntu2.26 (working)
- DMCUB/DMUB firmware: 0x09002C01 (0ubuntu2.26) -> 0x09000D00 (0ubuntu2.29),
  verified by hexdump of /lib/firmware/amdgpu/dcn_3_5_dmcub.bin — version
  field at offset 0x10: 01 2c 00 09 (0x09002C01) vs 00 0d 00 09 (0x09000D00).
- AMD DCN 3.5 / Strix Point (gfx1150), kernel 6.17.0-1032-oem.

Where this differs from the reported SDMA0 Oops: on my machine the
regression shows up as a DMUB soft-lockup in the ABM set_pipe path, not an
SDMA0 fence timeout. Trigger is reproducible (intermittent, not every
time): play a YouTube video in Firefox, send Firefox to the background,
then Alt-Tab to bring it back to the foreground. The GUI freezes and the
watchdog fires:

  watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [kworker/u64:2]
  Workqueue: events_unbound commit_work
  RIP: amdgpu_device_rreg+0xf1/0x120 [amdgpu]
   dmub_dcn35_get_inbox1_rptr+0x20/0x30 [amdgpu]
   dmub_srv_update_inbox_status+0x4e/0x150 [amdgpu]
   dmub_srv_wait_for_idle+0x82/0xc0 [amdgpu]            # spinning
   dc_dmub_srv_wait_for_idle+0x70/0x1d0 [amdgpu]
   dc_wake_and_execute_dmub_cmd+0x18/0x30 [amdgpu]
   dmub_abm_set_pipe+0x75/0xb0 [amdgpu]                 # hanging DMUB cmd
   dmub_abm_set_pipe_ex+0xb9/0xc0 [amdgpu]
   dcn21_set_pipe+0x96/0x130 [amdgpu]
   dcn20_program_pipe+0x3f7/0x4f0 [amdgpu]
   commit_planes_for_stream+0x8ae/0x17f0 [amdgpu]       # compositor plane 
commit
   amdgpu_dm_commit_planes+0x5e3/0x1740 [amdgpu]
   amdgpu_dm_atomic_commit_tail+0xb04/0x1270 [amdgpu]
   commit_tail / commit_work

Mechanism: YouTube keeps the display pipeline updating so ABM is active;
the Alt-Tab focus change makes the compositor issue a plane commit that
sends DMUB_CMD__ABM_SET_PIPE. In firmware 0x09000D00 that command's inbox1
read-pointer never advances, so dmub_srv_wait_for_idle spins.

Notes that may help triage:
- The kernel is NOT the variable: 6.17.0-1032-oem ran 5 boots with the old
  firmware (0x09002C01) and never hung. All hangs start at the first boot
  after the 0ubuntu2.29 upgrade. Booting an older kernel does NOT help,
  because the firmware file is shared across kernels.
- amdgpu.abmlevel=0 (already set) does NOT prevent it: disabling ABM is
  itself done by sending dmub_abm_set_pipe, so the command is issued
  regardless. No dcdebugmask/dcfeaturemask bit targets this path.
- Workaround confirmed: revert dcn_3_5_dmcub.bin (+ dcn_3_5_1_dmcub.bin)
  to the 0ubuntu2.26 blobs (0x09002C01) and apt-mark hold linux-firmware.

Happy to attach full journal excerpts / the decompressed firmware sha256
(0x09002C01: ce5dc8ef543ce71a0ef772d4d821872fbfaa48afd0634e00f814e04ed991c431,
 0x09000D00: 3849f6e2dd33c24977254f486710be9ee8f51fb5dad4b442444e119ced0c55d5)
if useful.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2163311

Title:
  linux-firmware 0ubuntu2.29 regresses DMCUB on DCN 3.5 (Strix Point)
  causing SDMA0 fence timeout and kernel Oops

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/2163311/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to