Bug ID 1068961
Summary X.org crashes with fbdev and modesetting GPU
Classification openSUSE
Product openSUSE Tumbleweed
Version Current
Hardware Other
OS Other
Status NEW
Severity Normal
Priority P5 - None
Component X.Org
Assignee xorg-maintainer-bugs@forge.provo.novell.com
Reporter msrb@suse.com
QA Contact xorg-maintainer-bugs@forge.provo.novell.com
Found By ---
Blocker ---

This bug is for tracking X crash that was observed in both bnc#1067977 and
bnc#1063139, but I believe it is not the core issue in neither of them.

The crash happens if X is started on a machine with at least two GPUs, fbdev is
used for the primary one and modesetting for the secondary one. (Also happens
with qxl instead of modesetting.)

A regular screen is created for the fbdev device and a "GPU" screen is created
for the modesetting device. The fbdev screen is set as master to the
modesetting screen. Later a randr function is called on the modesetting screen
and it tries to retrieve `rrScrPrivPtr` of the master (=fbdev) screen, but it
does not have one. It crashes trying to access it:

Thread 1 "X" received signal SIGSEGV, Segmentation fault.
RRSetChanged (pScreen=0x5555559e25a0) at randr.c:558
558         mastersp->changed = TRUE;

Backtrace:
#0  RRSetChanged (pScreen=0x5555559e25a0) at randr.c:558
#1  RRScreenSetSizeRange at rrinfo.c:228
#2  xf86RandR12CreateScreenResources12 at xf86RandR12.c:1795
#3  xf86RandR12CreateScreenResources at xf86RandR12.c:844
#4  xf86CrtcCreateScreenResources at xf86Crtc.c:719
#5  dix_main at main.c:208

Not sure about proper solution yet. Either the randr function should handle the
case when master screen does not have randr initialized on it, or the slave
screens should not be created at all - without randr there is no PRIME, so
there is no use for slave screens.


You are receiving this mail because: