Re: xsrc/58133: X server crashes; radeon 5450; modesetting

[Rhialto <rhialto%falu.nl@localhost>]

ah, so I tested the radeon driver after all (kernel_10+X_10+radeon)
and I saw indeed the same font issues as before. (some fonts didn't
render most letters, and some only half; it didn't go away when
minimizing and redisplaying the window) This time it was
limited to Firefox though.

A bit later in this combination X froze. In /var/log/messages it said
many times:

May  6 18:42:07 murthe /netbsd: [ 158834.9967050] radeon0: autoconfiguration error: error: ring 0 stalled for more than 374990msec
May  6 18:42:07 murthe /netbsd: [ 158834.9967050] radeon0: autoconfiguration error: error: ring 0 stalled for 8a last fence id 0x00000000000f828d on ring 0)

I had seen the same thing with kernel_10+X_9+radeon. Since I never had
it at all with kernel_9+X_9+radeon, this would seem to mean this is a
kernel-side issue in kernel_10.

A reboot seems to be the only way out of this.

I *thought* I had another candidate implementation of glMapBufferRange():

* Called via glMapBufferRange().
st_bufferobj_map_range() in ./usr/xsrc/external/mit/MesaLib/dist/src/mesa/state_tracker/st_cb_bufferobjects.c
    -> pipe_buffer_map_range() in ./usr/xsrc/external/mit/MesaLib/dist/src/gallium/auxiliary/util/u_inlines.h
	-> struct pipe_context.buffer_map() in ./usr/xsrc/external/mit/MesaLib/dist/src/gallium/include/pipe/p_context.h

	Possible initialization:
	./external/mit/MesaLib/dist/src/gallium/winsys/radeon/drm/radeon_drm_bo.c:   ws->base.buffer_map = radeon_bo_map;
	    # this is NOT the one listed above
	    radeon_bo_map() in ./usr/xsrc/external/mit/MesaLib/dist/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
	    -> radeon_bo_do_map() in same file
		-> os_mmap()

so I put printfs in both st_bufferobj_map_range() and radeon_bo_map()
(which is a different radeon_bo_map() than before!) but I did not see
output from them. Even though I got output from glamor_get_vbo_space().
So the real implementation must still be somewhere else.

This would have been a nice candidate, because it does a mmap() and
munmap() for every glMapBufferRange() / glUnMapBuffer(). So there would
be lots of opportunity for things to go wrong.

My current test is kernel_10+X_10+modesetting with a slightly modified
version of glamor_get_vbo_space(). I moved the calls to glUnmapBuffer()
and glMapBufferRange() into the condition about growing the buffer. So
mmap should be called only once now, ever (needing a bigger buffer is
really unlikely). It doesn't fix the root cause but it may work around
the issue. I really hope it does.

(maybe there needs to be some synchronisation, before reusing the
buffer, to wait for it to be "all processed" (there is something like
that in radeon_bo_map() in
./usr/xsrc/external/mit/MesaLib/dist/src/gallium/winsys/radeon/drm/radeon_drm_bo.c)
but I'm not sure what to call there)