Created attachment 1163358 [details]
File: backtrace

Created attachment 1163360 [details]
File: dmesg

Created attachment 1163361 [details]
File: dso_list

Created attachment 1163362 [details]
File: etc_X11_xorg_conf_d.tar.gz

Created attachment 1163363 [details]
File: usr_share_xorg_conf_d.tar.gz

Description of problem:
- ran "sudo dnf update" on a workstation edition (gnome-terminal)
- got thrown back to the login-screen (which seems to be the point where the crash happened)
- now have duplicated packages (like systemd)

Version-Release number of selected component:
xorg-x11-server-Xorg-1.18.4-4.fc24

Additional info:
reporter:       libreport-2.7.2
executable:     /usr/libexec/Xorg
kernel:         4.7.5-200.fc24.x86_64
pkg_fingerprint: 73BD E983 81B4 6521
pkg_vendor:     Fedora Project
runlevel:       N 5
type:           xorg
uid:            0

Truncated backtrace:
0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x59f679]
1: /lib64/libc.so.6 (__restore_rt+0x0) [0x7ff4abc4976f]
2: /usr/libexec/Xorg (RRTellChanged+0x165) [0x4f87b5]
3: /usr/libexec/Xorg (xf86PlatformDeviceCheckBusID+0x2d6) [0x49cff6]
4: /usr/libexec/Xorg (config_fini+0x7ef) [0x4994cf]
5: /usr/libexec/Xorg (config_fini+0x13e0) [0x49ad00]
6: /usr/libexec/Xorg (WakeupHandler+0x6d) [0x43b94d]
7: /usr/libexec/Xorg (WaitForSomething+0x1e9) [0x597fb9]
8: /usr/libexec/Xorg (SendErrorToClient+0x10e) [0x436c5e]
9: /usr/libexec/Xorg (remove_fs_handlers+0x463) [0x43ae63]
10: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x7ff4abc35731]
11: /usr/libexec/Xorg (_start+0x29) [0x424d59]
12: ? (?+0x29) [0x29]

The dmesg output from the original reporter shows that they have a dual GPU nvidia/intel device, and the second reporter said on IRC they also have a system with that hardware. Here are their hardware details:

00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller [8086:0044] (rev 18)
00:01.0 PCI bridge [0604]: Intel Corporation Core Processor PCI Express x16 Root Port [8086:0045] (rev 18)
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 18)
00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 Series Chipset HECI Controller [8086:3b64] (rev 06)
00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 06)
00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio [8086:3b56] (rev 06)
00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 [8086:3b42] (rev 06)
00:1c.1 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 [8086:3b44] (rev 06)
00:1c.3 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 4 [8086:3b48] (rev 06)
00:1c.4 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 5 [8086:3b4a] (rev 06)
00:1c.5 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 6 [8086:3b4c] (rev 06)
00:1d.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b34] (rev 06)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev a6)
00:1f.0 ISA bridge [0601]: Intel Corporation HM57 Chipset LPC Interface Controller [8086:3b0b] (rev 06)
00:1f.2 SATA controller [0106]: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller [8086:3b2f] (rev 06)
00:1f.3 SMBus [0c05]: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller [8086:3b30] (rev 06)
00:1f.6 Signal processing controller [1180]: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem [8086:3b32] (rev 06)
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108M [GeForce GT 420M] [10de:0df1] (rev a1)
04:00.0 Network controller [0280]: Intel Corporation Centrino Wireless-N 1000 [Condor Peak] [8086:0083]
05:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 03)
09:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
ff:00.0 Host bridge [0600]: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers [8086:2c62] (rev 05)
ff:00.1 Host bridge [0600]: Intel Corporation Core Processor QuickPath Architecture System Address Decoder [8086:2d01] (rev 05)
ff:02.0 Host bridge [0600]: Intel Corporation Core Processor QPI Link 0 [8086:2d10] (rev 05)
ff:02.1 Host bridge [0600]: Intel Corporation 1st Generation Core i3/5/7 Processor QPI Physical 0 [8086:2d11] (rev 05)
ff:02.2 Host bridge [0600]: Intel Corporation 1st Generation Core i3/5/7 Processor Reserved [8086:2d12] (rev 05)
ff:02.3 Host bridge [0600]: Intel Corporation 1st Generation Core i3/5/7 Processor Reserved [8086:2d13] (rev 05)

The new reporter also provided journal output. I'll attach it. From it, we can see that the crash appears to happen during systemd daemon re-execution (which happens as part of the systemd package's scriptlets).

