<div dir="ltr">Hi Michel,<div><br></div><div>(Just for other readers my reply has been delayed on the mailing lists and should have been on second position)</div><div><br></div><div>We have actually spotted this /0/i/ but somehow I convinced myself it was intentional. The reason I found was that you wanted to set the fpfn only if there is 2 placements, which means it will try to move from accessible to inaccessible.</div><div><br></div><div>I will have a go with that change and let you know. I do not remember if I tried it for this soft lockup. But for sure it does not solve the hard lockup that Zach also mentioned at the end of his reply. I am saying that because this other issue has some similarities (same ioctl call).</div><div><br></div><div><span style="font-size:12.8px">But in general, isn't "radeon_lockup_timeout" supposed to detect this situation ?</span><br></div><div><br></div><div>Thx</div><div>Julien</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 March 2017 at 09:24, Michel Dänzer <span dir="ltr"><<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 23/03/17 06:26 PM, Julien Isorce wrote:<br>
> Hi Michel,<br>
><br>
> When it happens, the main thread of our gl based app is stuck on a<br>
> ioctl(RADEON_CS). I set RADEON_THREAD=false to ease the debugging but<br>
> same thing happens if true. Other threads are only si_shader:0,1,2,3 and<br>
> are doing nothing, just waiting for jobs. I can also do sudo gdb -p<br>
> $(pidof Xorg) to block the X11 server, to make sure there is no ping<br>
> pong between 2 processes. All other processes are not loading<br>
> dri/radeonsi_dri.so . And adding a few traces shows that the above ioctl<br>
> call is looping for ever on<br>
> <a href="https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/ttm/ttm_bo.c#L819" rel="noreferrer" target="_blank">https://github.com/torvalds/<wbr>linux/blob/master/drivers/gpu/<wbr>drm/ttm/ttm_bo.c#L819</a><br>
> <<a href="https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/ttm/ttm_bo.c#L819" rel="noreferrer" target="_blank">https://github.com/torvalds/<wbr>linux/blob/master/drivers/gpu/<wbr>drm/ttm/ttm_bo.c#L819</a>> and<br>
> comes from<br>
> mesa <a href="https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/radeon/drm/radeon_drm_cs.c#n454" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/<wbr>mesa/mesa/tree/src/gallium/<wbr>winsys/radeon/drm/radeon_drm_<wbr>cs.c#n454</a><br>
> .<br>
><br>
> After adding even more traces I can see that the bo, which is being<br>
> indefinitely evicted, has the flag RADEON_GEM_NO_CPU_ACCESS.<br>
> And it gets 3 potential placements after calling "radeon_evict_flags".<br>
>  1: VRAM cpu inaccessible, fpfn is 65536<br>
>  2: VRAM cpu accessible, fpfn is 0<br>
>  3: GTT, fpfn is 0<br>
><br>
> And it looks like it continuously succeeds to move on the second<br>
> placement. So I might be wrong but it looks it is not even a ping pong<br>
> between VRAM accessible / not accessible, it just keeps being blited in<br>
> the CPU accessible part of the VRAM.<br>
<br>
</div></div>Thanks for the detailed description! AFAICT this can only happen due to<br>
a silly mistake I made in this code. Does this fix it?<br>
<br>
diff --git a/drivers/gpu/drm/radeon/<wbr>radeon_ttm.c b/drivers/gpu/drm/radeon/<wbr>radeon_ttm.c<br>
index 5c7cf644ba1d..37d68cd1f272 100644<br>
--- a/drivers/gpu/drm/radeon/<wbr>radeon_ttm.c<br>
+++ b/drivers/gpu/drm/radeon/<wbr>radeon_ttm.c<br>
@@ -213,8 +213,8 @@ static void radeon_evict_flags(struct ttm_buffer_object *bo,<br>
                        rbo->placement.num_busy_<wbr>placement = 0;<br>
<span class="">                        for (i = 0; i < rbo->placement.num_placement; i++) {<br>
</span><span class="">                                if (rbo->placements[i].flags & TTM_PL_FLAG_VRAM) {<br>
-                                       if (rbo->placements[0].fpfn < fpfn)<br>
-                                               rbo->placements[0].fpfn = fpfn;<br>
</span>+                                       if (rbo->placements[i].fpfn < fpfn)<br>
+                                               rbo->placements[i].fpfn = fpfn;<br>
                                } else {<br>
                                        rbo->placement.busy_placement =<br>
                                                &rbo->placements[i];<br>
<span class="im HOEnZb"><br>
<br>
<br>
--<br>
Earthling Michel Dänzer               |               <a href="http://www.amd.com" rel="noreferrer" target="_blank">http://www.amd.com</a><br>
Libre software enthusiast             |             Mesa and X developer<br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
dri-devel mailing list<br>
<a href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.<wbr>org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/dri-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/dri-devel</a><br>
</div></div></blockquote></div><br></div>