<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 3, 2023, 14:53 André Almeida <<a href="mailto:andrealmeid@igalia.com">andrealmeid@igalia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Em 03/05/2023 14:08, Marek Olšák escreveu:<br>
> GPU hangs are pretty common post-bringup. They are not common per user, <br>
> but if we gather all hangs from all users, we can have lots and lots of <br>
> them.<br>
> <br>
> GPU hangs are indeed not very debuggable. There are however some things <br>
> we can do:<br>
> - Identify the hanging IB by its VA (the kernel should know it)<br>
<br>
How can the kernel tell which VA range is being executed? I only found <br>
that information at mmCP_IB1_BASE_ regs, but as stated in this thread by <br>
Christian this is not reliable to be read.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The kernel receives the VA and the size via the CS ioctl. When user queues are enabled, the kernel will no longer receive them.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> - Read and parse the IB to detect memory corruption.<br>
> - Print active waves with shader disassembly if SQ isn't hung (often <br>
> it's not).<br>
> <br>
> Determining which packet the CP is stuck on is tricky. The CP has 2 <br>
> engines (one frontend and one backend) that work on the same command <br>
> buffer. The frontend engine runs ahead, executes some packets and <br>
> forwards others to the backend engine. Only the frontend engine has the <br>
> command buffer VA somewhere. The backend engine only receives packets <br>
> from the frontend engine via a FIFO, so it might not be possible to tell <br>
> where it's stuck if it's stuck.<br>
<br>
Do they run at the same asynchronously or does the front end waits the <br>
back end to execute?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">They run asynchronously and should run asynchronously for performance, but they can be synchronized using a special packet (PFP_SYNC_ME).</div><div dir="auto"><br></div><div dir="auto">Marek</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> <br>
> When the gfx pipeline hangs outside of shaders, making a scandump seems <br>
> to be the only way to have a chance at finding out what's going wrong, <br>
> and only AMD-internal versions of hw can be scanned.<br>
> <br>
> Marek<br>
> <br>
> On Wed, May 3, 2023 at 11:23 AM Christian König <br>
> <<a href="mailto:ckoenig.leichtzumerken@gmail.com" target="_blank" rel="noreferrer">ckoenig.leichtzumerken@gmail.com</a> <br>
> <mailto:<a href="mailto:ckoenig.leichtzumerken@gmail.com" target="_blank" rel="noreferrer">ckoenig.leichtzumerken@gmail.com</a>>> wrote:<br>
> <br>
>  Â  Â Am 03.05.23 um 17:08 schrieb Felix Kuehling:<br>
>  Â  Â  > Am 2023-05-03 um 03:59 schrieb Christian König:<br>
>  Â  Â  >> Am 02.05.23 um 20:41 schrieb Alex Deucher:<br>
>  Â  Â  >>> On Tue, May 2, 2023 at 11:22 AM Timur Kristóf<br>
>  Â  Â  >>> <<a href="mailto:timur.kristof@gmail.com" target="_blank" rel="noreferrer">timur.kristof@gmail.com</a> <mailto:<a href="mailto:timur.kristof@gmail.com" target="_blank" rel="noreferrer">timur.kristof@gmail.com</a>>> wrote:<br>
>  Â  Â  >>>> [SNIP]<br>
>  Â  Â  >>>>>>>> In my opinion, the correct solution to those problems would be<br>
>  Â  Â  >>>>>>>> if<br>
>  Â  Â  >>>>>>>> the kernel could give userspace the necessary information<br>
>  Â  Â about<br>
>  Â  Â  >>>>>>>> a<br>
>  Â  Â  >>>>>>>> GPU hang before a GPU reset.<br>
>  Â  Â  >>>>>>>><br>
>  Â  Â  >>>>>>> Â  The fundamental problem here is that the kernel doesn't have<br>
>  Â  Â  >>>>>>> that<br>
>  Â  Â  >>>>>>> information either. We know which IB timed out and can<br>
>  Â  Â  >>>>>>> potentially do<br>
>  Â  Â  >>>>>>> a devcoredump when that happens, but that's it.<br>
>  Â  Â  >>>>>><br>
>  Â  Â  >>>>>> Is it really not possible to know such a fundamental thing<br>
>  Â  Â as what<br>
>  Â  Â  >>>>>> the<br>
>  Â  Â  >>>>>> GPU was doing when it hung? How are we supposed to do any<br>
>  Â  Â kind of<br>
>  Â  Â  >>>>>> debugging without knowing that?<br>
>  Â  Â  >><br>
>  Â  Â  >> Yes, that's indeed something at least I try to figure out for years<br>
>  Â  Â  >> as well.<br>
>  Â  Â  >><br>
>  Â  Â  >> Basically there are two major problems:<br>
>  Â  Â  >> 1. When the ASIC is hung you can't talk to the firmware engines any<br>
>  Â  Â  >> more and most state is not exposed directly, but just through some<br>
>  Â  Â  >> fw/hw interface.<br>
>  Â  Â  >> Â Â Â  Just take a look at how umr reads the shader state from the SQ.<br>
>  Â  Â  >> When that block is hung you can't do that any more and basically<br>
>  Â  Â have<br>
>  Â  Â  >> no chance at all to figure out why it's hung.<br>
>  Â  Â  >><br>
>  Â  Â  >> Â Â Â  Same for other engines, I remember once spending a week<br>
>  Â  Â figuring<br>
>  Â  Â  >> out why the UVD block is hung during suspend. Turned out to be a<br>
>  Â  Â  >> debugging nightmare because any time you touch any register of that<br>
>  Â  Â  >> block the whole system would hang.<br>
>  Â  Â  >><br>
>  Â  Â  >> 2. There are tons of things going on in a pipeline fashion or even<br>
>  Â  Â  >> completely in parallel. For example the CP is just the beginning<br>
>  Â  Â of a<br>
>  Â  Â  >> rather long pipeline which at the end produces a bunch of pixels.<br>
>  Â  Â  >> Â Â Â  In almost all cases I've seen you ran into a problem somewhere<br>
>  Â  Â  >> deep in the pipeline and only very rarely at the beginning.<br>
>  Â  Â  >><br>
>  Â  Â  >>>>>><br>
>  Â  Â  >>>>>> I wonder what AMD's Windows driver team is doing with this<br>
>  Â  Â problem,<br>
>  Â  Â  >>>>>> surely they must have better tools to deal with GPU hangs?<br>
>  Â  Â  >>>>> For better or worse, most teams internally rely on scan dumps via<br>
>  Â  Â  >>>>> JTAG<br>
>  Â  Â  >>>>> which sort of limits the usefulness outside of AMD, but also<br>
>  Â  Â gives<br>
>  Â  Â  >>>>> you<br>
>  Â  Â  >>>>> the exact state of the hardware when it's hung so the<br>
>  Â  Â hardware teams<br>
>  Â  Â  >>>>> prefer it.<br>
>  Â  Â  >>>>><br>
>  Â  Â  >>>> How does this approach scale? It's not something we can ask<br>
>  Â  Â users to<br>
>  Â  Â  >>>> do, and even if all of us in the radv team had a JTAG device, we<br>
>  Â  Â  >>>> wouldn't be able to play every game that users experience<br>
>  Â  Â random hangs<br>
>  Â  Â  >>>> with.<br>
>  Â  Â  >>> It doesn't scale or lend itself particularly well to external<br>
>  Â  Â  >>> development, but that's the current state of affairs.<br>
>  Â  Â  >><br>
>  Â  Â  >> The usual approach seems to be to reproduce a problem in a lab and<br>
>  Â  Â  >> have a JTAG attached to give the hw guys a scan dump and they can<br>
>  Â  Â  >> then tell you why something didn't worked as expected.<br>
>  Â  Â  ><br>
>  Â  Â  > That's the worst-case scenario where you're debugging HW or FW<br>
>  Â  Â issues.<br>
>  Â  Â  > Those should be pretty rare post-bringup. But are there hangs caused<br>
>  Â  Â  > by user mode driver or application bugs that are easier to debug and<br>
>  Â  Â  > probably don't even require a GPU reset? For example most VM faults<br>
>  Â  Â  > can be handled without hanging the GPU. Similarly, a shader in an<br>
>  Â  Â  > endless loop should not require a full GPU reset. In the KFD compute<br>
>  Â  Â  > case, that's still preemptible and the offending process can be<br>
>  Â  Â killed<br>
>  Â  Â  > with Ctrl-C or debugged with rocm-gdb.<br>
> <br>
>  Â  Â We also have infinite loop in shader abort for gfx and page faults are<br>
>  Â  Â pretty rare with OpenGL (a bit more often with Vulkan) and can be<br>
>  Â  Â handled gracefully on modern hw (they just spam the logs).<br>
> <br>
>  Â  Â The majority of the problems is unfortunately that we really get hard<br>
>  Â  Â hangs because of some hw issues. That can be caused by unlucky timing,<br>
>  Â  Â power management or doing things in an order the hw doesn't expected.<br>
> <br>
>  Â  Â Regards,<br>
>  Â  Â Christian.<br>
> <br>
>  Â  Â  ><br>
>  Â  Â  > It's more complicated for graphics because of the more complex<br>
>  Â  Â  > pipeline and the lack of CWSR. But it should still be possible to do<br>
>  Â  Â  > some debugging without JTAG if the problem is in SW and not HW or<br>
>  Â  Â FW.<br>
>  Â  Â  > It's probably worth improving that debugability without getting<br>
>  Â  Â  > hung-up on the worst case.<br>
>  Â  Â  ><br>
>  Â  Â  > Maybe user mode graphics queues will offer a better way of<br>
>  Â  Â recovering<br>
>  Â  Â  > from these kinds of bugs, if the graphics pipeline can be unstuck<br>
>  Â  Â  > without a GPU reset, just by killing the offending user mode queue.<br>
>  Â  Â  ><br>
>  Â  Â  > Regards,<br>
>  Â  Â  > Â  Felix<br>
>  Â  Â  ><br>
>  Â  Â  ><br>
>  Â  Â  >><br>
>  Â  Â  >> And yes that absolutely doesn't scale.<br>
>  Â  Â  >><br>
>  Â  Â  >> Christian.<br>
>  Â  Â  >><br>
>  Â  Â  >>><br>
>  Â  Â  >>> Alex<br>
>  Â  Â  >><br>
> <br>
</blockquote></div></div></div>