Bug 62251

Summary: [ILK pch edp] intel_wait_for_pipe_off timeout
Product: Drivers Reporter: Adam Williamson (adamw)
Component: Video(DRI - Intel)Assignee: intel-gfx-bugs (intel-gfx-bugs)
Status: RESOLVED CODE_FIX    
Severity: normal CC: daniel, intel-gfx-bugs, johnjohn.tedro, rik.theys, tmn505
Priority: P3    
Hardware: All   
OS: Linux   
Kernel Version: 3.10.12 Subsystem:
Regression: No Bisected commit-id:
Attachments: the oldest instance of the tb I have (in abrt format)
the newest instance of the tb I have (in abrt format)
dmesg with the bug
dmesg on Fedora 20's 3.14.2 kernel
patch rediffed for 3.14
dmesg with the patch applied on 3.14.4
dmesg-3.6 without traceback
dmesg-3.7-rc1 traceback appeared
dmesg-3.18-rc2 current state of drm driver

Description Adam Williamson 2013-09-27 19:05:59 UTC
Created attachment 109831 [details]
the oldest instance of the tb I have (in abrt format)

I'm running Fedora 18 on a 2010 model Sony Vaio Z, model VPCZ112GD, graphics adapter is a:

00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02)

[    58.460] (--) intel(0): Integrated Graphics Chipset: Intel(R) Arrandale

The system also has an NVIDIA adapter - it slightly predates Optimus, it uses some kind of Sony-proprietary Optimus precursor, I think, but I have it firmware hacked to enable only the Intel adapter. The NVIDIA one does not show up at all in lspci or X log, so I don't think it's interfering.

Ever since kernel 3.8.9-200.fc18.x86_64 , I've been consistently getting a traceback like this once or twice per boot:

WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 intel_wait_for_pipe_off+0xea/0x1b0 [i915]()
Hardware name: VPCZ112GD
pipe_off wait timed out

I'll attach the oldest and newest ones I have, for reference. They look pretty similar, looks like only line numbers change, really. This has persisted all the way up to the current F18 kernel, 3.10.12-100.fc18.x86_64 . I am about to bump the system to F20, so I'll be able to see if it's still happening with 3.11 and 3.12 soon.

Other reports of this often seem related to external displays, but I have no external display hooked up to the system at any point. I'm only using the internal display. By the timing, I think the traces occur during system boot and possibly shutdown.
Comment 1 Adam Williamson 2013-09-27 19:07:36 UTC
Created attachment 109841 [details]
the newest instance of the tb I have (in abrt format)
Comment 2 Daniel Vetter 2013-09-27 19:51:46 UTC
Please boot with drm.debug=0xe, reproduce the issue and attach the complete dmesg (on the most recent kernel you have for better debug output).
Comment 3 Adam Williamson 2013-10-01 00:19:20 UTC
Created attachment 110081 [details]
dmesg with the bug

Here's dmesg from a fairly fresh session, I see the kernel trace in the logs during this session so it should be fine. Kernel is 3.12.0-0.rc2.git4.2.fc21.x86_64 .

I'm now in a situation where I have an external monitor connected to the laptop most of the time. It seems like when I suspend and resume, it changes the display configuration system for some reason, from span mode to clone mode.
Comment 4 Daniel Vetter 2013-10-01 12:58:39 UTC
It's exactly like the other DP wait_for_pipe_off bugs insofar that you have an eDP panel connected to the pch. That's physically the same routing as is used for external DP screens. Laptops eDP panels usually are connected to the cpu die directly and also don't seem to suffer from this issue. We don't seem to have a dupe yet here on kernel bz, but there's one on the freedesktop bugzilla at:

https://bugs.freedesktop.org/show_bug.cgi?id=54687
Comment 5 Adam Williamson 2013-10-01 13:03:59 UTC
Well, it wouldn't be a Sony if they wired it up according to the boring, _normal_ way of doing things ;)
Comment 6 Adam Williamson 2014-04-28 20:51:07 UTC
This is still happening with kernel 3.14.0 (latest to hit Fedora 20).
Comment 7 rik.theys 2014-05-02 13:47:28 UTC
Created attachment 134721 [details]
dmesg on Fedora 20's 3.14.2 kernel

Hi,

In attach the dmesg output with drm.debug=0xe on the kernel command line. This is on a Dell Optiplex 990 with intel graphics and a Dell 30" monitor.

I can reproduce this easily by simply booting the kernel with the monitor attached. There are no other GPU's in this desktop system.

Let me know if there's any more info you need.

Regards,

Rik
Comment 8 Daniel Vetter 2014-05-22 20:27:24 UTC
Please test this patch here, should apply to any recent-ish upstream:

http://patchwork.freedesktop.org/patch/24864/
Comment 9 Adam Williamson 2014-05-22 21:01:07 UTC
doesn't apply cleanly on current Fedora 20 kernel (approx. 3.14) or Rawhide kernel (approx. 3.15rc6). just as a note, I can probably rediff it (I hope).
Comment 10 Adam Williamson 2014-05-23 01:06:21 UTC
Welp, I just built a kernel with the patch rediffed to 3.14, booted it, and it looks like it fixes the issue for me.
Comment 11 rik.theys 2014-05-23 11:34:34 UTC
(In reply to Adam Williamson from comment #10)
> Welp, I just built a kernel with the patch rediffed to 3.14, booted it, and
> it looks like it fixes the issue for me.

Hi Adam,

Can you attach your rediffed patch? I would like to check if it fixes it for me.

Regards,

Rik
Comment 12 Adam Williamson 2014-05-23 16:03:58 UTC
Created attachment 137271 [details]
patch rediffed for 3.14

Sure, here you go.
Comment 13 rik.theys 2014-05-26 07:11:02 UTC
Created attachment 137361 [details]
dmesg with the patch applied on 3.14.4

Hi,

I applied the patch on Fedora's 3.14.4 kernel and still experience the WARNING. This attachment is a boot with the drm.debug=0xe parameter set.

This is on on a

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

The monitor in use is a Dell U3011.

Regards,

Rik
Comment 14 John-John Tedro 2014-08-05 11:44:08 UTC
I can reproduce this.

The screen goes blank and does not recover.
Only happens after I upgraded systemd, I can switch to sysvinit (init=/sbin/init) and I get as far as a working X session.

I'm using the same monitor model as Rik.

kernel: 3.14.14 (gentoo-sources)
gpu: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09)
monitor: Dell U3011
systemd version: 215-r3

Snippet from journalctl;

