Bug 1341327 - [abrt] xorg-x11-server-Xorg: Segmentation fault at address 0x34 when restart of systemd-udev-trigger.service causes 'replug' of hybrid graphics
[abrt] xorg-x11-server-Xorg: Segmentation fault at address 0x34 when restart ...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
24
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
abrt_hash:2ca0314eba957df347df612072c...
: Reopened
: 1382864 1397517 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-05-31 16:46 EDT by Onuralp SEZER
Modified: 2017-08-08 10:42 EDT (History)
34 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-08 10:42:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (697 bytes, text/plain)
2016-05-31 16:46 EDT, Onuralp SEZER
no flags Details
File: dmesg (87.64 KB, text/plain)
2016-05-31 16:50 EDT, Onuralp SEZER
no flags Details
File: dso_list (160 bytes, text/plain)
2016-05-31 16:51 EDT, Onuralp SEZER
no flags Details
File: etc_X11_xorg_conf_d.tar.gz (345 bytes, application/octet-stream)
2016-05-31 16:52 EDT, Onuralp SEZER
no flags Details
File: usr_share_xorg_conf_d.tar.gz (2.33 KB, application/octet-stream)
2016-05-31 16:52 EDT, Onuralp SEZER
no flags Details
journal output from affected time period, from klumbe (362.27 KB, text/plain)
2016-10-04 13:17 EDT, Adam Williamson
no flags Details
journalctl (30.11 KB, text/plain)
2016-10-04 20:13 EDT, srakitnican
no flags Details

  None (edit)
Description Onuralp SEZER 2016-05-31 16:46:41 EDT
Description of problem:
I was updating my system and suddenly It's crashed. and have "seg-fault"

Package list while I was updating.

systemd-compat-libs-229-8.fc24.x86_64         Tue 31 May 2016 11:38:43 PM EEST
nss-softokn-freebl-3.24.0-1.0.fc24.i686       Tue 31 May 2016 11:38:43 PM EEST
mailcap-2.1.46-1.fc24.noarch                  Tue 31 May 2016 11:38:43 PM EEST
libsolv-0.6.20-3.fc24.x86_64                  Tue 31 May 2016 11:38:43 PM EEST
dmidecode-3.0-3.fc24.x86_64                   Tue 31 May 2016 11:38:43 PM EEST
systemd-udev-229-8.fc24.x86_64                Tue 31 May 2016 11:38:42 PM EEST
nss-tools-3.24.0-1.1.fc24.x86_64              Tue 31 May 2016 11:38:42 PM EEST
libinput-1.3.1-1.fc24.x86_64                  Tue 31 May 2016 11:38:42 PM EEST
systemd-229-8.fc24.x86_64                     Tue 31 May 2016 11:38:41 PM EEST
systemd-libs-229-8.fc24.x86_64                Tue 31 May 2016 11:38:38 PM EEST
nss-sysinit-3.24.0-1.1.fc24.x86_64            Tue 31 May 2016 11:38:38 PM EEST
nss-softokn-freebl-3.24.0-1.0.fc24.x86_64     Tue 31 May 2016 11:38:38 PM EEST
nss-softokn-3.24.0-1.0.fc24.x86_64            Tue 31 May 2016 11:38:38 PM EEST
nss-3.24.0-1.1.fc24.x86_64                    Tue 31 May 2016 11:38:38 PM EEST
nss-util-3.24.0-1.0.fc24.x86_64               Tue 31 May 2016 11:38:37 PM EEST

Version-Release number of selected component:
xorg-x11-server-Xorg-1.18.3-2.fc24

Additional info:
reporter:       libreport-2.7.1
executable:     /usr/libexec/Xorg
kernel:         4.5.5-300.fc24.x86_64
pkg_fingerprint: 73BD E983 81B4 6521
pkg_vendor:     Fedora Project
reproducible:   Not sure how to reproduce the problem
runlevel:       N 5
type:           xorg
uid:            0

Truncated backtrace:
0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x59fbd9]
1: /lib64/libc.so.6 (__restore_rt+0x0) [0x7f42b95ececf]
2: /usr/libexec/Xorg (RRTellChanged+0x165) [0x4f8c85]
3: /usr/libexec/Xorg (xf86PlatformDeviceCheckBusID+0x2d6) [0x49d016]
4: /usr/libexec/Xorg (config_fini+0x7ef) [0x4994ef]
5: /usr/libexec/Xorg (config_fini+0x13e0) [0x49ad20]
6: /usr/libexec/Xorg (WakeupHandler+0x70) [0x43b860]
7: /usr/libexec/Xorg (WaitForSomething+0x1e9) [0x598569]
8: /usr/libexec/Xorg (SendErrorToClient+0x10e) [0x436b4e]
9: /usr/libexec/Xorg (remove_fs_handlers+0x463) [0x43ad83]
10: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x7f42b95d8731]
11: /usr/libexec/Xorg (_start+0x29) [0x424bc9]
12: ? (?+0x29) [0x29]
Comment 1 Onuralp SEZER 2016-05-31 16:46:48 EDT
Created attachment 1163358 [details]
File: backtrace
Comment 2 Onuralp SEZER 2016-05-31 16:50:11 EDT
Created attachment 1163360 [details]
File: dmesg
Comment 3 Onuralp SEZER 2016-05-31 16:51:23 EDT
Created attachment 1163361 [details]
File: dso_list
Comment 4 Onuralp SEZER 2016-05-31 16:52:00 EDT
Created attachment 1163362 [details]
File: etc_X11_xorg_conf_d.tar.gz
Comment 5 Onuralp SEZER 2016-05-31 16:52:17 EDT
Created attachment 1163363 [details]
File: usr_share_xorg_conf_d.tar.gz
Comment 6 spam.klumbe 2016-10-04 11:42:20 EDT
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]
Comment 7 Adam Williamson 2016-10-04 13:15:23 EDT
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).
Comment 8 Adam Williamson 2016-10-04 13:17 EDT
Created attachment 1207294 [details]
journal output from affected time period, from klumbe
Comment 9 Stephen Gallagher 2016-10-04 13:39:41 EDT
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?
Comment 10 Adam Williamson 2016-10-04 13:46:15 EDT
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.
Comment 11 Adam Williamson 2016-10-04 16:36:38 EDT
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.
Comment 12 Zbigniew Jędrzejewski-Szmek 2016-10-04 16:41:27 EDT
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.
Comment 13 Zbigniew Jędrzejewski-Szmek 2016-10-04 16:50:24 EDT
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 ***
Comment 14 Adam Williamson 2016-10-04 16:53:00 EDT
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.
Comment 15 srakitnican 2016-10-04 19:46:11 EDT
Well, systemctl restart systemd-udev-trigger.service affects my desktop Ivy Bridge. No hybrids here.
Comment 16 Adam Williamson 2016-10-04 19:48:53 EDT
srakitnican: yikes, by 'affects' you mean 'X crashes'? Can you post the output of 'lspci -nn'? Thanks!
Comment 17 srakitnican 2016-10-04 19:53:59 EDT
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)
Comment 18 Adam Williamson 2016-10-04 19:56:52 EDT
srakitnican: thanks. can you also check in the journal if the backtrace you get looks the same?
Comment 19 srakitnican 2016-10-04 20:13 EDT
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
Comment 20 Adam Williamson 2016-10-04 20:17:50 EDT
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...
Comment 21 Steve 2016-10-04 22:31:27 EDT
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
Comment 22 Adam Williamson 2016-10-04 22:57:24 EDT
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?
Comment 23 Steve 2016-10-05 00:39:57 EDT
yum log shows a different issue, user error (overzealous removal of superfluous packages).
Comment 24 srakitnican 2016-10-05 04:12:46 EDT
(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.
Comment 25 Karel Volný 2016-10-05 04:36:34 EDT
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 ...?
Comment 26 Hans de Goede 2016-10-05 10:56:42 EDT
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
Comment 27 Hans de Goede 2016-10-06 07:33:23 EDT
Removing 2 see also bugs which are for a different issue (which is fixed in f25 updates-testing now).
Comment 28 Ashesh Kumar Singh 2016-10-07 18:33:13 EDT
*** Bug 1382864 has been marked as a duplicate of this bug. ***
Comment 29 Naipaul Ojar 2016-11-22 12:07:53 EST
*** Bug 1397517 has been marked as a duplicate of this bug. ***
Comment 30 Fedora End Of Life 2017-07-25 16:57:30 EDT
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.
Comment 31 Fedora End Of Life 2017-08-08 10:42:47 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.