http://bugzilla.opensuse.org/show_bug.cgi?id=1068961 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: You are on the CC list for the bug.