Control: tag -1 upstream moreinfo On Wed, 2014-04-09 at 11:07 +0200, Julien Cristau wrote: > Control: reassign -1 src:linux 3.13.7-1 > > On Fri, Apr 4, 2014 at 14:45:47 -0500, Nathan Schulte wrote: > > > Source: libdrm-radeon1 > > Severity: normal > > > > 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). Please report this upstream at https://bugs.freedesktop.org under product 'DRI', component 'DRM/Radeon'. Let us know the URL for the bug report so we can track it. > > Earlier on in the log I see this interesting output: > > [ 15.930532] [drm] GPU not posted. posting now... > > [ 15.933770] radeon 0000:01:00.0: VRAM: 4096M 0x0000000000000000 - 0x00000000FFFFFFFF (4096M used) > > [ 15.934639] radeon 0000:01:00.0: GTT: 1024M 0x0000000100000000 - 0x000000013FFFFFFF > > [ 15.935484] [drm] Detected VRAM RAM=4096M, BAR=256M > > [ 15.936327] [drm] RAM width 256bits DDR > > [ 15.940586] [drm] radeon: 4096M of VRAM memory ready > > [ 15.941394] [drm] radeon: 1024M of GTT memory ready. > > [ 15.942210] [drm] Loading PITCAIRN Microcode > > [ 15.966837] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_pfp.bin > > [ 15.976695] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_me.bin > > [ 15.996448] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_ce.bin > > [ 16.015403] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_rlc.bin > > [ 16.016529] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_mc.bin > > [ 16.026910] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_smc.bin > > [ 16.045744] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/TAHITI_uvd.bin > > > > Why is the Radeon DRI loading TAHITI_uvd.bin for the card when it loads > > PITCAIRN for everything else? [...] Probably because this logic block is shared across more chips than the others. Ben. -- Ben Hutchings All extremists should be taken out and shot.
Attachment:
signature.asc
Description: This is a digitally signed message part