<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Segfault in Xorg after RADEON(0): Failed to make 28944x66x32bpp GBM bo"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=96396#c7">Comment # 7</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Segfault in Xorg after RADEON(0): Failed to make 28944x66x32bpp GBM bo"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=96396">bug 96396</a>
              from <span class="vcard"><a class="email" href="mailto:holmgren@lysator.liu.se" title="Magnus Holmgren <holmgren@lysator.liu.se>"> <span class="fn">Magnus Holmgren</span></a>
</span></b>
        <pre>(In reply to Michel Dänzer from <a href="show_bug.cgi?id=96396#c6">comment #6</a>)
<span class="quote">> Does it work better with DRI3 enabled, by any chance?</span >

Well... with Option "DRI" 3", KSP.x86_64 -force-glcore _almost_ always
terminates right away with this in the log:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been
called
[xcb] Aborting, sorry about that.
KSP.x86_64: ../../src/xcb_io.c:274: poll_for_event: Assertion
`!xcb_xlib_threads_sequence_lost' failed.

Thread 1 (Thread 0x7f9f76ec4740 (LWP 5471)):
#0  0x00007f9f768def8d in read () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f9f71c358bd in ?? () from
/home/magnus/.local/share/Steam/SteamApps/common/Kerbal Space
Program/KSP_Data/Mono/x86_64/libmono.so
#2  <signal handler called>
#3  0x00007f9f750f8458 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:55
#4  0x00007f9f750f98da in __GI_abort () at abort.c:89
#5  0x00007f9f750f1387 in __assert_fail_base (fmt=<optimized out>,
assertion=assertion@entry=0x7f9f761c8f20 "!xcb_xlib_threads_sequence_lost",
file=file@entry=0x7f9f761c8d6b "../../src/xcb_io.c", line=line@entry=274,
function=function@entry=0x7f9f761c9226 "poll_for_event") at assert.c:92
#6  0x00007f9f750f1432 in __GI___assert_fail (assertion=0x7f9f761c8f20
"!xcb_xlib_threads_sequence_lost", file=0x7f9f761c8d6b "../../src/xcb_io.c",
line=274, function=0x7f9f761c9226 "poll_for_event") at assert.c:101
#7  0x00007f9f76155a59 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8  0x00007f9f76155b0b in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9  0x00007f9f76155e1d in _XEventsQueued () from
/usr/lib/x86_64-linux-gnu/libX11.so.6
#10 0x00007f9f76158b95 in _XGetRequest () from
/usr/lib/x86_64-linux-gnu/libX11.so.6
#11 0x00007f9f76158caf in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#12 0x00007f9f76158481 in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#13 0x00007f9f76472702 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1
#14 0x00007f9f7646e9f4 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1

I checked again that the above doesn't happen with Option "DRI" "2".

It also does not happen with -force-glcore40 or -force-glcore41 instead of
-force-glcore, with or without DRI3. And although the log says "Creating OpenGL
4.1 graphics device" in all cases, -force-glcore40 seems to work more often,
maybe even most of the time.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>