Have you come across an error like this?

[MrConfusion]

A bucketload of these in dmesg, with varying numerical content. They appear when I hit CTRL-C for a process that fails to display GLES content. My window manager hides the window at startup, so I "switch to it" to see it - in the meanwhile it renders "off screen". When things work, it just shows what it's supposed to when I pop the window on screen. When not. it's showing Big Black Nothing...

It can break between starting programs. Once broken it stays broken until reboot - no moduleunloading does the trick...

Windows with GLESV2 content (eglgears) rarely work, but sometimes do.

eglinfo works fine every time.

(

Similar also with glshim and plain old glxgears - when it works it works fine with a really good framerate, but mostly window remains blank. And glxinfo also works with glshim. But that's not surprising considering it is a wrapper...

)

Kernel 3.2.52

Videodriver versions I've tried:

4.00.00.01

4.03.00.02

1GHz unit and SL4P 14.0.

---------------------------------------------------

[ 1553.902648] PVR_K: HWRecoveryResetSGX: SGX Hardware Recovery triggered

 1553.902648] PVR_K: EUR_CR_EVENT_STATUS:     20040001
[ 1553.902679] PVR_K: EUR_CR_EVENT_STATUS2:    0
[ 1553.902679] PVR_K: EUR_CR_BIF_CTRL:         0
[ 1553.902679] PVR_K: EUR_CR_BIF_INT_STAT:     4002
[ 1553.902709] PVR_K: EUR_CR_BIF_FAULT:        f007000
[ 1553.902709] PVR_K: EUR_CR_BIF_MEM_REQ_STAT: 0
[ 1553.902709] PVR_K: EUR_CR_CLKGATECTL:       222220
[ 1553.902740] PVR_K: EUR_CR_PDS_PC_BASE:      0
[ 1553.902740] PVR_K: SGX Host control:
[ 1553.902740] PVR_K:   0x0: 0x0000001C 0x00000000 0x0000147D 0x0000000A
[ 1553.902770] PVR_K:   0x10: 0x00000002 0x00000000 0x00000001 0x00000067
[ 1553.902770] PVR_K:   0x20: 0x0F006810 0x00000001 0x00000000 0x00005D45
[ 1553.902770] PVR_K: SGX TA/3D control:
[ 1553.902801] PVR_K:   0x0: 0x0F03A42C 0x00000000 0x00000000 0x0F001020
[ 1553.902801] PVR_K:   0x10: 0x00000000 0x00000000 0x0F001020 0x00000000
[ 1553.902832] PVR_K:   0x20: 0x00000000 0x0F001020 0x00000000 0x00000000
[ 1553.902832] PVR_K:   0x30: 0x0F001020 0x00000000 0x00000000 0x00000000
[ 1553.902862] PVR_K:   0x40: 0x00000000 0x00000000 0x00000000 0x00000000
[ 1553.902862] PVR_K:   0x50: 0x00000000 0x0F000000 0x882D0000 0x00000001
[ 1553.902893] PVR_K:   0x60: 0x00000000 0x0F009680 0x00000000 0x0F007380
[ 1553.902893] PVR_K:   0x70: 0x0F001020 0x00000001 0x00000002 0x00000039
[ 1553.902893] PVR_K:   0x80: 0x0F03A42C 0x0F007380 0x0F001020 0x00000001
[ 1553.902923] PVR_K:   0x90: 0x00000000 0x00000003 0x00000000 0x00000000
[ 1553.902923] PVR_K:   0xA0: 0x00000000 0x00000000 0x00000000 0x00000000
[ 1553.902954] PVR_K:   0xB0: 0x00000000 0x00000003 0x00000000 0x00000000
[ 1553.902954] PVR_K:   0xC0: 0x00000000 0x00000000 0x00000000 0x00000000
[ 1553.902984] PVR_K:   00: 0x00000003 0x00000003 0x0F003000 0x0F007020
[ 1553.902984] PVR_K:   0xE0: 0x0F007020 0x00000000 0x7273752F 0x62696C2F
[ 1553.903015] PVR_K: Command Complete Data for display device 1:
 

 

[ptitSeb]

I have something similar with a game I'm trying to port. I have thoses HWRecoveryResetSGX also (with OGS Majhong), with every driver except the 4.10. The redering is broken also, with heavy blinking and wrong texture once the first HWRecovery trigger. I haven't located yet what is triggering thing.

Try with 4.10 maybe, it's more stable (at least for me).

 

[JonnyH]

