SDDM crash and random X crashes since upgrade

oeut1341 · 2017-01-18 21:32:25

Storm wrote:

oeut1341 wrote:
I rolled back xorg-server to 1.19.0-6 yesterday and haven't had a single crash ever since. So the problem is with 1.19.1-1, not 1.19 itself. Which is weird, considering it should include only fixes.
Did you roll back only Xorg? As if yes, that proves it's Xorg itself.

Yup. At least on my end, there are no packages yet depending on 1.19.1 (i.e., 1.19.0 suffices all dependencies), so downgrading is easy since it involves only the xorg-server package and nothing more.

Storm · 2017-01-19 16:20:06

I commented on the bugreport upstream because original reporter only talks about Intel VGA even though several people with nVidia cards have the same problem:
https://bugs.freedesktop.org/show_bug.cgi?id=99431#c1

oeut1341 wrote:

Yup. At least on my end, there are no packages yet depending on 1.19.1

Here several xf86-input-* packages conflict with it so I rather don't upgrade for now.

oeut1341 · 2017-01-20 22:57:04

Update: I've been getting crashes on 1.19.0-6 too, sadly (though much less compared to 1.19.1-1).

Other thing I noticed is that they seem to be correlated with notifications popping up in Plasma. Disabled them; let's see what happens...

halogene · 2017-01-23 11:01:42

I can confirm that sddm seems to be broken with current xorg-server 1.19.1. I'm on an intel GPU (Intel Corporation HD Graphics 5500 (rev 09)). I disabled sddm, and after re-installing xorg-server and xorg-server-common (1.19.1) and rebooting I was able to manually launch an xserver. However, sddm still hangs, and downgrading xorg-server to 1.19.0-6 did not help starting sddm again. Do I have to downgrade xorg-server-common as well?

Running X (started manually from terminal) now for about 2 hours and no crashes so far.

oeut1341 · 2017-01-23 13:02:08

halogene wrote:

I can confirm that sddm seems to be broken with current xorg-server 1.19.1. I'm on an intel GPU (Intel Corporation HD Graphics 5500 (rev 09)). I disabled sddm, and after re-installing xorg-server and xorg-server-common (1.19.1) and rebooting I was able to manually launch an xserver. However, sddm still hangs, and downgrading xorg-server to 1.19.0-6 did not help starting sddm again. Do I have to downgrade xorg-server-common as well?
Running X (started manually from terminal) now for about 2 hours and no crashes so far.

Downgrading to 1.19.0-6 does not seem to help indeed. So I went and checked my logs a couple of days ago, and noticed the crashes had begun mid-January, more precisely the exact day after I'd updated from 1.18.4-1 to 1.19.1-1. Downgraded to 1.18.4-1 and voilà! no more crashes.

