Bug 1316877 - System freeze when closing display, using external monitors through dock
System freeze when closing display, using external monitors through dock
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
23
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-11 06:38 EST by Jelmer Verkleij
Modified: 2017-06-30 05:37 EDT (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 14:23:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Logs right after suspend (29.67 KB, text/plain)
2016-06-01 08:08 EDT, Dmitry Tantsur
no flags Details

  None (edit)
Description Jelmer Verkleij 2016-03-11 06:38:20 EST
User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36
Build Identifier: 

I'm seeing various issues with a Lenovo Thinkpad T460s on Fedora 23, which all (to my mind) seem to trace back to the display driver. Unfortunately the journal logging gets corrupted after each hang so I lose any debugging that is logged in there after any hang occurs. The graphics module is an Intel HD Graphics 520.

I know that generally speaking separate bugs should be reported separately, but since I get the feeling these are connected I thought I'd start with a combined report. If this is unwanted, just let me know and I will file separate reports for each of these.

1) Closing display causes hang
Whenever the laptop display is closed and reopened, the system is frozen. The display does seem to turn off when it's closed (and turns back on when reopened) but X seems to hang completely. This happens regardless of the Power Management settings (do nothing or suspend). An interesting note: when the power cord is plugged in, this particular issue goes away for the most part (but sometimes still plays up); it will then often simply lock the display or suspend the system (whichever is configured in Power Management).

2) Booting the system on a dock with connected external monitors causes kernel panic
When an external monitor is connected to the dock and the system boots while docked, the first boot produces kernel errors (this happens before the encrypted filesystem is even mounted):

