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 |
||
Created attachment 109841 [details]
the newest instance of the tb I have (in abrt format)
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). 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.
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 Well, it wouldn't be a Sony if they wired it up according to the boring, _normal_ way of doing things ;) This is still happening with kernel 3.14.0 (latest to hit Fedora 20). 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
Please test this patch here, should apply to any recent-ish upstream: http://patchwork.freedesktop.org/patch/24864/ 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). 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. (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 Created attachment 137271 [details]
patch rediffed for 3.14
Sure, here you go.
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
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 ]--- 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. (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. 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. 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. Created attachment 155791 [details]
dmesg-3.6 without traceback
Comment on attachment 155791 [details]
dmesg-3.6 without traceback
Last known kernel version without tracebacks
Created attachment 155801 [details]
dmesg-3.7-rc1 traceback appeared
First known kernel version with tracebacks
Created attachment 155821 [details]
dmesg-3.18-rc2 current state of drm driver
Current state of drm driver.
(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? (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. 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 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. (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? 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 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 |
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.