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: NEW
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: 2016-11-22 12:07 EST (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: 2016-10-04 16:50:24 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. ***

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