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: gnats-bugs%netbsd.org@localhost
Cc: xsrc-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
	Rhialto <rhialto%falu.nl@localhost>
Subject: Re: xsrc/58133: X server crashes; radeon 5450; modesetting
Date: Sun, 5 May 2024 15:02:06 +0200

 After some experiments with difficulty, I found out less than I wanted
 and just got more confused in some respects.
 
 With Driver "modesetting", the segv is in glamor_text() in
 xsrc/external/mit/xorg-server/dist/glamor/glamor_text.c, which calls
 glamor_get_vbo_space() in
 xsrc/external/mit/xorg-server/dist/glamor/glamor_vbo.c. This ends up in
 /usr/X11R7/lib/modules/libglamoregl.so. I could get debugging output
 from there. It shows that the "vbo" (video buffer object, I presume)
 indeed gets filled up and restarted from the beginning pretty quickly,
 so when the segmentation violation happens with vbo_offset == 0, it must
 be the Nth time that this state occurs.
 
 A call there to glMapBufferRange() appears to be responsible for memory
 mapping. When chasing SIGSEGVs this would be a first suspect. But
 finding out to which source code this calls is nontrivial, since it
 seems that GL internally has lots of similar versions of the same thing,
 and a dispatcher that somehow chooses between options.
 
 It seemed that a function annotated "* Called via glMapBuffer() and
 glMapBufferRange()", named radeonMapBufferRange() in
 ./usr/xsrc/external/mit/MesaLib/dist/src/mesa/drivers/dri/radeon/radeon_buffer_objects.c
 would be a good candidate, which in turn would seem to refer to bo_map()
 in xsrc/external/mit/libdrm/dist/radeon/radeon_bo.c. However, this
 location is NOT reached with Driver "modesetting".
 
 With Driver "radeon", it does reach bo_map() but not glamor_get_vbo_space().
 
 To make things more confusing: if you do not have a xorg.conf file, X
 doesn't choose "modesetting_drv" as a default driver. It doesn't even
 choose "radeon_drv", but "ati_drv":
 
 [   845.672] (==) Using default built-in configuration (39 lines)
 [   845.672] (==) --- Start of built-in configuration ---
 [   845.672] 	Section "Device"
 [   845.672] 		Identifier	"Builtin Default ati Device 0"
 [   845.672] 		Driver	"ati"
 [   845.672] 	EndSection
 [   845.672] 	Section "Screen"
 [   845.672] 		Identifier	"Builtin Default ati Screen 0"
 [   845.672] 		Device	"Builtin Default ati Device 0"
 [   845.672] 	EndSection
 ...
 [   845.672] 	Section "ServerLayout"
 [   845.672] 		Identifier	"Builtin Default Layout"
 [   845.672] 		Screen	"Builtin Default ati Screen 0"
 [   845.672] 		Screen	"Builtin Default modesetting Screen 0"
 [   845.672] 		Screen	"Builtin Default vesa Screen 0"
 [   845.672] 		Screen	"Builtin Default wsfb Screen 0"
 [   845.672] 	EndSection
 [   845.672] (==) --- End of built-in configuration ---
 ...
 
 confusingly, it labels most of its output with (II) RADEON: 
 
 [   845.738] (II) RADEON(0): Creating default Display subsection in Screen section
 	"Builtin Default ati Screen 0" for depth/fbbpp 24/32
 [   845.738] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32
 [   845.738] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
 [   845.738] (==) RADEON(0): Default visual is TrueColor
 [   845.738] (==) RADEON(0): RGB weight 888
 [   845.738] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
 [   845.738] (--) RADEON(0): Chipset: "ATI Radeon HD 5450" (ChipID = 0x68f9)
 
 however this driver actually logs the precise chipset, which I think the
 "radeon_drv" doesn't do.
 
 The ati_drv is smaller than the radeon_drv and links to fewer other
 libraries (in particular not libglapi, but both do link to libdrm_radeon
 where bo_map() is).
 
 I'm trying the reliability of the "ati_drv" now.
 
 However I would still like to know what code there is behind
 glMapBufferRange(). It seems that this may be a key to the root cause of
 the segv. Without working single stepping in gdb this seems hard to find
 out though.