I also had to downgrade xf86-input-libinput to 0.20.0-1 and xf86-input-wacom (because I've one of these Wacom pens) to 0.33.0-1. By the way, you need to add "--assume-installed xf86-input-driver" to pacman's parameters when doing so since it does not resolve that automatically (from what I understand, it's not a real package in the first place; it gets dynamically replaced by either xf86-input-libinput or xf86-input-evdev when you install xorg-server).

So it turns out 1.19 is behind the crashes after all...

loqs · 2017-01-23 19:46:10

99431 was closed as a duplicate of 99358. Does applying the three patches attached to that bug report solve the issue?
edit:
spelling

Last edited by loqs (2017-01-23 19:46:35)

Storm · 2017-01-24 09:33:07

Crashes has gone completely since I rolled back my system which also downgraded Xorg to 1.18.4-1

halogene wrote:

Do I have to downgrade xorg-server-common as well?

When you up- or downgrade packages that belong to the same software, that have the same version numbering, you should always up- or downgrade them together unless you have a specific reason to do it otherwise.

Downgrade all Xorg packages that have version number 1.19.x to 1.18.4-1.

loqs wrote:

Does applying the three patches attached to that bug report solve the issue?

I don't have the time to test it right now. Anyone else tried them yet?

halogene · 2017-01-24 10:06:13

Thank you - well I did try to roll back to 1.18.4-1, but libinput refused to let that happen. Tried to downgrade libinput to 0.20, but that failed too due to dependencies. I sure could have forced the downgrade but actually my xserver runs well, didn't have any crash at all so far and I'm again at 1.19.1. Only sddm doesn't seem to work so I disabled it via systemctl (systemctl disable sddm) and now I start x with startx for the time being. Given this is only a minor annoyance in my usage scenario I decided to leave it at this workaround until it gets fixed properly.

I have another, a bit aged core-i5-system with an nvidia GPU (660TI), but that one had no troubles with the updates. Runs smoothly and sddm works. Strange.

oeut1341 · 2017-01-24 18:41:08

loqs wrote:

99431 was closed as a duplicate of 99358. Does applying the three patches attached to that bug report solve the issue?

I tested the patches today and it does not solve the issue. Which is not that surprising since that bug has only got to do with the Intel driver (and the stack trace there also looks totally different compared to the ones we've reported in this thread).

Last edited by oeut1341 (2017-01-24 18:42:02)

loqs · 2017-01-24 22:08:37

oeut1341 wrote:

I tested the patches today and it does not solve the issue. Which is not that surprising since that bug has only got to do with the Intel driver (and the stack trace there also looks totally different compared to the ones we've reported in this thread).

Thank you for testing the patches.

Perhaps if you replied to 99358#c8 with your findings 99431 might be reopened or you may receive a more detailed explanation about why upstream found the bug report to be a duplicate.
Edit:
Apologies for not grasping the situation as well as I believe I currently do.

Michel Dänzer wrote:

(In reply to Storm Engineer from comment #1)
> See threads at Arch forums for people with nVidia cards crashing in the same
> manner:
> https://bbs.archlinux.org/viewtopic.php?id=221871
> https://bbs.archlinux.org/viewtopic.php?id=221958
I skimmed these for evidence supporting that they're about the same problem as in this report, but couldn't find any. Until there is such evidence, it's better to assume that there are multiple separate problems and track them separately.

So for Intel GPU's the patches may help. Upstream considered the Nvidia issue separate and requested a new issue be opened for it then as 99431 was thus reduced to Intel only cards it was merged with 99358.
Is there a new issue opened upstream relating to Nvidia cards?

Last edited by loqs (2017-01-25 04:22:18)

V1del · 2017-01-25 09:52:39

Something I notice with both of your reports (regarding the initial issue) Storm and oeut1341: Both of you are using xf86-input-wacom. And since libinput is supposed to replace everything™ and there have been large changes to the input stack, I wouldn't put it past that, that the issue here might lie with those two drivers biting and the Nvidia card not being as relevant as initially assumed, so it would be interesting if you could try to reproduce without the wacom driver. The stack traces from the KDE session also note globalaccel crashing, which is KDE's shortcut handler, ergo also something to do with input devices. Just a thought, I obviously don't have the hardware to test, the only thing I can say for certain is that I have no problems with an Nvidia Titan X and the nvidia drivers.

Last edited by V1del (2017-01-25 09:54:37)

Storm · 2017-01-27 09:55:46

Can someone who has a better understanding of things than me make a report upstream please? If nobody does it I will but I'm pretty much a noob so I would prefer someone more knowledgeable to do it.

oeut1341 · 2017-01-27 13:20:48

Update: having read V1del's attentive observations (thanks!), I went and uninstalled xf86-input-wacom (which, surprisingly, is not at all needed in order to use the Wacom pen I have, an Intuos CTL-480; I suppose libinput supports it natively now). I haven't had any crashes in the last couple of days, so this might just have fixed it.

Still, xf86-input-wacom was listed as supported here: https://www.archlinux.org/news/xorg-ser … -in-extra/

Last edited by oeut1341 (2017-01-27 13:22:15)

V1del · 2017-01-27 14:00:04

Well there have been some big changes in Xorg input which require the use of libinput (there was a blog post about multithreaded input making use of libinput), which is why it went from optional to required dep on Xorg. It is supposed to replace the other input drivers completely in the long run anyway. what would be interesting here, if the bug still occurs if you explicitly force the use of the wacom driver over libinput via Xorg configuration. If it doesn't it might be a conflict because Xorg attempts to use both drivers at the same time for the device, if it does we have found a bug in the xf86-input-wacom module, however the relevance upstream might not be as high since, as said libinput is the modern focus.

Last edited by V1del (2017-01-27 14:14:44)

Storm · 2017-01-29 21:39:17

I can't afford to uninstall input-wacom, no can I afford the crashes so now I'm locked with this old xorg server... great.

Did someone make any upstream tickets yet?

lboltzmann · 2017-02-07 12:07:29

I uninstalled xf86-input-wacom but I'm still getting random coredumps using the nvidia blobs. I'm not sure what to make of the stack trace. Seems to happen only when the workstation is being used.

First problem I've encountered where I couldn't find a good workaround/fix. Any help appreciated. Can't do any real work without the anxiety of being logged out randomly.

Christianh · 2017-02-07 21:03:39

I have the same issue Like most I have the same Wacom / Nvidia combination. I will try to uninstall xf86-input-wacom tomorrow (on my work computer). My other computer

As suggested before: downgrade all packages (begin januari?), ignore Xorg in pacman.conf and upgrade.

IgnoreGroup = xorg xorg-apps xorg-drivers

Where should we report this bug? Xorg? linuxwacom? Nvidia? Libinput?

Last edited by Christianh (2017-02-07 21:06:01)

Storm · 2017-02-21 12:19:08

Any news on this?

I'm still sitting on a downgraded system and don't know when can I have the time to upgrade again, check things and downgrade back if it still doesn't work.

lboltzmann · 2017-02-21 12:29:21

Storm wrote:

Any news on this?
I'm still sitting on a downgraded system and don't know when can I have the time to upgrade again, check things and downgrade back if it still doesn't work.

Removing the wacom libraries made Xorg crash less frequently for me. I also found out through trial and error that my old Nvidia Tesla card that I passed through to qemu via vfio was partly to blame for Xorg crashing; the memory on the card was failing. I removed the card and haven't seen a crash in 3 days. If your gfx cards are in good health with updated drivers and all the old xf86-input libraries are uninstalled, I would go ahead and try it to see what happens. Post your coredumps if it crashes. Wacom tablet seems to work fine without xf86-input-wacom.

Last edited by lboltzmann (2017-02-21 12:31:56)

Storm · 2017-03-02 09:54:08

lboltzmann wrote:

Wacom tablet seems to work fine without xf86-input-wacom.

Except I need my tablet's and stylus' buttons configured to specific actions for my workflow instead of the defaults and that cannot be done without xf86-input-wacom.

Storm · 2017-03-02 10:34:52

I hoped someone more qualified than me will make a ticket on the Wacom/nVidia crash but since nobody did it I just did. Please add your input, logs and useful information there:
https://bugs.freedesktop.org/show_bug.cgi?id=100033

lboltzmann · 2017-03-09 01:05:15

I've been running the xf86-input-wacom driver for over three days now. I have yet to experience a crash.

Storm · 2017-03-09 20:04:23

The Xorg patch made it into the Arch repos last week, and that fixed the crashes.

It did not fix the SDDM crash tho.

Also, now I have another issue: When my stylus is in use the GUI freezes constantly if xf86-input-wacom is installed. Xorg when patching the crash found a problem in xf86-input-wacom too and submitted a patch upstream, which is in testing already fro Arch since today. I don't know if that fixes the freezes.

I'll report back once the package is live in the normal repos and I could test it.

Arch Linux

#26 2017-01-18 21:32:25

Re: SDDM crash and random X crashes since upgrade

#27 2017-01-19 16:20:06

Re: SDDM crash and random X crashes since upgrade

#28 2017-01-20 22:57:04

Re: SDDM crash and random X crashes since upgrade

#29 2017-01-23 11:01:42

Re: SDDM crash and random X crashes since upgrade

#30 2017-01-23 13:02:08

Re: SDDM crash and random X crashes since upgrade

#31 2017-01-23 19:46:10

Re: SDDM crash and random X crashes since upgrade

#32 2017-01-24 09:33:07

Re: SDDM crash and random X crashes since upgrade

#33 2017-01-24 10:06:13

Re: SDDM crash and random X crashes since upgrade

#34 2017-01-24 18:41:08

Re: SDDM crash and random X crashes since upgrade

#35 2017-01-24 22:08:37

Re: SDDM crash and random X crashes since upgrade

#36 2017-01-25 09:52:39

Re: SDDM crash and random X crashes since upgrade

#37 2017-01-27 09:55:46

Re: SDDM crash and random X crashes since upgrade

#38 2017-01-27 13:20:48

Re: SDDM crash and random X crashes since upgrade

#39 2017-01-27 14:00:04

Re: SDDM crash and random X crashes since upgrade

#40 2017-01-29 21:39:17

Re: SDDM crash and random X crashes since upgrade

#41 2017-02-07 12:07:29

Re: SDDM crash and random X crashes since upgrade

#42 2017-02-07 21:03:39

Re: SDDM crash and random X crashes since upgrade

#43 2017-02-21 12:19:08

Re: SDDM crash and random X crashes since upgrade

#44 2017-02-21 12:29:21

Re: SDDM crash and random X crashes since upgrade

#45 2017-03-02 09:54:08

Re: SDDM crash and random X crashes since upgrade

#46 2017-03-02 10:34:52

Re: SDDM crash and random X crashes since upgrade

#47 2017-03-09 01:05:15

Re: SDDM crash and random X crashes since upgrade

#48 2017-03-09 20:04:23

Re: SDDM crash and random X crashes since upgrade

Board footer