Created attachment 1207294 [details]
journal output from affected time period, from klumbe

I see that this was with an nVidia graphics card. Are you using the built-in "nouveau" driver or are you using the proprietary nVidia driver?

Both reporters are using nouveau, it's clear from the journal output (klumbe) and dmesg output (onuralp).

Here's the edited highlights from the journal, which make it (I think) fairly clear roughly what's going on:

Oct 04 12:52:00 localhost.localdomain systemd[1]: Reexecuting.
...
Oct 04 12:52:32 localhost.localdomain systemd[1]: Stopping udev Coldplug all Devices...
Oct 04 12:52:32 localhost.localdomain systemd[1]: Starting udev Coldplug all Devices...
...
Oct 04 12:52:33 localhost.localdomain systemd[1]: Started udev Coldplug all Devices.
...
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (II) config/udev: removing GPU device /sys/devices/pci0000:00/0000:00:01.0/0000:02:00.0/drm/card1 /dev/dri/card1
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: xf86: remove device 0 /sys/devices/pci0000:00/0000:00:01.0/0000:02:00.0/drm/card1
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (II) NOUVEAU(G0): NVLeaveVT is called.
Oct 04 12:52:33 localhost.localdomain systemd-logind[886]: Watching system buttons on /dev/input/event2 (Lid Switch)
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (II) UnloadModule: "nouveau"
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (II) UnloadSubModule: "exa"
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (II) Unloading exa
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (II) UnloadSubModule: "shadowfb"
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (II) Unloading shadowfb
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (II) UnloadSubModule: "fb"
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (II) Unloading fb
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (II) systemd-logind: releasing fd for 226:1
Oct 04 12:52:33 localhost.localdomain systemd-logind[886]: Watching system buttons on /dev/input/event7 (Video Bus)
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE)
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) Backtrace:
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x59f679]
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) 1: /lib64/libc.so.6 (__restore_rt+0x0) [0x7ff4abc4976f]
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) 2: /usr/libexec/Xorg (RRTellChanged+0x165) [0x4f87b5]
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) 3: /usr/libexec/Xorg (xf86PlatformDeviceCheckBusID+0x2d6) [0x49cff6]
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) 4: /usr/libexec/Xorg (config_fini+0x7ef) [0x4994cf]
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) 5: /usr/libexec/Xorg (config_fini+0x13e0) [0x49ad00]
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) 6: /usr/libexec/Xorg (WakeupHandler+0x6d) [0x43b94d]
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) 7: /usr/libexec/Xorg (WaitForSomething+0x1e9) [0x597fb9]
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) 8: /usr/libexec/Xorg (SendErrorToClient+0x10e) [0x436c5e]
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) 9: /usr/libexec/Xorg (remove_fs_handlers+0x463) [0x43ae63]
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x7ff4abc35731]
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) 11: /usr/libexec/Xorg (_start+0x29) [0x424d59]
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) 12: ? (?+0x29) [0x29]
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE)
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) Segmentation fault at address 0x34
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE)
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: Fatal server error:
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) Caught signal 11 (Segmentation fault). Server aborting
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE)
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE)
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: Please consult the Fedora Project support
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]:          at http://wiki.x.org
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]:  for help.
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE) Please also check the log file at "/home/muellerc/.local/share/xorg/Xorg.0.log" for additional information.
Oct 04 12:52:33 localhost.localdomain /usr/libexec/gdm-x-session[1534]: (EE)

basically, it looks like the systemd re-exec triggers a udev coldplug of the video adapter, which in turn leads to X exploding.

Some more info here, thanks to Zbyszek. It seems we've discovered a reliable trigger for the bug on klumbe's system: `systemctl restart systemd-udev-trigger.service` , and more specifically, `udevadm trigger --type=devices --action=add` .

The service restart happens in systemd-udev package %post, and runs that udevadm command. It seems that is what causes the video hardware to be effectively 'replugged', which in turn causes the X crash.

zbyszek says he thinks this should probably be considered a bug on systemd's end (this 'replug' should not really be happening), and he's going to remove the systemd-udev-trigger service restart as a short-term workaround, then see if he can figure out why it's causing the replug (he thinks it may be that the udevadm trigger call 'confuses' systemd-logind, which actually does the replug) and stop that happening.

