[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=103370

--- Comment #33 from Alex Deucher <alexdeucher at gmail.com> ---
(In reply to Michel Dänzer from comment #27)
> Thanks for bisecting, but I don't think that commit can be directly
> responsible for a GPU hang. Before that commit, the DRI3 code in Mesa would
> only use one back buffer for glxgears, which means that the GPU could only
> start rendering a new frame after the previous one had finished presenting.
> Maybe that somehow prevented the hang.

That commit "fixed" a performance regression at the time because it ended up
causing enough of a delay that the clocks didn't ramp up.  So it probably
exposed a kernel dpm issue.  Without it, the clocks never ramped up enough to
cause an issue.  With it, they did.


(In reply to Timo Aaltonen from comment #32)
> forwarding a comment from an engineer:
> 
> "During viewing the source code of radeon module, I found there is a bug [1]
> related to the dpm and clocks. So I decided to do some experiments.
> Tried to set different max_sclk and max_mclk to see if the issue is gone.
> 1. max_sclk: 70000, max_mclk: 75000 --> have the same issue
> 2. max_sclk: 50000, max_mclk: 60000 --> pass multi-run test (more than 50
> runs)
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=76490
> "

I think Sonny fixed this.  It was due to using the wrong firmware.
[    1.827060] [drm] initializing kernel modesetting (HAINAN 0x1002:0x6665
0x1028:0x0844 0xC3).  This chip should be using radeon/banks_k_2_smc.bin smc
firmware.  Is that available on the test system and kernel?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20171120/cf100cc9/attachment.html>