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

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

The following reply was made to PR xsrc/58133; it has been noted by GNATS.

From: Rhialto <rhialto%falu.nl@localhost>
To: matthew green <mrg%eterna23.net@localhost>
Cc: Rhialto <rhialto%falu.nl@localhost>, xsrc-manager%netbsd.org@localhost,
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
	gnats-bugs%netbsd.org@localhost
Subject: Re: xsrc/58133: X server crashes; radeon 5450; modesetting
Date: Mon, 6 May 2024 21:58:51 +0200

 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)