Meanwhile on the other end of the problem, we're still not yet totally sure under what circumstances X crashes when this happens and under what circumstances it doesn't, and whether we should also consider that a bug in X or not. Ben Skeggs suggests that it might be the case that X will always crash in this situation on hybrid graphics systems - not just NVIDIA/Intel hybrid, but any hybrid case. So I'll send out a call for testing to try and get some data here. For now, let's assign this to systemd.

There's 1378974 which is a duplicate. I'll leave this one open for xorg-x11-server-Xorg in case the Xorg guys want to look at the segmentation fault crash.

Never mind, somehow I missed that adamw reassigned this to systemd. It does not make sense to keep two bugs open.

*** This bug has been marked as a duplicate of bug 1378974 ***

OK. Re-assigning this back to X, then, and I'll propose 1378974 as an FE for F25 Beta.

We have had reports from two AMD/Intel hybrid graphics users - Luya (finalzone) and irishluck83 on IRC - that the bug affects them. Luya reported no bug on a system with a dedicated graphics adapter. So evidence seems to be building for the theory that it's hybrid graphics systems - all hybrid graphics systems - that crash.

Well, systemctl restart systemd-udev-trigger.service affects my desktop Ivy Bridge. No hybrids here.

srakitnican: yikes, by 'affects' you mean 'X crashes'? Can you post the output of 'lspci -nn'? Thanks!

Yes, X crashes to login screen. Wayland is not affected by this.

$ lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller [8086:0150] (rev 09)
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev 09)
00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4)
00:1c.4 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev c4)
00:1c.5 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 6 [8086:1e1a] (rev c4)
00:1c.7 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 8 [8086:1e1e] (rev c4)
00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
00:1f.0 ISA bridge [0601]: Intel Corporation H77 Express Chipset LPC Controller [8086:1e4a] (rev 04)
00:1f.2 RAID bus controller [0104]: Intel Corporation SATA Controller [RAID mode] [8086:2822] (rev 04)
00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller [8086:1e22] (rev 04)
02:00.0 PCI bridge [0604]: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge [1b21:1080] (rev 01)
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
05:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 01)

srakitnican: thanks. can you also check in the journal if the backtrace you get looks the same?

Created attachment 1207416 [details]
journalctl

Actually, no, it seems it is not producing a backtrace for some reason. Attached relevant portion of the log.

Oct 05 01:38:43 rawhide abrt-hook-ccpp[18415]: Process 17110 (Xorg) of user 1000 killed by SIGSEGV - dumping core
Oct 05 01:38:44 rawhide abrt-hook-ccpp[18415]: Failed to create core_backtrace: dwfl_getthread_frames failed: No DWARF information found

yeah, that doesn't look quite the same, though I bet it's the same general *type* of bug (wackiness caused by this hardware replug thing going on). The gnome-settings-daemon null pointers likely have something to do with it. Could you open a new bug, but with 'see also' for this bug and 1378974 , and include the log and the lspci output and also lsusb? Thanks...

This bug is possibly present in CentOS-7 and the yum system.  I did an yum update (04102016) on a VM and the result was as described in this report

Steve: when you say 'as described', does your system / X log (I don't know if X logs are still separate on EL 7) show the same X traceback?

yum log shows a different issue, user error (overzealous removal of superfluous packages).

(In reply to Adam Williamson from comment #20)
> yeah, that doesn't look quite the same, though I bet it's the same general
> *type* of bug (wackiness caused by this hardware replug thing going on). The
> gnome-settings-daemon null pointers likely have something to do with it.
> Could you open a new bug, but with 'see also' for this bug and 1378974 , and
> include the log and the lspci output and also lsusb? Thanks...

I've opened 1381840, not sure how to set See Also field or if I am allowed.

I can confirm that `udevadm trigger --type=devices --action=add` triggers the problem on my system (intel+nouveau), however, at first, I didn't get any X crash, now on another try, abrt complains that the backtrace is unusable and connects the crash with https://retrace.fedoraproject.org/faf/reports/486741/ which is not linked to this bug ...?

Hi,

I've tried to reproduce this on Fedora-25 with xserver-1.19 (using updated pkgs to fix bug 1381840), but the xserver does not crash there. What does happen is that the secondary GPU no longer shows in "xrandr --list-providers", which also is not good.

I've 2 days of PTO coming up, then a week at ELCE and when I'm back from ELCE I need to do some other stuff before I can look into this. I do plan to look into this soon after ELCE.

Regards,

Hans

Removing 2 see also bugs which are for a different issue (which is fixed in f25 updates-testing now).

*** Bug 1382864 has been marked as a duplicate of this bug. ***

*** Bug 1397517 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.