MrConfusion: That's a weird one - can you double-check you're not calling eglTerminate() before that crash? It's pagefaulting the GPU in an area that should only be used for data owned by the EGL render context...

Is there any chance you can get an apitrace of a failing app? Plus the exact version of the driver/sgx you're running it on at the time (the '/proc/pvr/version' file)

Generally, hardware recovery logs with a non-zero 'EUR_CR_BIF_FAULT' are page faults, and can be caused by api-usage violations (going over a vertex array with an index is the most common, but the address shown here is outside the range used for user-supplied buffers, ruling that out). I'm still working on getting a 530-based platform up and running to try to test myself, so can't be too much help (yet)....

 

[MrConfusion]

ptitSeb: I hit two issues with higher driver numbers:

-the dri2 dependency problem

-I also have a Classic unit and I'd like to keep backwards compatibility... as I use the pandora 50-50 for work and play and it's my backup unit

JonnyH: I'll get back to that when I have time

 

[ptitSeb]

@JonnyH: With OGS Mahjong, using 1.6.16.3977 on a Gigahertz model, I have that:

[234960.972564] PVR_K: HWRecoveryResetSGX: SGX Hardware Recovery triggered
[234960.972595] PVR_K: SGX debug (1.6.16.3977)
[234960.972595] PVR_K: (P0) EUR_CR_EVENT_STATUS:     20008000
[234960.972625] PVR_K: (P0) EUR_CR_EVENT_STATUS2:    00000018
[234960.972625] PVR_K: (P0) EUR_CR_BIF_CTRL:         00000000
[234960.972686] PVR_K: (P0) EUR_CR_BIF_INT_STAT:     00000000
[234960.972686] PVR_K: (P0) EUR_CR_BIF_FAULT:        00000000
[234960.972686] PVR_K: (P0) EUR_CR_BIF_MEM_REQ_STAT: 00000000
[234960.972717] PVR_K: (P0) EUR_CR_CLKGATECTL:       00222220
[234960.972717] PVR_K: (P0) EUR_CR_PDS_PC_BASE:      0030003C
[234960.972747] PVR_K: Flip Command Complete Data 0 for display device 1:
[234960.972747] PVR_K: SGX Host control:
[234960.972747] PVR_K:  (HC-0) 0x00000001 0x00000000 0x00000000 0x00000001
[234960.972778] PVR_K:  (HC-10) 0x00000001 0x00000119 0x0000000A 0x00030D40
[234960.972839] PVR_K:  (HC-20) 0x00000002 0x00000001 0x00000001 0x00000000
[234960.972839] PVR_K:  (HC-30) 0x000137D7 0x000E0D55 0xA1FB64B8 0x00000000
[234960.972839] PVR_K: SGX TA/3D control:
[234960.972869] PVR_K:  (T3C-0) 0x0F003000 0x0F003120 0x0F002000 0x00000000
[234960.972869] PVR_K:  (T3C-10) 0x0F0A41C0 0x00000001 0x00000002 0x00000001
[234960.972900] PVR_K:  (T3C-20) 0x0F007F40 0x00000000 0x00000000 0x00000000
[234960.972900] PVR_K:  (T3C-30) 0x00000000 0x00000000 0x00000000 0x00000000
[234960.972930] PVR_K:  (T3C-40) 0x00000000 0x00000000 0x00000000 0x00000000
[234960.972930] PVR_K:  (T3C-50) 0x00000000 0x0F007F40 0x00000000 0x00000000
[234960.972930] PVR_K:  (T3C-60) 0x0F007F40 0x00000000 0x00000000 0x00000000
[234960.972961] PVR_K:  (T3C-70) 0x00000000 0x00000000 0x00000000 0x00000000
[234960.972961] PVR_K:  (T3C-80) 0x00000000 0x0F0BC6CC 0x00000000 0x0F000000
[234960.972991] PVR_K:  (T3C-90) 0x99CC3000 0x0F092CC0 0x0F0BC6CC 0x0F0BD2C0
[234960.972991] PVR_K:  (T3C-A0) 0x0F007F40 0x0F0BC6CC 0x0F0883A0 0x00000000
[234960.973022] PVR_K:  (T3C-B0) 0x0F0BC400 0x00000001 0x00000002 0x00000000
[234960.973022] PVR_K:  (T3C-C0) 0x00000000 0x661EE219 0x00000000 0x000002C4
[234960.973052] PVR_K:  (T3C-D0) 0x00000000 0x00000000 0x0000000C 0x00000000
[234960.973052] PVR_K:  (T3C-E0) 0x0000006F 0x0000006F 0x0F000000 0x80008000
[234960.973052] PVR_K:  (T3C-F0) 0x80048000 0x0F004000 0x0F007C20 0x0F002020
[234960.973083] PVR_K:  (T3C-100) 0x0F088000 0x0F088000 0x00000000 0x4C494146
[234960.973083] PVR_K: SGX Kernel CCB WO:0xE6 RO:0xE6

