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

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

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.