Comment # 33
on bug 103370
from Alex Deucher
(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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
