Re: [Intel-gfx] [PATCH] Avoid i915 flip unpin/HPD event handler deadlock.
On Fri, Aug 30, 2013 at 06:30:55PM -0700, Stuart Abercrombie wrote:
> Both of these were taking the mode_config mutex but executed from the
> same work queue. If intel_crtc_page_flip happened to flush a work queue
> containing an HPD event handler work item, deadlock resulted, since the
> mutex required by the HPD handler was taken before the flush. Instead
> use a separate work queue for the flip unpin work.
>
> Signed-off-by: sabercrom...@chromium.org
> Reviewed-by: marc...@chromium.org
It would be possible to rearrange the flip to drop the lock around the
flush (which is a regression from the kernel/workqueue.c refacting...).
However, this looks much simpler. In the long run being strict on
calling flush_workqueue() unlocked is likely to be safer though.
Reviewed-by; Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_dma.c | 21 -
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_display.c | 4 ++--
> 3 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 4f129bb..9215360 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1558,6 +1558,22 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> goto out_mtrrfree;
> }
>
> + /* intel_crtc_page_flip runs with the mode_config mutex having been
> + * taken in the DRM layer. It synchronously waits for pending unpin
> + * work items while holding this mutex. Therefore this queue cannot
> + * contain work items that take this mutex, such as HPD event
> + * handling, or we deadlock. There is also no reason for flipping to
> + * wait on such events. Therefore put flip unpinning in its own
> + * work queue.
> + */
> + dev_priv->flip_unpin_wq = alloc_ordered_workqueue("i915", 0);
> + if (dev_priv->flip_unpin_wq == NULL) {
> + DRM_ERROR("Failed to create flip unpin workqueue.\n");
> + destroy_workqueue(dev_priv->wq);
> + ret = -ENOMEM;
> + goto out_mtrrfree;
> + }
> +
> /* This must be called before any calls to HAS_PCH_* */
> intel_detect_pch(dev);
>
> @@ -1628,6 +1644,7 @@ out_gem_unload:
> intel_teardown_gmbus(dev);
> intel_teardown_mchbar(dev);
> destroy_workqueue(dev_priv->wq);
> + destroy_workqueue(dev_priv->flip_unpin_wq);
To be consistent, flip_wq then wq. In case we get ordering issues later.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] BUG: i830 flickering for horizontal panning
Dear intel-gfx developers, panning on i830 based graphics seem to be working only half-ways. Vertical panning works fine, but horizontal panning flickers at about 60Hz frequency at specific pixel positions. The problem persists throughout kernel 3.10.9, and potentially later. How to reproduce: Enable panning, e.g. by xrandr --fb 2048x1536 xrandr --output DVI1 --panning 2048x1536 then scroll with the mouse slowly to the right. The affected hardware is *at least* this one: 00:02.0 VGA compatible controller: Intel Corporation 82830M/MG Integrated Graphics Controller (rev 04) as it is found in the Fujitsu-Siemens S2475 lifebook. The IBM Thinkpad R31 is also affected, it also contains a 830GM chipset graphics, but a different DVO. There is no specific output when flickering. The screen contents seems to be flickering between a dark frame and a frame that is half the way shifted correctly (left) and half the way a copy of the leftmost pixels of the screen on the right hand side. The kernel uses the i915 driver for this hardware. I currently don't see where precisely panning in the i915 sources is handled, thus I cannot really say what is necessary to support this correctly. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] BUG: Kernel warning of 830M chipset graphics
Dear intel-gfx developers, when booting up the 3.10.9 kernel on a Fujitsu-Siemens S4575, I get the following warnings from the linux kernel (see below). The hardware is a 00:02.0 VGA compatible controller: Intel Corporation 82830M/MG Integrated Graphics Controller (rev 04) with the dreadful ns2501 DVO. If you remember, this DVO has a special "condition" that it does not react on the i2c bus if the graphic pipelines are not configured correctly. Probably this is related to the warning below. Other than the warning, the system works correctly (minus panning, minus suspend). [6.938862] Modules linked in: pcmcia(+) snd_seq i915(+) firewire_ohci firewire_core snd_seq_device snd_timer crc_itu_t lpc_ich i2c_algo_bit yenta_socket mfd_core intel_agp pcmcia_rsrc snd psmouse sg 8139too 8139cp serio_raw sr_mod fujitsu_laptop apanel pcspkr mii input_polldev evdev cdrom pcmcia_core uhci_hcd intel_gtt drm_kms_helper drm soundcore usbcore rng_core i2c_i801 agpgart led_class video usb_common i2c_core ac button [6.938930] CPU: 0 PID: 218 Comm: modprobe Tainted: GW 3.10.9 #6 [6.938937] Hardware name: FUJITSU SIEMENS LIFEBOOK S Series/FJNB159, BIOS Version 1.06 07/02/2002 [6.938944] c12e5228 c102dcca f8628630 f5b5ba28 0f57 f85f08d4 f85f08d4 f50eac00 [6.938961] f5be9a60 f5a4c780 0f57 c102dd83 0009 f5b5ba10 f8628630 f5b5ba28 [6.938978] f85f08d4 f86277a4 0f57 f8628630 f862eb50 0008 f8293d80 c13e5120 [6.938995] Call Trace: [6.939007] [] ? dump_stack+0xa/0x13 [6.939019] [] ? warn_slowpath_common+0x6a/0x90 [6.939085] [] ? intel_modeset_check_state+0x734/0x780 [i915] [6.939149] [] ? intel_modeset_check_state+0x734/0x780 [i915] [6.939162] [] ? warn_slowpath_fmt+0x33/0x40 [6.939226] [] ? intel_modeset_check_state+0x734/0x780 [i915] [6.939241] [] ? check_preempt_wakeup+0x157/0x1e0 [6.939255] [] ? check_preempt_curr+0x6c/0x80 [6.939267] [] ? usleep_range+0x40/0x40 [6.939279] [] ? call_timer_fn.isra.34+0x1c/0x80 [6.939292] [] ? sclhi+0x43/0x60 [i2c_algo_bit] [6.939304] [] ? __udelay+0x1f/0x20 [6.939373] [] ? intel_gpio_post_xfer+0x28/0x40 [i915] [6.939386] [] ? usleep_range+0x40/0x40 [6.939397] [] ? run_timer_softirq+0x124/0x1c0 [6.939409] [] ? __do_softirq+0xee/0x150 [6.939421] [] ? do_IRQ+0x43/0xb0 [6.939432] [] ? common_interrupt+0x2c/0x31 [6.939494] [] ? assert_pipe+0x96/0xf0 [i915] [6.939556] [] ? intel_wait_for_pipe_off+0x110/0x1a0 [i915] [6.939619] [] ? i9xx_crtc_disable+0x177/0x220 [i915] [6.939687] [] ? i830_update_wm+0x1c/0xd0 [i915] [6.939757] [] ? intel_update_watermarks+0x12/0x20 [i915] [6.939821] [] ? intel_modeset_setup_hw_state+0x683/0xa50 [i915] [6.939873] [] ? i915_semaphore_is_enabled+0x30/0x30 [i915] [6.939925] [] ? i915_driver_load+0xbbb/0xe30 [i915] [6.939975] [] ? i915_dma_init+0x2d0/0x2d0 [i915] [6.940007] [] ? drm_get_pci_dev+0x141/0x260 [drm] [6.940050] [] ? driver_probe_device+0x1f0/0x1f0 [6.940064] [] ? pci_device_probe+0x7d/0xc0 [6.940075] [] ? driver_probe_device+0x1f0/0x1f0 [6.940086] [] ? driver_probe_device+0x53/0x1f0 [6.940097] [] ? kobject_add_internal+0x6d/0x1f0 [6.940108] [] ? __driver_attach+0x79/0x80 [6.940119] [] ? bus_for_each_dev+0x38/0x70 [6.940130] [] ? driver_attach+0x16/0x20 [6.940141] [] ? driver_probe_device+0x1f0/0x1f0 [6.940151] [] ? bus_add_driver+0xc9/0x210 [6.940162] [] ? pci_device_remove+0xb0/0xb0 [6.940173] [] ? pci_device_remove+0xb0/0xb0 [6.940184] [] ? pci_match_id+0x90/0x90 [6.940194] [] ? driver_register+0x63/0x160 [6.940208] [] ? 0xf81aafff [6.940218] [] ? do_one_initcall+0xe2/0x140 [6.940230] [] ? __blocking_notifier_call_chain+0x4b/0x70 [6.940244] [] ? load_module+0x19d3/0x2220 [6.940255] [] ? 0xf7ffdfff [6.940270] [] ? vmalloc_sync_all+0xd0/0xd0 [6.940283] [] ? SyS_init_module+0x91/0xd0 [6.940299] [] ? sysenter_do_call+0x12/0x26 [6.940307] ---[ end trace 0e5983c19538fe53 ]--- [6.940313] [ cut here ] [6.940377] WARNING: at drivers/gpu/drm/i915/intel_display.c:3929 intel_modeset_check_state+0x711/0x780 [i915]() [6.940383] encoder->connectors_active not set [6.940388] Modules linked in: pcmcia(+) snd_seq i915(+) firewire_ohci firewire_core snd_seq_device snd_timer crc_itu_t lpc_ich i2c_algo_bit yenta_socket mfd_core intel_agp pcmcia_rsrc snd psmouse sg 8139too 8139cp serio_raw sr_mod fujitsu_laptop apanel pcspkr mii input_polldev evdev cdrom pcmcia_core uhci_hcd intel_gtt drm_kms_helper drm soundcore usbcore rng_core i2c_i801 agpgart led_class video usb_common i2c_core ac button [6.940458] CPU: 0 PID: 218 Comm: modprobe Tainted: GW 3.10.9 #6 [6.940466] Hardware name: FUJITSU SIEMENS LIFEBOOK S Series/FJNB159, BIOS Version 1.06 07/02/2002 [6.940472] c12e5228 c102dc
[Intel-gfx] BUG: resume from standby on 830GM broken
Dear intel-gfx developers, suspend from standby is broken on the Fujitsu-Siemens Lifebook S2474, at least from kernel 3.4 up to 3.10.9. The hardware is a 00:02.0 VGA compatible controller: Intel Corporation 82830M/MG Integrated Graphics Controller (rev 04), i.e. a 830GM. The machine suspends correctly, but resume from RAM does not proceed and the display remains dark. Activating the resume debug mode of the kernel that uses the RTC to store state information confirms that the kernel locks up on the PCI device 00:02.0. The problem might be related to the NS2501 DVO. The problem is here that the ns2501 locks up and does not react on the i2c bus unless the output pipelines are configured correctly. I believe in an early version of the patch I provided to support the ns2501, the enable_dvo() function included a specific hack to force enable the dvo, by calling into a private function of the i915 module. I seem to remember that with this specific hack enabled, resume did work (at least most of the time), so something is not yet quite right when configuring the dvo. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [git pull] drm fixes
Hmm. I just updated my machine to a i7-4770S (kept everything else the same, just switched out motherboards), and now when my display goes to sleep, it seems to never come back. Any known issues with DVI on Haswell (it seems to show up as "HDMI1" as the output, but it's a DVI cable)? I need to get a DP cable anyway (right now I'm driving my 2560x1440 display at 32Hz due to DVI crap) and maybe that will fix things, but this happens even if I don't force that odd mode (so it maxes out at 1920x1200 or whatever). I doubt this is new, but I've only ever run current -git on this machine, so who knows.. The machine ends up being kind of unusable. I guess I can just turn off power save. Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
