I used to have a lot of faults on access to FB bar, apparently caused by BIOS.
Since now FB bar is mapped via VM, maybe its the same thing?

The faults themselves were accesses from SMI code my bios runs apparently for no reason (some debug code leftovers maybe)

VFETCH means "vertex fetch", so it's caused by vertex fetches / reads of vertex data by PGRAPH.

One possible reason is that some app asks for vertices outside the limit of a vertex buffer (for whatever reason - could be app bug, driver bug or mesa bug), which go to a special memory area, NV50_3D_VERTEX_RUNOUT_ADDRESS, which isn't initialized and thus would cause VM faults at address 0.

That is what I suspected but didn't want to be true.
That happens with many games, so I suspect its nouveau mesa driver and not game fault, and it might reflect upon something nasty happening in the driver

I also have just seen that in kernel log:


[29782.682641] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TEXTURE - TP0: Unhandled ustatus 0x00000003
[29782.682671] [drm] nouveau 0000:01:00.0: PGRAPH_TRAP_TPDMA_RT - TP 0 - Unknown fault at address 0022467000
[29782.682693] [drm] nouveau 0000:01:00.0: PGRAPH_TRAP_TPDMA_RT - TP 0 - e0c: 00000000, e18: 00000000, e1c: 00000000, e20: 00001100, e24: 00030000
[29782.682722] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP
[29782.682740] [drm] nouveau 0000:01:00.0: PGRAPH - ch 5 (0x000472b000) subc 5 class 0x8297 mthd 0x15e0 data 0x00000000
[29782.682771] [drm] nouveau 0000:01:00.0: VM: trapped write at 0x0022467000 on ch 5 [0x0000472b] PGRAPH/PROP/RT0 reason: PAGE_NOT_PRESENT


Probably unrelated, or maybe not.
This time its texture fetch fault.

I also want to note that running Unigine demos (all of them) produces these TRAP_VFETCH FAULT messages and system eventually hangs.
That issue might be the indicator.

I'll should close this bug I think. Its just an application error who submits out of bound vertexes. mesa in debug mode actually complains about that.

Only thing though, maybe you want to filter this bogus data and not give it to apps?

By debug mode, do you mean "LIBGL_DEBUG=1 glapp"? If so, then mesa is being silent about any application errors.

Using nq-glslx (glsl branch of QuakeForge (git://git.quakeforge.net/gitroot/quake/quakeforge)) and leaving it to idle on the start map results in these messages eventually appearing after about 90 seconds (with occurrences every 90s or so). However, when I tried running nq-glslx under valgrind, it wouldn't happen :/

I also run into these errors.  They only occur after I reclock the card to any performance level above 1. If I then run Heroes of Newerth (Opengl game)  I run into slowdowns that will eventually lock the system up with this message in log repeatedly.  The messages and slowdowns stop if I manage to kill X before the system becomes unresponsive.  Running the game at the default performance level works fine.

01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9600M GT] (rev a1)

Mar 11 19:23:46 [kernel] [55207.554706] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_VFETCH FAULT
Mar 11 19:23:46 [kernel] [55207.554724] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_VFETCH 00f00000 0000fe0c 00000000 00000000
Mar 11 19:23:46 [kernel] [55207.554726] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP
Mar 11 19:23:46 [kernel] [55207.554730] [drm] nouveau 0000:01:00.0: PGRAPH - ch 4 (0x00040f0000) subc 5 class 0x8297 mthd 0x0f04 data 0xbef727ba
Mar 11 19:23:46 [kernel] [55207.554743] [drm] nouveau 0000:01:00.0: VM: trapped read at 0x0000000000 on ch 4 [0x000040f0] PGRAPH/VFETCH/00 reason: PT_NOT_PRESENT

libdrm mesa xf86-video-nouveau and kernel current as of 3 PM 02/19/2012 PST

(In reply to comment #8)
> libdrm mesa xf86-video-nouveau and kernel current as of 3 PM 02/19/2012 PST
Woops meant 03/11/2012

libdrm mesa xf86-video-nouveau and kernel current as of April 14th 16:00 PST

I can no longer reproduce these errors seems to be fixed.

Yep, this is fixed by new shader compiler ages ago.