<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - GF117: MMIO write of 0000001f FAULT at 6013d4 [ IBUS ]" href="https://bugs.freedesktop.org/show_bug.cgi?id=108980#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - GF117: MMIO write of 0000001f FAULT at 6013d4 [ IBUS ]" href="https://bugs.freedesktop.org/show_bug.cgi?id=108980">bug 108980</a> from <a class="email" href="mailto:imirkin@alum.mit.edu" title="Ilia Mirkin <imirkin@alum.mit.edu>"> Ilia Mirkin</a> <pre>OK, I see what's going on. This is going to be a game of whack-a-mole. We make a bunch of MMIO accesses to "illegal" areas. The "error" buffer is only 1-deep, i.e. it keeps track of only the last one. When we enable reporting, it reports whichever was the first, or the last such error. With the vga write fixed, now it's something else. 84048 is PVLD.ACCESS_EN. I guess we're accessing it before it's enabled? It looks like this is coming from nvkm_falcon_fini (which is, counter-intuitively, called as part of the initialization flow). The logic in core/subdev.c is to first run ->fini() and then do nvkm_mc_reset() which will turn off-then-on the bit that enables the engine. Ben - what's the proper way to deal with this? Tweak PMC.ENABLE in nvkm_device_fini? [We could always just clear out those errors before first enabling the bus intr reporting, but that would just be sticking our heads in the sand...] In the meanwhile, I'll work on a proper patch for the vgalock thing.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>