Bug 77244

Are you sure you are using the right RLC firmware?

Re: RLC firmware: I'm not sure, I'm using whatever Debian packages with Sid, and I have to imagine they're doing a better job than I would, so yes?

How can I tell?

What is the output of "md5sum /lib/firmware/radeon/PITCAIRN_rlc.bin"?

/lib/firmware/radeon/PITCAIRN_rlc.bin has md5 hash 3d2c150b3626419131bbc9a5864c7f1d

$ md5sum /lib/firmware/radeon/PITCAIRN_* /lib/firmware/radeon/TAHITI_uvd.bin 
a5f07f65a9ef260c0077021ecae43dc7  /lib/firmware/radeon/PITCAIRN_ce.bin
96b18c6f7c74ad4cecb04fca967ca433  /lib/firmware/radeon/PITCAIRN_mc.bin
5e899b3ff3e128453784b8fdacb947bb  /lib/firmware/radeon/PITCAIRN_me.bin
6a1f860df54aa4d462339322ba363092  /lib/firmware/radeon/PITCAIRN_pfp.bin
3d2c150b3626419131bbc9a5864c7f1d  /lib/firmware/radeon/PITCAIRN_rlc.bin
b4b17dd30f14ceab88446c20796767d5  /lib/firmware/radeon/PITCAIRN_smc.bin
201877fa59f2fe4d896d5e6b6c1d2e1c  /lib/firmware/radeon/TAHITI_uvd.bin

(In reply to comment #4)
> /lib/firmware/radeon/PITCAIRN_rlc.bin has md5 hash
> 3d2c150b3626419131bbc9a5864c7f1d

That's the right one, so it isn't an issue with the firmware.

(In reply to comment #0)
> Created attachment 97143 [details]
> Linux kernel log
> 
> I have a Clevo P150SM based laptop with an Intel HD 4600 iGPU and an AMD
> Radeon HD 8970M dGPU.  I receive the following errors when the Radeon
> DRI/DRM implementation attempts to initialize the card:
> 
> [   65.525470] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   66.537637] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   67.549797] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   68.561967] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   69.574142] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   70.586334] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   71.598533] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   72.610705] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   73.622877] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   74.635068] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to
> reset the VCPU!!!
> [   74.654938] [drm:uvd_v1_0_start] *ERROR* UVD not responding, giving up!!!
> [   74.654955] [drm:si_startup] *ERROR* radeon: failed initializing UVD (-1).
> 
> 
> This appears to happen on video mode changes or vtty changes, I'm not
> quite sure really what triggers it other than initial loading.  When it
> does occur, the system appears to hang for a short time (15 seconds or
> so) while the dGPU is active, and then "comes back" after the dGPU is
> disabled.  The Clevo P150SM has an LED showing the dGPU power state,
> and debugfs/vgaswitcheroo seems to corroborate this.
> 
> I'm also experiencing issues with PRIME (and e.g. xserver seg-faults when
> building from source to try new code), but this issue exists out of the box
> on Debian Sid, and seems to persist even with newer Mesa and DRM.  I have a
> bug report for the PRIME/hybrid graphics issue as well, and it may end up
> that these are related: https://bugs.freedesktop.org/show_bug.cgi?id=77094
> 
> Finally, this bug looks similar to mine, though I am not messing with PRIME
> (at least explicitly; no xrandr --setprovider* calls and no DRI_PRIME env.
> var. is set): https://bugs.freedesktop.org/show_bug.cgi?id=75234


It is definitely the duplicate of this bug https://bugs.freedesktop.org/show_bug.cgi?id=75234 .
These error messages appear even without using dGPU just after its initialization. And firmware is also up-to-date.
> There is a downstream bug report here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743659

(In reply to comment #6)
> It is definitely the duplicate of this bug
> https://bugs.freedesktop.org/show_bug.cgi?id=75234 .

I'm not so sure.  On bug 75234, the UVD initialization only fails after a runtime power management event, while in this case, it fails right from the start.

For this bug, does disabling runtime power management help?  Try appending radeon.runpm=0 to the kernel command line in grub.

Booting with radeon.runpm=0 produces slightly different results.  The card doesn't power down ("dGPU LED" is on now), and I still have the UVD error logging, but just once this time; switching vttys does not cause the logging again.  As well, the "hang" is much reduced or completely gone when switching vttys: switching from a "graphic" (not sure of the proper terms) vtty to any console-vtty has a very small delay, but switching to a "graphic" vtty does not.

As well, I tried render offload with radeon.runpm=0, and that still crashes X, but there is no radeon/UVD/DRM logging from the kernel like the was prior.

Created attachment 97157 [details]
Linux kernel log -- radeon.runpm=0

Is there anything else I can do to help get this resolved?

This bug seems resolved for me in 3.14.4.  UVD initializes fine.  PRIME is still having issues, though.