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 23:10:33 UTC 2017
Even if I make all calls of copyNtoN(...) go to the unaccelerated fallback
the MMUs still occur in the same amount.
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)
{
...
if (!nBox)
return;
if (etnaviv->force_fallback)
goto fallback;
if (!etnaviv_init_dstsrc_drawable(etnaviv, &op, pDst, pSrc))
goto fallback;
goto fallback;
I get this different kernel MMU fault:
=== 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 = 000010b0 Command DMA address
00000668 = 00000040 FE fetched word 0
0000066c = 00000000 FE fetched word 1
00000670 = 00000000
=== Buffers
Num Name IOVA Size
0 reg 00000000 00000128 296
1 mmu 00000000 00401000 4198400
2 ring 00000000 00001000 4096
* 3 cmd 00001000 000001a0 416
4 cmd 00002000 00000190 400
5 cmd 00003000 000001a0 416
6 cmd 00004000 00000190 400
7 bomap 00000000 000018d8 6360
8 bo 00040000 00300000 3145728
9 bo 00340000 00001000 4096
10 bo 02316000 00001000 4096
11 bo 0231e000 00001000 4096
12 bo 02320000 00018000 98304
Checking MMU entries... ok
Corresponding cmd-00001000.bin follows in attachment.
On Thu, Nov 2, 2017 at 10:58 PM, Luís Mendes <luis.p.mendes at gmail.com>
wrote:
> I tried to avoid issuing such commands to the GC320 by doing:
> if ((extent.x2==22 && extent.y2==22) || etna_bo_size(op.dst.bo) == 98304)
> {
> goto fallback;
> }
> However the MMU faults still happen.
>
> === 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
> === 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 00000008 8
> 5 cmd 00003000 00000190 400
> 6 cmd 00004000 00000320 800
> 7 cmd 00005000 00000190 400
> 8 bomap 00000000 000018e8 6376
> 9 bo 00040000 00300000 3145728
> 10 bo 00340000 00001000 4096
> 11 bo 00341000 00002000 8192
> 12 bo 025c2000 00001000 4096
> 13 bo 025c7000 00001000 4096
> 14 bo 025c8000 00018000 98304
> Checking MMU entries... ok
>
> Respective cmd-00001000.bin follows in attachment.
>
>
> On Thu, Nov 2, 2017 at 10:47 PM, Luís Mendes <luis.p.mendes at gmail.com>
> wrote:
>
>> I changed the logging code to log everything and got this near a MMU
>> fault:
>> Nov 2 22:34:37 picolo xf86_armada[1303]: pDst->x=0, pSrc->x=0
>> Nov 2 22:34:37 picolo xf86_armada[1303]: pDst->y=0, pSrc->y=0
>> Nov 2 22:34:37 picolo xf86_armada[1303]: pDst->width=22, pSrc->width=22
>> Nov 2 22:34:37 picolo xf86_armada[1303]: pDst->height=22, pSrc->height=22
>> Nov 2 22:34:37 picolo xf86_armada[1303]: extent(x1=0, y1=0, x2=22, y2=22)
>> Nov 2 22:34:37 picolo xf86_armada[1303]: pGC is not NULL
>> Nov 2 22:34:37 picolo xf86_armada[1303]: initial op.src.offset.x=0,
>> op.src.offset.y=0
>> Nov 2 22:34:37 picolo xf86_armada[1303]: dx: 0, op.dst.offset.x:0
>> Nov 2 22:34:37 picolo xf86_armada[1303]: dy: 0, op.dst.offset.y:0
>> Nov 2 22:34:37 picolo kernel: [ 168.123707] etnaviv-gpu 134000.gpu: MMU
>> fault status 0x00000002
>> Nov 2 22:34:37 picolo kernel: [ 168.130029] etnaviv-gpu 134000.gpu: MMU
>> 0 fault addr 0x0d03afc0
>> Nov 2 22:34:37 picolo kernel: [ 168.135974] etnaviv-gpu 134000.gpu: MMU
>> 1 fault addr 0x00000000
>> Nov 2 22:34:37 picolo kernel: [ 168.141911] etnaviv-gpu 134000.gpu: MMU
>> 2 fault addr 0x00000000
>> Nov 2 22:34:37 picolo kernel: [ 168.147846] etnaviv-gpu 134000.gpu: MMU
>> 3 fault addr 0x00000000
>> Nov 2 22:34:37 picolo xf86_armada[1303]: final op.src.offset.x=0,
>> op.src.offset.y=0
>> Nov 2 22:34:37 picolo xf86_armada[1303]: pDst->x=0, pSrc->x=0
>> Nov 2 22:34:37 picolo xf86_armada[1303]: pDst->y=0, pSrc->y=0
>> Nov 2 22:34:37 picolo xf86_armada[1303]: pDst->width=22, pSrc->width=22
>> Nov 2 22:34:37 picolo xf86_armada[1303]: pDst->height=22, pSrc->height=22
>> Nov 2 22:34:37 picolo xf86_armada[1303]: extent(x1=0, y1=0, x2=22, y2=22)
>> Nov 2 22:34:37 picolo xf86_armada[1303]: pGC is not NULL
>>
>>
>> On Thu, Nov 2, 2017 at 10:26 PM, Luís Mendes <luis.p.mendes at gmail.com>
>> wrote:
>>
>>> Hi Russell,
>>>
>>> Please ignore my previous email...
>>> I tried to include the stacktrace of the calling process, but I am
>>> missing something despite I have included -rdynamic in the linker flags,
>>> but no stack is being generated.
>>> The debug code is like this in case you want to check how the variables
>>> are being obtained:
>>> 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)
>>> {
>>> ...
>>> if (!etnaviv_init_dstsrc_drawable(etnaviv, &op, pDst, pSrc))
>>> goto fallback;
>>>
>>>
>>> syslog(LOG_ERR, "initial op.src.offset.x=%d, op.src.offset.y=%d\n",
>>> op.src.offset.x, op.src.offset.y);
>>>
>>> /* Include the copy delta on the source */
>>> op.src.offset.x += dx - op.dst.offset.x;
>>> op.src.offset.y += dy - op.dst.offset.y;
>>> op.src_origin_mode = SRC_ORIGIN_RELATIVE;
>>>
>>> /* Calculate the overall extent */
>>> extent.x1 = max_t(short, pDst->x, pSrc->x - dx);
>>> extent.y1 = max_t(short, pDst->y, pSrc->y - dy);
>>> extent.x2 = min_t(short, pDst->x + pDst->width,
>>> pSrc->x + pSrc->width - dx);
>>> 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.src.offset.x, op.src.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);
>>> }
>>> }
>>>
>>>
>>> The MMU fault dump now looks like this:
>>>
>>> === 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
>>> === 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 00000310 784
>>> 7 bomap 00000000 000018f0 6384
>>> 8 bo 00040000 00300000 3145728
>>> 9 bo 00340000 00001000 4096
>>> 10 bo 00341000 00002000 8192
>>> 11 bo 030b9000 00001000 4096
>>> 12 bo 0311b000 00001000 4096
>>> 13 bo 0311c000 00001000 4096
>>> 14 bo 0311d000 00018000 98304
>>> Checking MMU entries... ok
>>>
>>> I have attached cmd-00001000.bin.
>>>
>>> The syslog logging follows in attachment too.
>>>
>>> By looking at the log I would say that the culprit copyNtoN is this one,
>>> as it is the one nearer the first MMU fault, but is not matching the
>>> condtion "etna_bo_size(op.dst.bo) == 98304":
>>> Nov 2 22:10:29 picolo xf86_armada[744]: initial op.src.offset.x=0,
>>> op.src.offset.y=0
>>> Nov 2 22:10:29 picolo kernel: [ 66.966997] etnaviv-gpu 134000.gpu:
>>> MMU fault status 0x00000002
>>> Nov 2 22:10:29 picolo kernel: [ 66.973342] etnaviv-gpu 134000.gpu:
>>> MMU 0 fault addr 0x0803ffc0
>>> Nov 2 22:10:29 picolo kernel: [ 66.979286] etnaviv-gpu 134000.gpu:
>>> MMU 1 fault addr 0x00000000
>>> Nov 2 22:10:29 picolo kernel: [ 66.985221] etnaviv-gpu 134000.gpu:
>>> MMU 2 fault addr 0x00000000
>>> Nov 2 22:10:29 picolo kernel: [ 66.991154] etnaviv-gpu 134000.gpu:
>>> MMU 3 fault addr 0x00000000
>>>
>>>
>>> Luis
>>>
>>> On Thu, Nov 2, 2017 at 9:57 PM, Luís Mendes <luis.p.mendes at gmail.com>
>>> wrote:
>>>
>>>> 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/ee0d802b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmd-00001000.bin
Type: application/octet-stream
Size: 416 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/etnaviv/attachments/20171102/ee0d802b/attachment-0001.bin>
More information about the etnaviv
mailing list