[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
[drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit
[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
[drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit
[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
[drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit
[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
[drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit
[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
[drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit
[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
[drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit
random: nonblocking pool is initialized
[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many voltage retries, give up
[drm:intel_dp_link_training_channel_equalization [i915]] *ERROR* failed to train DP, aborting
[drm:intel_dp_link_training_channel_equalization [i915]] *ERROR* Timed out waiting for DP idle patterns
Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler
Shutting down cpus with NMI
Kernel Offset: disabled
Rebooting in 30 seconds..
ACPI MEMORY or I/O RESET_REG

After the reboot, the system gets past these errors and seems to boot properly, but at the point where usually the login prompt would show up the screen remains blank. This very much looks like X refusing to start, although unfortunately I don't have any logging to support this.

3) Enabling an external monitor connected through dock causes hang
When the laptop is connected to the dock after boot, or when the laptop boots in the dock and the monitor is connected after, the system runs fine but the external monitor is disabled by default. It is detected and shows up in the Display configuration screen with the correct make and model data. Enabling the monitor in the Display configuration screen causes a X to hang completely.

Reproducible: Always

Steps to Reproduce:
1) Closing display causes hang
1. Close the display while the system is powered on

2) Booting the system on a dock with connected external monitors causes kernel panic
1. Connect an external monitor to a docking station
2. Connect the laptop to the docking station while powered off
3. Power on the laptop

3) Enabling an external monitor connected through dock causes hang
1. Connect an external monitor to a docking station
2. Power on the laptop (while it isn't yet connected to the dock)
3. Connect the laptop to the docking station while powered on
4. Enable the external monitor
Actual Results:  
1) The screen locks / the system suspends (depending on power settings)
2) The system boots
3) The external monitor is enabled

Expected Results:  
1) X hangs
2) Kernel panic / X fails to start
3) X hangs
Comment 1 Warren Togami 2016-03-16 03:56:20 EDT
https://kojipkgs.fedoraproject.org/packages/kernel/4.4.5/300.fc23/
The X hang on suspend seems to be solved by upgrading to kernel-4.4.5-300.fc23.

There remain other problems with the X driver after it has resumed from suspend.

https://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-intel/2.99.917/
It seems to be more stable with xorg-x11-drv-intel-2.99.917-22.20160119.fc24 which easily rebuilds for F23.  There's a clue as to why in the changelog.

%changelog
* Mon Mar 07 2016 Hans de Goede <hdegoede@redhat.com> - 2.99.917-22.20160119
- xorg-x11-drv-intel hardly has any accel on skylake and newer, so make
  Xorg fallback to modesetting + glamor by returning FALSE from probe
- Using glamor also gives us proper Xvideo support on skylake (rhbz#1305369)

* Fri Feb 05 2016 Fedora Release Engineering <releng@fedoraproject.org> - 2.99.917-21.20160119
- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild

* Tue Jan 19 2016 Kevin Fenzi <kevin@scrye.com> - 2.99.917-20-20160119
- Update to 20160119 snapshot
Comment 2 Warren Togami 2016-03-16 15:48:03 EDT
kernel-4.4.5-300 and/or xorg-x11-drv-intel-2.99.917-22.20160119 seems to have also fixed the hang/crash upon VT switch while plugged into an external display via mini DisplayPort.
Comment 3 Warren Togami 2016-03-16 16:50:32 EDT
kernel-4.4.5-300 (custom build with unrelated patch on touchpad driver)
xorg-x11-drv-intel-2.99.917-22.20160119

[   25.372755] ------------[ cut here ]------------
[   25.372777] WARNING: CPU: 0 PID: 1876 at drivers/gpu/drm/i915/intel_pm.c:3601 skl_update_other_pipe_wm+0x1de/0x1f0 [i915]()
[   25.372779] WARN_ON(!wm_changed)
[   25.372780] Modules linked in:
[   25.372781]  ccm cmac xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_filter ebtable_broute bridge ebtable_nat ebtables ip6table_security ip6table_raw ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_filter ip6_tables iptable_security iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle bnep dm_crypt arc4 intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp kvm_intel kvm snd_soc_skl snd_hda_codec_hdmi iTCO_wdt snd_soc_skl_ipc iTCO_vendor_support snd_hda_ext_core snd_soc_sst_ipc snd_hda_codec_realtek iwlmvm snd_soc_sst_dsp irqbypass snd_hda_codec_generic snd_soc_core crct10dif_pclmul mac80211
[   25.372808]  crc32_pclmul crc32c_intel snd_compress vfat snd_pcm_dmaengine ac97_bus dw_dmac_core fat snd_hda_intel snd_hda_codec uvcvideo btusb snd_hda_core snd_hwdep iwlwifi btrtl snd_seq videobuf2_vmalloc videobuf2_memops btbcm snd_seq_device videobuf2_v4l2 btintel bluetooth videobuf2_core snd_pcm v4l2_common cfg80211 videodev joydev rtsx_pci_ms media memstick mei_me snd_timer i2c_i801 mei thinkpad_acpi shpchp snd soundcore wmi tpm_crb rfkill tpm_tis tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc 8021q garp stp llc mrp i915 rtsx_pci_sdmmc mmc_core e1000e i2c_algo_bit drm_kms_helper drm ptp pps_core serio_raw nvme rtsx_pci video fjes
[   25.372841] CPU: 0 PID: 1876 Comm: Xorg Tainted: G        W       4.4.5-300.fc23.x86_64 #1
[   25.372842] Hardware name: LENOVO 20F9CTO1WW/20F9CTO1WW, BIOS N1CET38W (1.06 ) 02/03/2016
[   25.372843]  0000000000000286 0000000085831796 ffff8805014577c8 ffffffff813b54ae
[   25.372846]  ffff880501457810 ffffffffa022cbf8 ffff880501457800 ffffffff810a40f2
[   25.372848]  ffff880501457934 ffff88003f852000 ffff88003f854000 0000000000000000
[   25.372850] Call Trace:
[   25.372855]  [<ffffffff813b54ae>] dump_stack+0x63/0x85
[   25.372858]  [<ffffffff810a40f2>] warn_slowpath_common+0x82/0xc0
[   25.372860]  [<ffffffff810a418c>] warn_slowpath_fmt+0x5c/0x80
[   25.372874]  [<ffffffffa0167d6e>] skl_update_other_pipe_wm+0x1de/0x1f0 [i915]
[   25.372887]  [<ffffffffa0167fd2>] skl_update_wm+0x252/0x750 [i915]
[   25.372905]  [<ffffffffa01b0e64>] ? gen9_read32+0x124/0x2f0 [i915]
[   25.372919]  [<ffffffffa016c4de>] intel_update_watermarks+0x1e/0x30 [i915]
[   25.372938]  [<ffffffffa01d06c2>] intel_atomic_commit+0x462/0x1420 [i915]
[   25.372952]  [<ffffffffa007b1be>] ? drm_atomic_check_only+0x18e/0x590 [drm]
[   25.372964]  [<ffffffffa007b5f7>] drm_atomic_commit+0x37/0x60 [drm]
[   25.372971]  [<ffffffffa00d34c6>] drm_atomic_helper_set_config+0x76/0xb0 [drm_kms_helper]
[   25.372980]  [<ffffffffa006ab62>] drm_mode_set_config_internal+0x62/0x100 [drm]
[   25.372991]  [<ffffffffa006eee2>] drm_mode_setcrtc+0x3d2/0x4f0 [drm]
[   25.372998]  [<ffffffffa0060602>] drm_ioctl+0x152/0x540 [drm]
[   25.373008]  [<ffffffffa006eb10>] ? drm_mode_setplane+0x1b0/0x1b0 [drm]
[   25.373011]  [<ffffffff8133fc7c>] ? selinux_file_ioctl+0x10c/0x1c0
[   25.373014]  [<ffffffff81241248>] do_vfs_ioctl+0x298/0x480
[   25.373017]  [<ffffffff81337533>] ? security_file_ioctl+0x43/0x60
[   25.373020]  [<ffffffff812414a9>] SyS_ioctl+0x79/0x90
[   25.373022]  [<ffffffff817a052e>] entry_SYSCALL_64_fastpath+0x12/0x71
[   25.373024] ---[ end trace 0b5639353d90fdfe ]---
Comment 4 Warren Togami 2016-03-17 15:24:12 EDT
Correction: With the above kernel and xorg-x11-drv-intel it seems to avoid immediate hang with suspend or external displays, but it does sometimes hang or glitch often requiring a reboot.  Not entirely stable.
Comment 5 Carl Henrik Lunde 2016-03-18 17:00:20 EDT
For the T460s, try with this patch on top of 4.4.6-300: https://lkml.org/lkml/2016/3/17/563

I still have xorg-x11-drv-intel-2.99.917-19.20151206.fc23.x86_64, and I have not yet had any issues with suspend/resume with this patch.  I believe the mini displayport issue was fixed by a kernel update for me.
Comment 6 Jelmer Verkleij 2016-03-21 04:25:45 EDT
The suspend error has been fixed with that kernel patch. The external displays still cause consistent hangs unfortunately.
Comment 7 Jelmer Verkleij 2016-03-21 13:32:08 EDT
On a hunch I decided to install the newest xorg-x11-server-common from F23 updates-testing (1.18.2-2.fc23) and all my issues have disappeared. Perhaps something for you guys to test if it fixes your issues as well?
Comment 8 Jelmer Verkleij 2016-03-22 05:55:24 EDT
Well, this is unfortunate. Yesterday everything seemed to work perfectly, this morning I tried to do the same and everything was back to the broken state. Nothing changed package-wise so I am clueless regarding the cause.

Suspend on lid close still works by the way, so the kernel patch still has its effects. It's just the display management that has resumed crashing.

(Note that the 'fix' of updating xorg-x11-server-common was in combination with the patched 4.4.6-300 kernel, something I forgot to mention in my previous update.)
Comment 9 Warren Togami 2016-03-25 17:32:41 EDT
http://marc.info/?l=linux-kernel&m=145879265604154&w=2
v7 of the aforementioned patch seems to substantially help.  After I applied it against kernel-4.4.6-300.fc23.x86_64 my Thinkpad T460s has not crashed once.
Comment 10 Jelmer Verkleij 2016-03-29 05:25:34 EDT
That patch unfortunately did not change the external display issue for me. Suspend on lid close is unchanged (i.e. still works).
Comment 11 gingerling 2016-04-18 10:18:26 EDT
I have this bug, when I close the lid of my new laptop, it "hangs". I tired locking the screen (I clicked the padlock icon in the dropdown from system icons area) before closing the lid to see if it helped, it seemed okay, but then the laptop overheated very badly in my bag. 

Is there anything I can do to help? Any logs I can provide etc?
Comment 12 Paolo Leoni 2016-04-27 15:42:15 EDT
I have this bug: using F23 with xorg-x11-drv-intel 2.99.917-19.20151206 and Kernel 4.4.7-300.fc23.x86_64

Downgrading to xorg-x11-drv-intel-2.99.917-16.20150729 I haven't any problem closing the lid.
Comment 13 Paolo Leoni 2016-05-18 04:13:46 EDT
Update:
I have this bug also in Fedora 24 Beta. It's a real problem for my daily use...no problem if I enable wayland before login.
Comment 14 gingerling 2016-05-22 08:47:02 EDT
For anyone who is less technical than these guys and really stuck, one solution which 100% removes the issue is to use wayland. When logging in you can click the little cog icon and choose gnome-wayland then log in. Without getting into a complex description of why, that does totally fix the issue by side-stepping the system were the issue is.
Comment 15 Dmitry Tantsur 2016-05-31 05:09:20 EDT
I'm not sure my problems are strictly the same, but still to weigh in: suspend causes freeze for me on T460s with F24 (Mate). It does not matter whether the power is connected or not. It does not matter how I enter suspend (closing lid, using mint menu, using systemctl suspend). When I move out of suspend I only see black screen. The same result with kernel 4.6.0 from rawhide. Did not try with wayland, as I don't think Mate supports it.
Comment 16 Vitezslav Humpa 2016-06-01 03:57:11 EDT
Had the same (remaining) issues on freshly installed F24. Update to the 4.7 kernel (4.7.0-0.rc0.git10.1.fc25.x86_64 - and kernel only, don't update the driver or mesa) from rawhide fixes the issues with multihead/dockstation, suspend also works. One issue left is that kernel sometimes panics on redocking the laptop.
Comment 17 Dmitry Tantsur 2016-06-01 06:24:02 EDT
The latest 4.7 from rawhide has the same problems for me as 4.5: freeze after suspend and external monitors are not detected.
Comment 18 Nitin Bansal 2016-06-01 06:32:36 EDT
Fedora 24 Beta on ThinkPad T460s, I can't get two external displays connected via docking station (displayports) to work when using X, system simply freezes. It's a bit better on Wayland but I have to first boot it without docking station. Same issue on 4.7 kernel as well.
Comment 19 Vitezslav Humpa 2016-06-01 06:56:38 EDT
With 4.7 I only have issues with suspend when I suspend undocked and resume docked, which is the same situation as redocking. What works to bypass this crash is to let the redocking happen "under" wayland - jump from the Gnome X session back to the GDM before redocking (i.e. via 'switch user'). Coming back to the running session does restore the external display configuration properly for me. Worth mentioning my displays are DVI and VGA.
Comment 20 Dmitry Tantsur 2016-06-01 08:08 EDT
Created attachment 1163618 [details]
Logs right after suspend

Attaching the logs from the moment of waking up from suspend. I don't see anything suspicious at all, but dunno.

I suspect that my particular problems may be partly due to lightdm, but I could not make gdm work for me (and it pulls in half of gnome btw).
Comment 21 Dmitry Tantsur 2016-06-01 08:52:58 EDT
Seems like I've fixed the majority of my problems and here's how:
I've tried all the workarounds people mention: switched to kernel 4.6.0, added intel_pstate=no_hwp i915.enable_rc6=0 to kernel arguments, all in vein. After trying to switch to gdm my system got to an unusable state, cause it was just looping trying to start on boot. Full stop.

When I started playing with kernel arguments in grub, I've noticed an interesting thing. I had a "nomodeset" argument there, probably hanging there since I did an installation in a low graphics mode. I've removed it and also rhgb (which I didn't not recognize at all). I've removed both and... a miracle! Both suspend and external monitors just work for me now!
Comment 22 gingerling 2016-06-10 17:59:46 EDT
seems better :)
Comment 23 Rigin Oommen 2016-07-15 01:28:51 EDT
I also faces the same issue
Comment 24 Fedora End Of Life 2016-11-24 11:01:44 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. 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 '23'.

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 23 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 25 Rigin Oommen 2016-11-25 02:25:15 EST
This issue still exists with the fedora 25
Comment 26 Vipin John Wilson 2016-12-02 10:46:07 EST
I am facing this issue with Fedora 25 stable Cinnamon
On new kernel version:
4.8.10-300.fc25

But no issue with the kernel 4.8.6-300.fc25 that comes along with the installation media from the fedora website.

Error on Log upon system freezes:
==================================================
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
Dec  3 01:29:23 fedora25 kernel: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
==================================================

My VGA details:
==================================================
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 510 (rev 06) (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. Device 8694
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 123
	Region 0: Memory at f6000000 (64-bit, non-prefetchable) [size=16M]
	Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at f000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [40] Vendor Specific Information: Len=0c <?>
	Capabilities: [70] Express (v2) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0
			ExtTag- RBE+
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
	Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0200c  Data: 41a1
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [100 v1] Process Address Space ID (PASID)
		PASIDCap: Exec+ Priv-, Max PASID Width: 14
		PASIDCtl: Enable- Exec- Priv-
	Capabilities: [200 v1] Address Translation Service (ATS)
		ATSCap:	Invalidate Queue Depth: 00
		ATSCtl:	Enable-, Smallest Translation Unit: 00
	Capabilities: [300 v1] Page Request Interface (PRI)
		PRICtl: Enable- Reset-
		PRISta: RF- UPRGI- Stopped-
		Page Request Capacity: 00008000, Page Request Allocation: 00000000
	Kernel driver in use: i915
	Kernel modules: i915
==================================================

How to resolve this?.
Comment 27 Fedora End Of Life 2016-12-20 14:23:26 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 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.
Comment 28 Richard J. Turner 2017-01-19 04:05:17 EST
According to Comment 25 it looks like this shouldn't have been closed EOL....

I'm unsure whether it's the same issue I have. Since upgrading to F25 I can no longer undock my HP EliteBook 820 (that has two external displays plugged-into the dock) without freezing the machine; I'm forced to reboot to recover.

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