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 20:16:45 UTC 2017
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/a799e9ba/attachment-0001.html>
More information about the etnaviv
mailing list