aug 05 11:42:27 localhost kernel: ------------[ cut here ]------------
aug 05 11:42:27 localhost kernel: WARNING: CPU: 0 PID: 3619 at drivers/gpu/drm/i915/intel_display.c:857 intel_wait_for_pipe_off+0x170/0x179 [i915]()
aug 05 11:42:27 localhost kernel: pipe_off wait timed out
aug 05 11:42:27 localhost kernel: Modules linked in: x86_pkg_temp_thermal ppdev coretemp dcdbas acpi_cpufreq kvm_intel kvm microcode snd_hda_codec_hdmi snd_hda_codec_realtek snd_hd
aug 05 11:42:27 localhost kernel:  ohci_hcd uhci_hcd usb_storage aic94xx libsas lpfc crc_t10dif crct10dif_common qla2xxx megaraid_sas megaraid_mbox megaraid_mm megaraid aacraid sx8
aug 05 11:42:27 localhost kernel:  pata_it821x pata_optidma pata_hpt3x2n pata_hpt3x3 pata_hpt37x pata_hpt366 pata_cmd64x pata_efar pata_rz1000 pata_sil680 pata_radisys pata_pdc2027
aug 05 11:42:27 localhost kernel: CPU: 0 PID: 3619 Comm: systemd-udevd Not tainted 3.14.14-gentoo #1
aug 05 11:42:27 localhost kernel: Hardware name: Dell Inc. OptiPlex 990/06D7TR, BIOS A06 07/25/2011
aug 05 11:42:27 localhost kernel:  0000000000000009 ffff88041390f208 ffffffff814c7363 0000000000000000
aug 05 11:42:27 localhost kernel:  ffff88041390f258 ffff88041390f248 ffffffff810375db ffff88041390f288
aug 05 11:42:27 localhost kernel:  ffffffffa0a27ee7 ffff880415650000 0000000000070008 00000000ffff90ac
aug 05 11:42:27 localhost kernel: Call Trace:
aug 05 11:42:27 localhost kernel:  [<ffffffff814c7363>] dump_stack+0x46/0x58
aug 05 11:42:27 localhost kernel:  [<ffffffff810375db>] warn_slowpath_common+0x77/0x91
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a27ee7>] ? intel_wait_for_pipe_off+0x170/0x179 [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffff81037689>] warn_slowpath_fmt+0x41/0x43
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a5c3dd>] ? gen6_read32+0x77/0x83 [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a27ee7>] intel_wait_for_pipe_off+0x170/0x179 [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a27f84>] intel_disable_pipe+0x94/0x9d [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a28f18>] ironlake_crtc_disable+0xe0/0x821 [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a25bc4>] ? intel_dump_pipe_config.isra.29+0x359/0x360 [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a2f4e9>] __intel_set_mode+0xd60/0x115c [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a31545>] intel_set_mode+0x11/0x2a [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a31c57>] intel_crtc_set_config+0x618/0x7e8 [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffffa098109e>] drm_mode_set_config_internal+0x4b/0xbb [drm]
aug 05 11:42:27 localhost kernel:  [<ffffffffa09e8965>] drm_fb_helper_set_par+0x59/0xa2 [drm_kms_helper]
aug 05 11:42:27 localhost kernel:  [<ffffffff81389bfe>] fbcon_init+0x35a/0x45b
aug 05 11:42:27 localhost kernel:  [<ffffffff8136cc00>] visual_init+0xb7/0x10d
aug 05 11:42:27 localhost kernel:  [<ffffffff8136e64c>] do_bind_con_driver+0x1af/0x2d6
aug 05 11:42:27 localhost kernel:  [<ffffffff8136e8af>] do_take_over_console+0x13c/0x16c
aug 05 11:42:27 localhost kernel:  [<ffffffff81388f00>] do_fbcon_takeover+0x58/0xa4
aug 05 11:42:27 localhost kernel:  [<ffffffff8138bf4f>] fbcon_event_notify+0x3f8/0x727
aug 05 11:42:27 localhost kernel:  [<ffffffff81138450>] ? __kernfs_create_file+0x93/0xbb
aug 05 11:42:27 localhost kernel:  [<ffffffff810515cc>] notifier_call_chain+0x32/0x5c
aug 05 11:42:27 localhost kernel:  [<ffffffff810516ff>] __blocking_notifier_call_chain+0x41/0x5a
aug 05 11:42:27 localhost kernel:  [<ffffffff81051727>] blocking_notifier_call_chain+0xf/0x11
aug 05 11:42:27 localhost kernel:  [<ffffffff813818ca>] fb_notifier_call_chain+0x16/0x18
aug 05 11:42:27 localhost kernel:  [<ffffffff813833fd>] register_framebuffer+0x242/0x2a2
aug 05 11:42:27 localhost kernel:  [<ffffffffa09e8849>] drm_fb_helper_initial_config+0x38e/0x451 [drm_kms_helper]
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a5cf72>] ? gen6_write32+0x75/0x84 [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a5cf72>] ? gen6_write32+0x75/0x84 [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a62870>] intel_fbdev_initial_config+0x1c/0x1e [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a076d1>] i915_driver_load+0xaa8/0xd2b [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffff813c471b>] ? device_add+0x513/0x525
aug 05 11:42:27 localhost kernel:  [<ffffffffa097b93f>] drm_dev_register+0xce/0x145 [drm]
aug 05 11:42:27 localhost kernel:  [<ffffffffa097dbef>] drm_get_pci_dev+0x10d/0x1d0 [drm]
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a045bd>] i915_pci_probe+0x40/0x49 [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffff8134d21d>] pci_device_probe+0x73/0xd3
aug 05 11:42:27 localhost kernel:  [<ffffffff813cf4c1>] ? pm_runtime_barrier+0x55/0x84
aug 05 11:42:27 localhost kernel:  [<ffffffff813c6a27>] driver_probe_device+0xa1/0x1e0
aug 05 11:42:27 localhost kernel:  [<ffffffff813c6b66>] ? driver_probe_device+0x1e0/0x1e0
aug 05 11:42:27 localhost kernel:  [<ffffffff813c6bc0>] __driver_attach+0x5a/0x7d
aug 05 11:42:27 localhost kernel:  [<ffffffff813c51a5>] bus_for_each_dev+0x57/0x89
aug 05 11:42:27 localhost kernel:  [<ffffffff813c65d0>] driver_attach+0x19/0x1b
aug 05 11:42:27 localhost kernel:  [<ffffffff813c6232>] bus_add_driver+0xe9/0x1ce
aug 05 11:42:27 localhost kernel:  [<ffffffff813c717d>] driver_register+0x87/0xbe
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a8f000>] ? 0xffffffffa0a8efff
aug 05 11:42:27 localhost kernel:  [<ffffffff8134d343>] __pci_register_driver+0x46/0x48
aug 05 11:42:27 localhost kernel:  [<ffffffffa097dd1c>] drm_pci_init+0x6a/0xee [drm]
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a8f000>] ? 0xffffffffa0a8efff
aug 05 11:42:27 localhost kernel:  [<ffffffffa0a8f06a>] i915_init+0x6a/0x6c [i915]
aug 05 11:42:27 localhost kernel:  [<ffffffff810002a3>] do_one_initcall+0x7f/0x108
aug 05 11:42:27 localhost kernel:  [<ffffffff810cdcd2>] ? __vunmap+0x91/0xb8
aug 05 11:42:27 localhost kernel:  [<ffffffff81085067>] load_module+0x1a1f/0x1cfa
aug 05 11:42:27 localhost kernel:  [<ffffffff81082786>] ? mod_kobject_put+0x45/0x45
aug 05 11:42:27 localhost kernel:  [<ffffffff810c89c5>] ? do_mmap_pgoff+0x2cb/0x33f
aug 05 11:42:27 localhost kernel:  [<ffffffff81085433>] SyS_finit_module+0x56/0x6c
aug 05 11:42:27 localhost kernel:  [<ffffffff814cc8a2>] system_call_fastpath+0x16/0x1b
aug 05 11:42:27 localhost kernel: ---[ end trace 64c03ae608251819 ]---
Comment 15 Adam Williamson 2014-09-19 16:07:13 UTC
John-John Tedro: FWIW I'd say it's somewhat unlikely this bug is actually the cause of your boot troubles - as it's a kernel issue it would be odd for it to cause a system to fail to boot with systemd but not sysv. I suspect it's more that you're seeing some other issue with systemd boot on your distro/configuration, and you just happen to see this oops on the console when it happens. This oops at least for me is just an annoyance, it doesn't actually cause any problems with use of the system.
Comment 16 John-John Tedro 2014-09-29 08:59:45 UTC
(In reply to Adam Williamson from comment #15)
> John-John Tedro: FWIW I'd say it's somewhat unlikely this bug is actually
> the cause of your boot troubles - as it's a kernel issue it would be odd for
> it to cause a system to fail to boot with systemd but not sysv. I suspect
> it's more that you're seeing some other issue with systemd boot on your
> distro/configuration, and you just happen to see this oops on the console
> when it happens. This oops at least for me is just an annoyance, it doesn't
> actually cause any problems with use of the system.

Certainly, I do believe the system is still 'usable' but it's preventing the only screen I've got connected to it from working, which makes it difficult to interact with.

With regards to systemd; I believe you are right. But I've had a hard time nailing down what is provoking it since KMS works when I run without it. For the record; I miss systemd.
Comment 17 Adam Williamson 2014-09-29 19:22:51 UTC
To be clear, when I say "doesn't actually cause any problems with use of the system", what I mean is that graphics work perfectly for me. I see the kernel WARNING, but there is no observable effect on actual use of the system. Graphics work, acceleration works, nothing at all visible to the user stops working. In my case.
Comment 18 Tomasz Maciej Nowak 2014-10-29 17:00:28 UTC
This bug seems to be somewhat fixed since kernel 3.18-rc1. The only error still appearing is (on 3.18-rc2):

[    1.012776] [drm:intel_enable_shared_dpll] enable PCH DPLL A (active 0, on? 0) for crtc 8
[    1.012776] [drm:intel_enable_shared_dpll] enabling PCH DPLL A
[    1.014159] [drm:edp_panel_vdd_on] Turning eDP port D VDD on
[    1.014161] [drm:wait_panel_power_cycle] Wait for panel power cycle
[    1.014306] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
[    1.481758] [drm:wait_panel_status] mask b800000f value 00000000 status 48000001 control abcd0000
[    1.508446] [drm:wait_panel_status] Wait complete

and it is observed once during boot. I didn't see it even after X session restarts. The hardware is Sony VAIO, model VPCZ13C5E.
Before kernel 3.18-rc1, tracebacks appeared on every restart of X server and sometimes during X server sessions freezing the screeen. I've been using this computer since kernel 3.14. I went back with kernel versions and the tracebacks first appeared in 3.7-rc1. I think the bug https://bugzilla.kernel.org/show_bug.cgi?id=52061 is related to this bug.
Comment 19 Tomasz Maciej Nowak 2014-10-29 17:02:29 UTC
Created attachment 155791 [details]
dmesg-3.6 without traceback
Comment 20 Tomasz Maciej Nowak 2014-10-29 17:04:03 UTC
Comment on attachment 155791 [details]
dmesg-3.6 without traceback

Last known kernel version without tracebacks
Comment 21 Tomasz Maciej Nowak 2014-10-29 17:05:36 UTC
Created attachment 155801 [details]
dmesg-3.7-rc1 traceback appeared

First known kernel version with tracebacks
Comment 22 Tomasz Maciej Nowak 2014-10-29 17:08:50 UTC
Created attachment 155821 [details]
dmesg-3.18-rc2 current state of drm driver

Current state of drm driver.
Comment 23 Jani Nikula 2015-01-28 15:17:56 UTC
(In reply to Tomasz Maciej Nowak from comment #22)
> Created attachment 155821 [details]
> dmesg-3.18-rc2 current state of drm driver
> 
> Current state of drm driver.

I don't see a backtrace there. Is there still an issue with recent kernels?
Comment 24 Tomasz Maciej Nowak 2015-01-30 17:20:56 UTC
(In reply to Jani Nikula from comment #23)
> (In reply to Tomasz Maciej Nowak from comment #22)
> > Created attachment 155821 [details]
> > dmesg-3.18-rc2 current state of drm driver
> > 
> > Current state of drm driver.
> 
> I don't see a backtrace there. Is there still an issue with recent kernels?

Yes since 3.18 backtraces are gone, except the error in comment #18. Please wait about a week with changing the status of the bug, then I'll have access to external displays and can/can't confirm that it's fixed.
Comment 25 John-John Tedro 2015-02-02 06:35:48 UTC
I'm running gentoo-sources 3.18.3 which is based of 3.18.1 with the following patches:
http://dev.gentoo.org/~mpagano/genpatches/patches-3.18-3.htm

I'm still getting the WARNING, however it seems to recover faster than it previously did.

feb 02 07:24:17 localhost kernel: fbcon: inteldrmfb (fb0) is primary device
feb 02 07:24:17 localhost kernel: ------------[ cut here ]------------
feb 02 07:24:17 localhost kernel: WARNING: CPU: 2 PID: 1380 at drivers/gpu/drm/i915/intel_display.c:994 intel_disable_pipe+0x21d/0x229 [i915]()
feb 02 07:24:17 localhost kernel: pipe_off wait timed out
feb 02 07:24:17 localhost kernel: Modules linked in: snd_hda_codec_realtek snd_hda_codec_generic ppdev x86_pkg_temp_thermal coretemp dcdbas kvm_intel kvm micr
feb 02 07:24:17 localhost kernel:  ohci_pci ohci_hcd uhci_hcd usb_storage aic94xx libsas lpfc crc_t10dif crct10dif_common qla2xxx megaraid_sas megaraid_mbox m
feb 02 07:24:17 localhost kernel:  pata_hpt3x2n pata_hpt3x3 pata_hpt37x pata_hpt366 pata_cmd64x pata_efar pata_rz1000 pata_sil680 pata_radisys pata_pdc2027x p
feb 02 07:24:17 localhost kernel: CPU: 2 PID: 1380 Comm: kworker/u32:5 Not tainted 3.18.3-gentoo #1
feb 02 07:24:17 localhost kernel: Hardware name: Dell Inc. OptiPlex 990/06D7TR, BIOS A06 07/25/2011
feb 02 07:24:17 localhost kernel: Workqueue: events_unbound async_run_entry_fn
feb 02 07:24:17 localhost kernel:  0000000000000009 ffff88041488b698 ffffffff814d2295 0000000000004646
feb 02 07:24:17 localhost kernel:  ffff88041488b6e8 ffff88041488b6d8 ffffffff81037697 ffff88041488b6f8
feb 02 07:24:17 localhost kernel:  ffffffffa0a4de7c ffff880418a50000 0000000000070008 00000000ffff8c7e
feb 02 07:24:17 localhost kernel: Call Trace:
feb 02 07:24:17 localhost kernel:  [<ffffffff814d2295>] dump_stack+0x46/0x58
feb 02 07:24:17 localhost kernel:  [<ffffffff81037697>] warn_slowpath_common+0x77/0x91
feb 02 07:24:17 localhost kernel:  [<ffffffffa0a4de7c>] ? intel_disable_pipe+0x21d/0x229 [i915]
feb 02 07:24:17 localhost kernel:  [<ffffffff810376f2>] warn_slowpath_fmt+0x41/0x43
feb 02 07:24:17 localhost kernel:  [<ffffffffa0a4de7c>] intel_disable_pipe+0x21d/0x229 [i915]
feb 02 07:24:17 localhost kernel:  [<ffffffffa0a582f6>] ironlake_crtc_disable+0x8f/0x702 [i915]
feb 02 07:24:17 localhost kernel:  [<ffffffffa0a4ac15>] ? intel_dump_pipe_config+0x1cd/0x35d [i915]
feb 02 07:24:17 localhost kernel:  [<ffffffffa0a53166>] __intel_set_mode+0x8a8/0x1233 [i915]
feb 02 07:24:17 localhost kernel:  [<ffffffffa0a59e35>] intel_set_mode+0x11/0x2a [i915]
feb 02 07:24:17 localhost kernel:  [<ffffffffa0a5acce>] intel_crtc_set_config+0x9a0/0xa86 [i915]
feb 02 07:24:17 localhost kernel:  [<ffffffffa09af5ec>] drm_mode_set_config_internal+0x51/0xdd [drm]
feb 02 07:24:17 localhost kernel:  [<ffffffffa09fae16>] restore_fbdev_mode+0xb5/0xce [drm_kms_helper]
feb 02 07:24:17 localhost kernel:  [<ffffffffa09fae51>] drm_fb_helper_restore_fbdev_mode_unlocked+0x22/0x37 [drm_kms_helper]
feb 02 07:24:17 localhost kernel:  [<ffffffffa09fc359>] drm_fb_helper_set_par+0x3f/0x5f [drm_kms_helper]
feb 02 07:24:17 localhost kernel:  [<ffffffffa0a63c7f>] intel_fbdev_set_par+0x15/0x58 [i915]
feb 02 07:24:17 localhost kernel:  [<ffffffff8138b149>] fbcon_init+0x35c/0x45d
feb 02 07:24:17 localhost kernel:  [<ffffffff8137152f>] visual_init+0xb7/0x10d
feb 02 07:24:17 localhost kernel:  [<ffffffff81372d4f>] do_bind_con_driver+0x1ab/0x2cd
feb 02 07:24:17 localhost kernel:  [<ffffffff81373330>] do_take_over_console+0x132/0x162
feb 02 07:24:17 localhost kernel:  [<ffffffff8138a31e>] do_fbcon_takeover+0x56/0x9f
feb 02 07:24:17 localhost kernel:  [<ffffffff8138d382>] fbcon_event_notify+0x452/0x780
feb 02 07:24:17 localhost kernel:  [<ffffffff8104c246>] notifier_call_chain+0x39/0x5c
feb 02 07:24:17 localhost kernel:  [<ffffffff8104c47e>] __blocking_notifier_call_chain+0x41/0x5a
feb 02 07:24:17 localhost kernel:  [<ffffffff8104c4a6>] blocking_notifier_call_chain+0xf/0x11
feb 02 07:24:17 localhost kernel:  [<ffffffff81390e48>] fb_notifier_call_chain+0x16/0x18
feb 02 07:24:17 localhost kernel:  [<ffffffff8139299f>] register_framebuffer+0x270/0x2a8
feb 02 07:24:17 localhost kernel:  [<ffffffffa09fbf4c>] drm_fb_helper_initial_config+0x258/0x312 [drm_kms_helper]
feb 02 07:24:17 localhost kernel:  [<ffffffffa0a6461f>] intel_fbdev_initial_config+0x16/0x18 [i915]
feb 02 07:24:17 localhost kernel:  [<ffffffff8104d34f>] async_run_entry_fn+0x33/0xca
feb 02 07:24:17 localhost kernel:  [<ffffffff810478ca>] process_one_work+0x1a0/0x2ae
feb 02 07:24:17 localhost kernel:  [<ffffffff8104825a>] worker_thread+0x281/0x373
feb 02 07:24:17 localhost kernel:  [<ffffffff81047fd9>] ? rescuer_thread+0x217/0x217
feb 02 07:24:17 localhost kernel:  [<ffffffff8104b736>] kthread+0xcd/0xd5
feb 02 07:24:17 localhost kernel:  [<ffffffff8104b669>] ? kthread_create_on_node+0x16c/0x16c
feb 02 07:24:17 localhost kernel:  [<ffffffff814d726c>] ret_from_fork+0x7c/0xb0
feb 02 07:24:17 localhost kernel:  [<ffffffff8104b669>] ? kthread_create_on_node+0x16c/0x16c
feb 02 07:24:17 localhost kernel: ---[ end trace 9888c63f5bc6b1b4 ]---
feb 02 07:24:17 localhost kernel: [drm:ironlake_disable_pch_transcoder] *ERROR* failed to disable transcoder A
feb 02 07:24:17 localhost kernel: [drm:cpt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo underrun on pch transcoder A
feb 02 07:24:17 localhost kernel: [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun
feb 02 07:24:17 localhost kernel: Console: switching to colour frame buffer device 320x100
feb 02 07:24:17 localhost kernel: i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
feb 02 07:24:17 localhost kernel: i915 0000:00:02.0: registered panic notifier
Comment 26 Tomasz Maciej Nowak 2015-02-10 20:57:29 UTC
For summary, after version 3.18 kernel doesn't trip any more (no segfaults). The error mentioned in comment #18 persist, but it doesn't create any inconveniences in daily use. The external monitor connection through HDMI is detected but there's no output on screen. This situation is much better than on Win7 where the driver doesn't even detect any connection. As I don't use external monitor, for me the issue is fixed. Thanks.
Comment 27 Jani Nikula 2015-02-11 09:18:40 UTC
(In reply to Tomasz Maciej Nowak from comment #26)
> For summary, after version 3.18 kernel doesn't trip any more (no segfaults).
> The error mentioned in comment #18 persist, but it doesn't create any
> inconveniences in daily use. The external monitor connection through HDMI is
> detected but there's no output on screen. This situation is much better than
> on Win7 where the driver doesn't even detect any connection. As I don't use
> external monitor, for me the issue is fixed. Thanks.

Thanks for the follow-up. What about others? Can we close the bug?
Comment 28 rik.theys 2015-02-11 09:24:01 UTC
Hi,

I'm running Fedora's 3.18.3-201.fc21.x86_64 and still get the following messages on boot:

Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel: ------------[ cut here ]------------
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel: WARNING: CPU: 3 PID: 128 at drivers/gpu/drm/i915/intel_display.c:994 intel_disable_pipe+0x2ae/
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel: pipe_off wait timed out
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel: Modules linked in: raid1 i915 i2c_algo_bit drm_kms_helper drm e1000e ptp pps_core video
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel: CPU: 3 PID: 128 Comm: kworker/u32:5 Not tainted 3.18.3-201.fc21.x86_64 #1
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel: Hardware name: Dell Inc. OptiPlex 990/06D7TR, BIOS A18 09/24/2013
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel: Workqueue: events_unbound async_run_entry_fn
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  0000000000000000 0000000062012830 ffff88041428f688 ffffffff8175da66
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  0000000000000000 ffff88041428f6e0 ffff88041428f6c8 ffffffff81099181
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  0000000000000000 ffff880412b30000 0000000000070008 00000000fffb71d6
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel: Call Trace:
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff8175da66>] dump_stack+0x46/0x58
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff81099181>] warn_slowpath_common+0x81/0xa0
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff810991f5>] warn_slowpath_fmt+0x55/0x70
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffffa0137f8e>] intel_disable_pipe+0x2ae/0x2c0 [i915]
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffffa0143bd5>] ironlake_crtc_disable+0x95/0x7b0 [i915]
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffffa01354bc>] ? intel_dump_pipe_config.isra.51+0x3c/0x3c0 [i915]
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffffa013de41>] __intel_set_mode+0x7f1/0x16f0 [i915]
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffffa0146c36>] intel_set_mode+0x16/0x30 [i915]
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffffa0147dda>] intel_crtc_set_config+0xa9a/0xea0 [i915]
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff8138ffd6>] ? get_from_free_list+0x46/0x60
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffffa0073e30>] drm_mode_set_config_internal+0x60/0xf0 [drm]
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffffa00cf553>] restore_fbdev_mode+0xd3/0x100 [drm_kms_helper]
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffffa00d1099>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffffa00d1112>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffffa0152efa>] intel_fbdev_set_par+0x1a/0x60 [i915]
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff813fbe88>] fbcon_init+0x578/0x600
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff8147a0bc>] visual_init+0xbc/0x120
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff8147c88e>] do_bind_con_driver+0x17e/0x3b0
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff8147d064>] do_take_over_console+0xb4/0x1b0
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff813f6c63>] do_fbcon_takeover+0x63/0xd0
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff813fc9ad>] fbcon_event_notify+0x6cd/0x7d0
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff810b8fdd>] notifier_call_chain+0x4d/0x80
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff810b935b>] __blocking_notifier_call_chain+0x4b/0x70
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff810b9396>] blocking_notifier_call_chain+0x16/0x20
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff8140291b>] fb_notifier_call_chain+0x1b/0x20
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff81404cf4>] register_framebuffer+0x214/0x360
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffffa00d13af>] drm_fb_helper_initial_config+0x26f/0x3d0 [drm_kms_helper]
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff81012651>] ? __switch_to+0x151/0x5f0
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffffa01541ab>] intel_fbdev_initial_config+0x1b/0x20 [i915]
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff810bab8a>] async_run_entry_fn+0x4a/0x150
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff810b240d>] process_one_work+0x14d/0x400
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff810b2d9b>] worker_thread+0x6b/0x4a0
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff810b2d30>] ? rescuer_thread+0x2a0/0x2a0
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff810b7fea>] kthread+0xea/0x100
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff810b7f00>] ? kthread_create_on_node+0x1b0/0x1b0
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff817646fc>] ret_from_fork+0x7c/0xb0
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel:  [<ffffffff810b7f00>] ? kthread_create_on_node+0x1b0/0x1b0
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel: ---[ end trace 313ba28f59e5b7e9 ]---
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel: [drm:ironlake_disable_pch_transcoder] *ERROR* failed to disable transcoder A
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel: [drm:cpt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo underrun on pch transcoder A
Jan 26 11:00:55 lucifer.esat.kuleuven.be kernel: [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun

Regards,

Rik
Comment 29 Jani Nikula 2015-10-07 10:02:43 UTC
AFAICT the original bug is fixed, closing.

Please file any new bug reports at the freedesktop.org bugzilla [1]. Thank you.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel