etnaviv-gpu 134000.gpu: MMU fault status 0x00000002 on i.XM6 Quad Plus
Luís Mendes
luis.p.mendes at gmail.com
Thu Nov 2 21:57:19 UTC 2017
Hi Russel,
I have the debug log with MMU faults and the logs you requested. I tried to
obtain the stacktrace with backtrace, I have included -rdynamic flag to the
compiler, but got no luck...
The debug code is like this:
void etnaviv_accel_CopyNtoN(DrawablePtr pSrc, DrawablePtr pDst,
GCPtr pGC, BoxPtr pBox, int nBox, int dx, int dy, Bool reverse,
Bool upsidedown, Pixel bitPlane, void *closure)
{
...
extent.y2 = min_t(short, pDst->y + pDst->height,
pSrc->y + pSrc->height - dy);
if (etna_bo_size(op.dst.bo) == 98304) {
int nptrs;
syslog(LOG_ERR, "dx: %d, op.dst.offset.x:%d\n", dx,
op.dst.offset.x);
syslog(LOG_ERR, "dy: %d, op.dst.offset.y:%d\n", dy,
op.dst.offset.y);
syslog(LOG_ERR, "final op.src.offset.x=%d, op.src.offset.y=%d\n",
op.dst.offset.x, op.dst.offset.y);
syslog(LOG_ERR, "pDst->x=%d, pSrc->x=%d\n", pDst->x, pSrc->x);
syslog(LOG_ERR, "pDst->y=%d, pSrc->y=%d\n", pDst->y, pSrc->y);
syslog(LOG_ERR, "pDst->width=%d, pSrc->width=%d\n", pDst->width,
pSrc->width);
syslog(LOG_ERR, "pDst->height=%d, pSrc->height=%d\n", pDst->height,
pSrc->height);
syslog(LOG_ERR, "extent(x1=%d, y1=%d, x2=%d, y2=%d)\n", extent.x1,
extent.y1,
extent.x2, extent.y2);
if (pGC) {
syslog(LOG_ERR, "pGC is not NULL\n");
} else {
syslog(LOG_ERR, "pGC is NULL\n");
}
nptrs = backtrace(buffer, 100);
strings = backtrace_symbols(buffer, nptrs);
if (strings == NULL) {
syslog(LOG_ERR, "Error getting stacktrace\n");
} else {
for (j = 0; j < nptrs; j++) {
syslog(LOG_ERR, "[%d] %s\n", j, strings[j]);
}
free(strings);
}
}
On Thu, Nov 2, 2017 at 8:16 PM, Luís Mendes <luis.p.mendes at gmail.com> wrote:
>
> I will do that. The strange thing is that I don't think
> etnaviv_accel_CopyNtoN(...) is the culprit of the MMU faults, because if I
> switch from hardware accelerated copyNtoN to software unaccelerated copyNtoN
> the MMU faults still occur, if I remember... However the corruption in
> the menus and dialog windows can be fixed by switching to unaccelerated
> copyNtoN.
>
> I will include the debug log when I have it.
>
>
> On Thu, Nov 2, 2017 at 4:18 PM, Russell King - ARM Linux <
> linux at armlinux.org.uk> wrote:
>
>> On Thu, Nov 02, 2017 at 03:33:19PM +0000, Luís Mendes wrote:
>> > Hi Russel,
>> >
>> > The requested file follows in attachment.
>>
>> Thanks - see below.
>>
>> > On Thu, Nov 2, 2017 at 3:20 PM, Russell King - ARM Linux <
>> > linux at armlinux.org.uk> wrote:
>> >
>> > > On Thu, Nov 02, 2017 at 03:05:38PM +0000, Luís Mendes wrote:
>> > > > [ 56.173613] etnaviv-gpu 134000.gpu: MMU fault status 0x00000002
>> > > > [ 56.179955] etnaviv-gpu 134000.gpu: MMU 0 fault addr 0x0803ffc0
>> > > > [ 56.185905] etnaviv-gpu 134000.gpu: MMU 1 fault addr 0x00000000
>> > > > [ 56.191843] etnaviv-gpu 134000.gpu: MMU 2 fault addr 0x00000000
>> > > > [ 56.197778] etnaviv-gpu 134000.gpu: MMU 3 fault addr 0x00000000
>> > > > [ 59.258367] etnaviv-gpu 134000.gpu: hangcheck detected gpu
>> lockup!
>> > > > [ 59.265910] etnaviv-gpu 134000.gpu: completed fence: 378
>> > > > [ 59.271737] etnaviv-gpu 134000.gpu: active fence: 383
>> > > > [ 59.277930] etnaviv-gpu 134000.gpu: hangcheck recover!
>> > > >
>> > > > === Register dump
>> > > > 0000000c = 000000df
>> > > > 00000000 = 00040900
>> > > > 00000004 = 7ffffff8 Idle: FE- DE- PE- SH+ PA+ SE+ RA+ TX+ VG+ IM+
>> FP+ TS+
>> > > > 00000008 = 00002200
>> > > > 00000014 = ffffffff
>> > > > 00000018 = 14010000
>> > > > 0000001c = e02c7eca
>> > > > 00000020 = 00000320
>> > > > 00000024 = 00005303
>> > > > 00000028 = 20140510
>> > > > 0000002c = 20353900
>> > > > 00000034 = e9399eff
>> > > > 00000038 = e9399eff
>> > > > 00000070 = 00000000
>> > > > 00000100 = 00140021
>> > > > 00000104 = 00000000
>> > > > 00000108 = 000000fa
>> > > > 0000010c = 00000000
>> > > > 00000400 = 00000000
>> > > > 00000404 = 00000000
>> > > > 00000408 = 00000000
>> > > > 0000040c = 00000000
>> > > > 00000410 = 00000000
>> > > > 00000414 = 3c000000
>> > > > 00000418 = 00000000
>> > > > 0000041c = 00000000
>> > > > 00000420 = 00000000
>> > > > 00000424 = 00000000
>> > > > 00000428 = 00000000
>> > > > 0000042c = 00030000
>> > > > 00000480 = 000000a8
>> > > > 0000065c = 00000001
>> > > > 00000660 = 00000803 Cmd: [load0 DMA: idle Fetch: valid] Req idle
>> Cal idle
>> > > > 00000664 = 00001230 Command DMA address
>> > > > 00000668 = 00000040 FE fetched word 0
>> > > > 0000066c = 00000000 FE fetched word 1
>> > > > 00000670 = 00000000
>> > >
>> > > Okay, so we stopped at 0x1230.
>> > >
>> > > > ===
>> > > > Buffers
>> > > >
>> > > > Num Name IOVA Size
>> > > > 0 reg 00000000 00000128 296
>> > > > 1 mmu 00000000 00401000 4198400
>> > > > 2 ring 00000000 00001000 4096
>> > > > * 3 cmd 00001000 00000320 800
>> > > > 4 cmd 00002000 00000190 400
>> > > > 5 cmd 00003000 00000320 800
>> > > > 6 cmd 00004000 00000190 400
>> > > > 7 cmd 00005000 00000188 392
>> > > > 8 bomap 00000000 000018f0 6384
>> > > > 9 bo 00040000 00300000 3145728
>> > > > 10 bo 00340000 00001000 4096
>> > > > 11 bo 00341000 00002000 8192
>> > > > 12 bo 02e60000 00001000 4096
>> > > > 13 bo 030c3000 00001000 4096
>> > > > 14 bo 030c4000 00001000 4096
>> > > > 15 bo 030c5000 00018000 98304
>> > > > Checking MMU entries... ok
>> > >
>> > > So, buffer 3 is the command buffer we were processing, it's only 800
>> > > bytes long. You should find that along side the log file, called
>> > > "cmd-00001000.bin". Please send me this file. Thanks.
>>
>> Here's the decoded command buffer. My decoding includes the buffer
>> addresses, and the ranges that the GPU would access based on the draw
>> commands. We have from the table above, the addresses and sizes of
>> the bos currently mapped into the GPU's IOVA space.
>>
>> 00000: 08050480 00341000 LDST 0x1200=0x00341000
>> 000000a0 LDST 0x1204=0x000000a0
>> 00000000 LDST 0x1208=0x00000000
>> 06000046 LDST 0x120c=0x06000046
>> fe48fd53 LDST 0x1210=0xfe48fd53
>> 00018: 0804048a 00040000 LDST 0x1228=0x00040000
>> 00001000 LDST 0x122c=0x00001000
>> 00000000 LDST 0x1230=0x00000000
>> 00002006 LDST 0x1234=0x00002006
>> 00030: 0801049f 00000000 LDST 0x127c=0x00000000
>> 00038: 08030497 0030cccc LDST 0x125c=0x0030cccc
>> 01b802ad LDST 0x1260=0x01b802ad
>> 01e002d5 LDST 0x1264=0x01e002d5
>> 00048: 20000100 00000000
>> 01b802ad 01e002d5 0,0,40,40 ->
>> 685,440,725,480
>> Blit: Dst:00040000 Src:00341000 Clip 685,440,725,480
>> Src: 0x00341000-0x003429a0 (40,40)
>> Dst: 0x00040000-0x00220b54 (725,480)
>>
>> Looks fine - source bo 11, destination bo 9.
>>
>> 00058: 08010001 00000000 LDST 0x0004=0x00000000
>> 00060: 08010001 00000000 LDST 0x0004=0x00000000
>> 00068: 08010001 00000000 LDST 0x0004=0x00000000
>>
>> This is the GC320 "workaround":
>>
>> 00070: 08050480 00340000 LDST 0x1200=0x00340000
>> 00000040 LDST 0x1204=0x00000040
>> 00000000 LDST 0x1208=0x00000000
>> 03000043 LDST 0x120c=0x03000043
>> ffff0000 LDST 0x1210=0xffff0000
>> 00088: 0804048a 00340000 LDST 0x1228=0x00340000
>> 00000040 LDST 0x122c=0x00000040
>> 00000000 LDST 0x1230=0x00000000
>> 00002003 LDST 0x1234=0x00002003
>> 000a0: 0801049f 00000000 LDST 0x127c=0x00000000
>> 000a8: 08030497 0030cccc LDST 0x125c=0x0030cccc
>> 00010000 LDST 0x1260=0x00010000
>> 00020001 LDST 0x1264=0x00020001
>> 000b8: 20000100 00000000
>> 00010000 00020001 0,0,1,1 -> 0,1,1,2
>> Blit: Dst:00340000 Src:00340000 Clip 0,1,1,2
>> Src: 0x00340000-0x00340044 (1,1)
>> Dst: 0x00340000-0x00340084 (1,2)
>>
>> Looks fine, source and destination bo 10.
>>
>> 000c8: 08010e03 00000008 LDST 0x380c=0x00000008 Flush PE2D
>> 000d0: 08010e02 00000701 LDST 0x3808=0x00000701 SEM FE -> PE
>> 000d8: 48000000 00000701 STALL FE -> PE
>> 000e0: 18000000(00000008) NOP
>> 000e8: 18000000(00000701) NOP
>> 000f0: 18000000(00000701) NOP
>> 000f8: 18000000(00000701) NOP
>> 00100: 18000000(000b0022) NOP
>> 00108: 18000000(00000000) NOP
>> 00110: 18000000(00000000) NOP
>> 00118: 18000000(00000000) NOP
>> 00120: 18000000(00100020) NOP
>> 00128: 18000000(00000000) NOP
>> 00130: 18000000(000b002a) NOP
>> 00138: 18000000(00000000) NOP
>> 00140: 18000000(00000000) NOP
>> 00148: 18000000(00000000) NOP
>> 00150: 18000000(00000018) NOP
>> 00158: 18000000(00000000) NOP
>> 00160: 18000000(000b0032) NOP
>> 00168: 18000000(00000000) NOP
>> 00170: 18000000(00000000) NOP
>> 00178: 18000000(00000000) NOP
>> 00180: 08050480 00040000 LDST 0x1200=0x00040000
>> 00001000 LDST 0x1204=0x00001000
>> 00000000 LDST 0x1208=0x00000000
>> 06000046 LDST 0x120c=0x06000046
>> ffe80000 LDST 0x1210=0xffe80000
>> 00198: 0804048a 030c5000 LDST 0x1228=0x030c5000
>> 00001000 LDST 0x122c=0x00001000
>> 00000000 LDST 0x1230=0x00000000
>> 00002006 LDST 0x1234=0x00002006
>> 001b0: 0802049f 00ff0001 LDST 0x127c=0x00ff0001
>> 01000100 LDST 0x1280=0x01000100
>> 001c0: 080304b2 ff000000 LDST 0x12c8=0xff000000
>> 00000000 LDST 0x12cc=0x00000000
>> 00000000 LDST 0x12d0=0x00000000
>> 001d0: 08030497 0030cccc LDST 0x125c=0x0030cccc
>> 00000000 LDST 0x1260=0x00000000
>> 00180400 LDST 0x1264=0x00180400
>> 001e0: 20000100 00000000
>> 00000000 00180400 0,-24,1024,0 -> 0,0,1024,24
>> Blit: Dst:030c5000 Src:00040000 Clip 0,0,1024,24
>> Src: 0x00040000-0x00041000 (1024,0)
>> Dst: 0x030c5000-0x030de000 (1024,24)
>>
>> Source bo 9, which looks fine.
>> Destination bo 15, which is:
>>
>> 15 bo 030c5000 00018000 98304
>>
>> It's final IOVA is the sum of those two, which is 0x030dd000.
>>
>> The destination stride is from state 0x122c, which is 4096.
>> Destination start address was 0x030c5000 in state 0x1228, and the
>> bottom y in the draw command is 24. That gives 98304 bytes, but
>> there's also the right x as well, which is another 1024 pixels on
>> top, giving an extra 4096 bytes on top of that.
>>
>> So, it looks like this bo was too small for the draw command
>> being requested.
>>
>> It's interesting to note that the MMU fault addresses don't seem to
>> correspond - my GC320 is a MMUv1 GPU, and doesn't have MMU faults,
>> so I don't know how to interpret these.
>>
>> 001f0: 08010001 00000000 LDST 0x0004=0x00000000
>> 001f8: 08010001 00000000 LDST 0x0004=0x00000000
>> 00200: 08010001 00000000 LDST 0x0004=0x00000000
>> 00208: 08050480 00340000 LDST 0x1200=0x00340000
>> 00000040 LDST 0x1204=0x00000040
>> 00000000 LDST 0x1208=0x00000000
>> 03000043 LDST 0x120c=0x03000043
>> ffff0000 LDST 0x1210=0xffff0000
>> 00220: 0804048a 00340000 LDST 0x1228=0x00340000
>> 00000040 LDST 0x122c=0x00000040
>> 00000000 LDST 0x1230=0x00000000
>> 00002003 LDST 0x1234=0x00002003
>>
>> <============stalled mid-loading above states=============>
>>
>> (rest of dump truncated as nor relevant.)
>>
>> The obvious question is - why did we end up with a 1024x24 blit copy
>> into a buffer that was actually too small. This also happens to be
>> the hardware clip window size as well (which should be bounded by the
>> source and destination drawable sizes and the copy position.)
>>
>> I suspect if we set extent.y2 one less, we'll get problems with the
>> last line being corrupted on other copies.
>>
>> Any chance of adding some debug to etnaviv_accel_CopyNtoN() to trace
>> which copy this is? We know that the destination bo is 98304 in
>> size, so use that to avoid printing out too much. The destination
>> bo should be in op.dst.bo, and its size can be found via
>> etna_bo_size(op.dst.bo).
>>
>> Thanks.
>>
>> --
>> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
>> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps
>> up
>> According to speedtest.net: 8.21Mbps down 510kbps up
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/etnaviv/attachments/20171102/b0e02740/attachment-0001.html>
More information about the etnaviv
mailing list