All of lore.kernel.org
 help / color / mirror / Atom feed
* etnaviv: mmu issue after end of address space reached?
@ 2016-12-10 11:00 Wladimir J. van der Laan
  2016-12-10 11:47 ` Wladimir J. van der Laan
  0 siblings, 1 reply; 5+ messages in thread
From: Wladimir J. van der Laan @ 2016-12-10 11:00 UTC (permalink / raw)
  To: etnaviv, dri-devel


I'm having an issue where a long-running test eventually runs into a MMU
fault. What this test does is basically:

- while [ 1 ]; do start a program that:
    - Allocate bo A, B and C, D
    - Map bo C, update it
    - Loop
        - Map bo A B and C, update them
        - Build command buffer
        - Submit command buffer
        - etna_cmd_stream_finish
        - Map buffer A, check output
    - Delete buffer A, B, C and D
    - Exit program
(code is here: https://github.com/etnaviv/etnaviv_gpu_tests/blob/master/src/etnaviv_verifyops.c#L735)

The curious thing is that after the fault happens once, it keeps running into
the same fault almost immediately, even after a GPU reset. This made me suspect
it has to do with kernel driver state not GPU state.

I added some debugging in the kernel driver in etnaviv_iommu_find_iova:

<4>[  549.776209] Found iova: 00000000 eff82000
<4>[  549.780712] Found iova: 00000000 eff93000
<4>[  549.785173] Found iova: 00000000 effa4000
<4>[  549.789706] Found iova: 00000000 effb5000
<4>[  549.794167] Found iova: 00000000 effc6000
<4>[  549.798686] Found iova: 00000000 effd7000
<4>[  549.803171] Found iova: 00000000 effe8000
<4>[  549.803171] Found iova: 00000000 effe8000
<4>[  549.807680] last_iova <- end of range
<4>[  549.809966] Found iova: 00000000 e8783000
<3>[  549.814025] etnaviv-gpu 130000.gpu: MMU fault status 0x00000002 <- happens almost immediately
<3>[  549.819960] etnaviv-gpu 130000.gpu: MMU 0 fault addr 0xe8783040
<3>[  549.825889] etnaviv-gpu 130000.gpu: MMU 1 fault addr 0x00000000
<3>[  549.831817] etnaviv-gpu 130000.gpu: MMU 2 fault addr 0x00000000
<3>[  549.837744] etnaviv-gpu 130000.gpu: MMU 3 fault addr 0x00000000

Apparently it is running out of the address space.
(I changed the end of the range to 0xf0000000 instead of 0xffffffff to rule out
that it had to do with the GPU disliking certain addresses)

In principle this shouldn't be an issue - after last_iova it starts over, with a
flushed MMU. I verified that this flush is actually being queued in etnaviv_buffer_queue.

However for some reason that logic doesn't seem to be working. I have not found
out what is wrong yet. I have not verified whether the MMU flush is actually flushing,
or whether this is a problem with updating the page tables.

What I find curious, though, is that after the search presumably starts over at
0 it returns 0xe8783000 instead of an earlier address. For this reason
last_iova is stuck near the end of the address space and the problem keeps
repeating once it's been hit.

It's certainly possible that I'm doing something dumb here and am somehow spamming
full the address space :)

Wladimir

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-12-12  9:57 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-12-10 11:00 etnaviv: mmu issue after end of address space reached? Wladimir J. van der Laan
2016-12-10 11:47 ` Wladimir J. van der Laan
2016-12-10 17:05   ` Wladimir J. van der Laan
2016-12-12  9:25     ` Lucas Stach
2016-12-12  9:57       ` Wladimir J. van der Laan

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.