Hi
I found a way to reliably reproduce PFIFO CACHE_ERRORS, but I don't see why.
How to reproduce them:
1) Run a couple of glxinfo loops - 3 is usually enough.
while [ true ]; do nvgl glxinfo >/dev/null 2>/dev/null; done
2) Run glxgears.
3) If you can't see it now, resize glxgears window or add more glxinfos.
Note: you need at least 2 CPUs.
Usually the error looks like this (with a bit improved logging):
nouveau E[ PFIFO][0000:02:00.0] CACHE_ERROR - ch 6 [glxgears[15559]] subc 0
mthd 0x0060 data 0x8000000f c1p0 0x20000010 HASH_FAILED (unknown bits
0x20000000) c1_hash 0x00000436
What I found so far:
1) It's triggered by setting of NV11_SUBCHAN_DMA_SEMAPHORE to NvSema
(0x8000000f) in nv84_fence_emit. Hw tells us it cannot find ramht entry
for NvSema object (NV04_PFIFO_CACHE1_PULL0 == HASH_FAILED, frequently
unknown 30th bit is set)
2) In 95% cases CACHE_ERRORs are triggered on glxgears channel.
3) RAMHT entry was definitely created and used many times before reporting
an error. Next use of NvSema usually does NOT trigger another CACHE_ERROR.
4) NV04_PFIFO_CACHE1_HASH has the same value as was written to ramht.
5) I can replace glxinfo loops with application which creates and destroys
PGRAPH objects. PCRYPT, PMPEG and SW objects do NOT provoke this bug.
(program attached)
6) There are no interrupts between CACHE_ERRORs, so it's not caused by race
in
cache_error/software method handling.
Any ideas how to debug it?
Marcin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_objects.tar.gz
Type: application/octet-stream
Size: 2399 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20121220/a790fe23/attachment.obj>
