<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!" href="https://bugs.freedesktop.org/show_bug.cgi?id=102322#c17">Comment # 17</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!" href="https://bugs.freedesktop.org/show_bug.cgi?id=102322">bug 102322</a> from <a class="email" href="mailto:andrey.grodzovsky@amd.com" title="Andrey Grodzovsky <andrey.grodzovsky@amd.com>"> Andrey Grodzovsky</a> <pre>(In reply to Alex Deucher from <a href="show_bug.cgi?id=102322#c16">comment #16</a>) > (In reply to Andrey Grodzovsky from <a href="show_bug.cgi?id=102322#c15">comment #15</a>) > > I think it just means systems with large VRAM so it will require large BAR > > for mapping. But I am not sure on that point. > > That's correct. the updates are done with the CPU rather than the GPU > (SDMA). The default BAR size on most systems is usually 256MB for 32 bit > compatibility so the window for CPU access to vram (where the page tables > live) is limited. Thanks Alex. dwagner, this is obviously just a work around and not a fix. It points to some problem with SDMA packets, if you want to continue exploring we can try to dump some fence traces and SDMA HW ring content to examine the latest packets before the hang happened.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>