Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

[Mike Lothian]

There's also some journalctl output in the bug report

On 5 April 2018 at 11:06, Mike Lothian <mike at fireburn.co.uk> wrote:
> Hi
>
> I'm attaching the core dumps (4GB uncompressed, 7MB XZ compressed)
>
> Might still be too big for the list
>
> Cheers
>
> Mike
>
> On 5 April 2018 at 09:33, Daniel Stone <daniel at fooishbar.org> wrote:
>> Hi Mike,
>>
>> On 5 April 2018 at 09:03, Mike Lothian <mike at fireburn.co.uk> wrote:
>>> I got different behavior with modesetting and the intel ddx
>>
>> I can try with the Intel DDX later on today.
>>
>>> Both didn't render anything, but I think one was crashing over and
>>> over (I think systemd kept restarting it in quick succession)
>>
>> systemd should log core files to coredumpctl and maintain any output
>> from services it's started itself in journalctl, so it would be great
>> to see any output and segfaults if possible.
>>
>>> I only remember that because when I switched VTs it made it almost
>>> impossible to type anything as it kept modesetting back to VT1 for a
>>> moment
>>>
>>> That didn't happen with the latest patches (which all seem to be in
>>> master now) but I did get the freeze that you saw
>>
>> Right, they are in master now. Which freeze do you mean? If you attach
>> to the kwin process and see it blocked forever waiting on a reply in
>> libICE/libSM, this seems to be related to KDE's session management
>> getting itself tangled, and _not_ anything to do with the rendering
>> path. For me, the hang inside libICE/libSM was caused by wiping out
>> all the ksmserver processes still running, as well as my .ICE-unix
>> directory.
>>
>> If you are seeing KWin and all the KDE session helper programs alive
>> and _not_ blocked inside libICE/libSM, a black screen and a KDE mouse
>> cursor, that's far more interesting and I'd also like to see the X
>> server's log file as well as any output from KDE in journalctl.
>>
>>> Be aware that kwin detects when there have been rendering crashes or
>>> incomplete starts and disables compositing. With compositing disabled
>>> or set to Xrender everything starts fine
>>
>> I'm _extremely_ sure that I was using GL compositing, because I was
>> seeing debug prints that I'd added to Mesa (and the X server DRI3
>> requests called by Mesa) from a session running only KDE and nothing
>> else. These debug prints were only ever called when you are an X11
>> compositing manager.
>>
>> Cheers,
>> Daniel