It's using some FBO... I have a correct behavour only with the "4.10" driver (not sure what is the internel version number).

 

@MrConfusion: yeah, 4.10 is Gigahertz only, and you cannot use it in a window...

 

[MrConfusion]

OOOOKAY...

So getting the apitrace was not as trivial as I though, but here it is.

As you can see from the logs, I used the mesa es2 test for this. It behaved the same as the ones I already had as binaries, but it's better in the sense it's easily obtainable from the net in case anyone is interested. I killed mesa from it, though, I had to do that much... I don't have it in my system.

Turns out if the window is NOT minimized at startup the pandora freezes every time, and so bad a hard reboot is needed. But happily it then turned out this is only because of high CPU/whatever resource usage and thus a prescripted kill -INT; kill -9 with a timer allowed me to shutdown capturing the trace (I hope) prefectly. So: I ran this for about 30 secs, but if you need a 10 hour longplay version, do tell ;-).

I killed my dwm window manager while running these, so basically there's no WM running at all during testing.

And. like (I think?) ptitSeb did I also get blocks of "random noise" on screen when doind the test like this. So not just black anymore.

Driver version is now the 4.00.00.01 one, meaning the one I most hope to get working... Has X, is Classic compatible...

Like I mentioned in my other thread my actual target is not fullscren games, but getting acceleration working in WebKitGTK. And unless I read completely wrong that thing expects to draw GL over X in selected locations. So definitely must have X11 integration or I'll spend the next summer hacking webkit to create empty SDL layers ;-)...

Added: Oh yes and I checked for eglTerminate from the code I traced with: no, I don't think it gets called, but yes it's there practically right before "exit(0)"... (eglut.c in that mesademopack)

es2gears_x11_misc.zip

es2gears_x11_apitrace.zip

 

[JonnyH]

Thanks for the details MrConfusion - I'll look at that when I can, I've been rather busy this last weekend (HDD in my pc died stopping me doing anything useful)

And ptitseb - that looks like a different problem, it doesn't seem to be a page fault but another reason the hw has stopped responding... So many bugs, so little time!

 

[Jignesh Patel]

Thanks JonnyH for explaining what EUR_CR_BIF_FAULT stands for. Can you also please tell what the other ones stand for?

EUR_CR_CORE_ID:
EUR_CR_CORE_REVISION:
EUR_CR_EVENT_STATUS:
EUR_CR_EVENT_STATUS2:
EUR_CR_BIF_CTRL:
EUR_CR_BIF_INT_STAT:
EUR_CR_BIF_FAULT:
EUR_CR_BIF_MEM_REQ_STAT
EUR_CR_CLKGATECTL:
EUR_CR_PDS_PC_BASE:

Please advise where can I get more info on this? (New to this , any advise appreciated )

 

[JonnyH]

Thanks JonnyH for explaining what EUR_CR_BIF_FAULT stands for. Can you also please tell what the other ones stand for?

EUR_CR_CORE_ID:
EUR_CR_CORE_REVISION:
EUR_CR_EVENT_STATUS:
EUR_CR_EVENT_STATUS2:
EUR_CR_BIF_CTRL:
EUR_CR_BIF_INT_STAT:
EUR_CR_BIF_FAULT:
EUR_CR_BIF_MEM_REQ_STAT
EUR_CR_CLKGATECTL:
EUR_CR_PDS_PC_BASE:

Please advise where can I get more info on this? (New to this , any advise appreciated )

EUR_CR_CORE_ID:
EUR_CR_CORE_REVISION:

These should be pretty self-explanitory - the core ID (e.g. '530' for a sgx530) and revision (for bug fixes and the like) identify exactly what core is on the SoC. It's not driver 'state' as such. Note, that the sgx driver model means that a binary driver must match both these *exactly* to work. Even revisions changed how things work in non-compatible ways.

I believe the other values don't really have any use unless you have internal knowledge of the driver and hardware workings, which aren't public, so can't really help you there.