ChanServ changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs https://oftc.irclog.whitequark.org/etnaviv
_Guapisimo_ has joined #etnaviv
_Guapisimo_ has quit []
samuelig has quit [Quit: Bye!]
samuelig has joined #etnaviv
lynxeye has joined #etnaviv
mvlad has joined #etnaviv
<bl4ckb0ne> lynxeye: i found new things regarding the MMU fault
<bl4ckb0ne> i increased the cycles in the waitlink and at some point the wait gets replaced by `400000eb 00004000`
<bl4ckb0ne> havent been about to find what's that address in the VA
<bl4ckb0ne> i also found that the waitlink in vivante does a l2 flush between the wait and the link, havent found if the GC7000 has a l2, adding is has been inconclusive but I think I got the whole waitlink segment wrong since it has to fit on 2 lines
<lynxeye> bl4ckb0ne: I don't exactly follow where you see the issue. The wait being replaced when more work is submitted is a normal thing to happen. 0x4000 looks like a pretty normal user cmdbuf address.
<bl4ckb0ne> yeah the fe is still progressing, could that address be the missing page?
<lynxeye> Not likely. If that address is unmapped you should see that address in the MMU fault report, at least that's my experience with FE going in the wrong direction. Also the user cmdbuf area is statically mapped into the address space, as it's just a static range of memory preallocated on driver bind.
<bl4ckb0ne> hm, so how the hell is that faulting on 0x0
lynxeye has quit [Quit: Leaving.]
mvlad has quit [Remote host closed the connection]