Bug 1274162 - Segfault when switching docking stations
Segfault when switching docking stations
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
:
: 1274163 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-22 03:33 EDT by Tim Niemueller
Modified: 2016-07-19 14:18 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 14:18:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Niemueller 2015-10-22 03:33:36 EDT
Description of problem:
The following situation: I have a laptop and two docking stations (DS), one at work and one at home. Both have an external monitor. My setup is to mirror the screens (same resolution on both) so that I use the external screen and keep the lid closed (I'm not so much a multi-screen person). Further, most of the week I find myself simply plugging in my laptop and hitting the DS power button at work in the morning and putting it to sleep using the DS power button and unplugging it in the evening without ever opening it in between.

Now the problem is, that the mirroring will then not be properly enabled (or for any other reason the external screen does not get a signal). The manual workaround is to open the lid, start the display settings (gnome-control-center display). That will enable the external monitor (I guess during probing). Obviously this is rather annoying over time, so the following describes a workaround. The idea is to react to an event that is triggered on wakeup, check if an external monitor is connected, and if so briefly disable and re-enable it.

The brief disabling and re-enabling of the (mirrored) external screen makes gnome-shell segfault (almost always). Sometimes I get the grey screen to logout as it thinks it cannot recover. The workaround is described in detail at http://www.niemueller.de/blog/id/249.

Version-Release number of selected component (if applicable):
gnome-shell-3.16.3-1.fc22.x86_64

How reproducible:
Almost always

Steps to Reproduce:
See blog entry. I'm using a Lenovo Thinkpad T450s with ultra docks.

Actual results:
gnome-shell segfaults

Expected results:
Should not segfault.

Additional info:
journalctl /usr/bin/gnome-session gives (excerpt):
Okt 22 08:43:07 p gnome-session[19852]: gnome-session[19852]: WARNING: Application 'gnome-shell.desktop' killed by signal 11
Okt 22 08:43:07 p gnome-session[19852]: WARNING: Application 'gnome-shell.desktop' killed by signal 11

The same for gnome-shell has nothing relevant.

This might even be a problem in the graphics driver, as I do see the following crash report in dmesg:
[259174.209850] WARNING: CPU: 1 PID: 19790 at drivers/gpu/drm/i915/intel_display.c:1332 assert_plane.constprop.88+0x74/0xb0 [i915]()
[259174.209850] plane A assertion failure (expected on, current off)
[259174.209868] Modules linked in: ppp_mppe ppp_async crc_ccitt ppp_generic slhc nf_conntrack_pptp nf_conntrack_proto_gre hid_lenovo loop nls_utf8 isofs uas usb_storage vhost_net vhost macvtap macvlan ccm rfcomm cmac xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 fuse xt_conntrack ebtable_nat ebtable_broute bridge ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw uhid bnep arc4 intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp iwlmvm kvm_intel mac80211 iTCO_wdt iTCO_vendor_support kvm
[259174.209886]  snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic iwlwifi snd_hda_intel snd_hda_controller snd_hda_codec joydev cfg80211 i2c_i801 snd_hda_core snd_hwdep snd_seq btusb uvcvideo btbcm btintel bluetooth videobuf2_vmalloc videobuf2_core rtsx_pci_ms videobuf2_memops v4l2_common memstick videodev snd_seq_device media snd_pcm thinkpad_acpi mei_me tpm_tis wmi snd_timer mei lpc_ich tpm rfkill snd shpchp soundcore nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc btrfs xor raid6_pq dm_crypt 8021q garp stp llc mrp i915 rtsx_pci_sdmmc mmc_core i2c_algo_bit drm_kms_helper drm e1000e crct10dif_pclmul crc32_pclmul crc32c_intel ptp ghash_clmulni_intel serio_raw rtsx_pci pps_core mfd_core video
[259174.209888] CPU: 1 PID: 19790 Comm: Xorg Tainted: G        W       4.1.10-200.fc22.x86_64 #1
[259174.209889] Hardware name: LENOVO 20BX0011GE/20BX0011GE, BIOS JBET47WW (1.12 ) 03/10/2015
[259174.209891]  0000000000000000 00000000ce53cdc4 ffff88024643f5f8 ffffffff8179a79d
[259174.209891]  0000000000000000 ffff88024643f650 ffff88024643f638 ffffffff810a16aa
[259174.209892]  ffff88032af39a20 0000000000000000 ffff88032c3b0000 ffff880036af2800
[259174.209893] Call Trace:
[259174.209896]  [<ffffffff8179a79d>] dump_stack+0x45/0x57
[259174.209899]  [<ffffffff810a16aa>] warn_slowpath_common+0x8a/0xc0
[259174.209900]  [<ffffffff810a1735>] warn_slowpath_fmt+0x55/0x70
[259174.209929]  [<ffffffffa01d36b4>] assert_plane.constprop.88+0x74/0xb0 [i915]
[259174.209945]  [<ffffffffa01dba03>] hsw_disable_ips+0x43/0x1a0 [i915]
[259174.209966]  [<ffffffffa01dbde1>] intel_crtc_disable_planes+0x41/0x170 [i915]
[259174.209979]  [<ffffffffa01dcbd7>] haswell_crtc_disable+0x47/0x3c0 [i915]
[259174.209991]  [<ffffffffa01ddeaa>] __intel_set_mode+0xbaa/0xce0 [i915]
[259174.210003]  [<ffffffffa00d143e>] ? drm_atomic_get_crtc_state+0x1e/0xc0 [drm]
[259174.210015]  [<ffffffffa01e560f>] intel_crtc_set_config+0xd3f/0x1080 [i915]
[259174.210025]  [<ffffffffa00d13ec>] ? drm_atomic_state_free+0x2c/0x60 [drm]
[259174.210034]  [<ffffffffa00c1516>] drm_mode_set_config_internal+0x66/0x100 [drm]
[259174.210040]  [<ffffffffa0126d08>] restore_fbdev_mode+0xc8/0xf0 [drm_kms_helper]
[259174.210046]  [<ffffffffa0128d69>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[259174.210051]  [<ffffffffa0128de2>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
[259174.210063]  [<ffffffffa01f48ca>] intel_fbdev_set_par+0x1a/0x60 [i915]
[259174.210065]  [<ffffffff8134e85d>] ? context_struct_compute_av+0x34d/0x440
[259174.210068]  [<ffffffff8142aee6>] fb_set_var+0x236/0x480
[259174.210069]  [<ffffffff81337837>] ? avc_alloc_node+0x27/0x130
[259174.210071]  [<ffffffff813bf9f9>] ? flex_array_get_ptr+0x9/0x20
[259174.210072]  [<ffffffff8134e9b5>] ? type_attribute_bounds_av+0x65/0x2f0
[259174.210073]  [<ffffffff81337837>] ? avc_alloc_node+0x27/0x130
[259174.210075]  [<ffffffff814209bc>] fbcon_blank+0x34c/0x390
[259174.210078]  [<ffffffff814a8daa>] do_unblank_screen+0xda/0x1d0
[259174.210079]  [<ffffffff8149daeb>] vt_ioctl+0x56b/0x1420
[259174.210079]  [<ffffffff81337837>] ? avc_alloc_node+0x27/0x130
[259174.210081]  [<ffffffff81490641>] tty_ioctl+0x3f1/0xc30
[259174.210082]  [<ffffffff81338028>] ? avc_has_perm+0x128/0x1a0
[259174.210083]  [<ffffffff8123c5af>] ? putname+0x6f/0x80
[259174.210084]  [<ffffffff8123cf09>] ? do_unlinkat+0x109/0x320
[259174.210086]  [<ffffffff81240086>] do_vfs_ioctl+0x2c6/0x4d0
[259174.210087]  [<ffffffff81240311>] SyS_ioctl+0x81/0xa0
[259174.210089]  [<ffffffff817a0d6e>] system_call_fastpath+0x12/0x71
[259174.210090] ---[ end trace e6cfbe8876ee6018 ]---

I'm not certain since only the gnome-shell seems to crash, not X. If there is any other way to produce meaningful logs I'm happy to help.

Then again, maybe the original problem, that the screen is not properly woken up, should be the actual problem to be solved to not even need the described workaround.
Comment 1 Tim Niemueller 2015-10-22 03:35:17 EDT
*** Bug 1274163 has been marked as a duplicate of this bug. ***
Comment 2 Fedora End Of Life 2016-07-19 14:18:15 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.