mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Krzysztof Mazur <krzysiek@podlesie.net>
To: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org, airlied@linux.ie, daniel.vetter@ffwll.ch
Subject: drm: i915+fb: crtc->lock recursive locking deadlock on VT switch [>= 3.9-rc1 regresion]
Date: Sat, 13 Apr 2013 17:41:46 +0200	[thread overview]
Message-ID: <20130413154146.GA8136@shrek.podlesie.net> (raw)

Hi,

the drm_fb_helper_hotplug_event() locks all crtc->mutex locks by calling
drm_modeset_lock_all() and later calls drm_fb_helper_probe_connector_modes(),
which in case of i915 DRM driver effectively calls
intel_get_load_detect_pipe() that tries to lock crtc->mutex again.
This causes a deadlock, and can be in some cases triggered by VT
switch to framebuffer console on i915.

This bug is introduced in Linux 3.9-rc1 and still exists
in v3.9-rc6-183-gbf81710. Linux 3.8 is ok.

This deadlock is probably introduced by
commit 7b24056be6db7ce907baffdd4cf142ab774ea60c
(drm: don't hold crtc mutexes for connector ->detect callbacks).


Steps to reproduce (the deadlock occurs in almost all cases):
LCD panel connected to LVDS1, 915GM, HP nc6120
1. power on
2. $ startx
3. connect monitor to VGA1
4. $ xrandr --output VGA1 --mode 1600x1200 --right-of LVDS1
5. change VT, ALT + CTRL + F2

Krzysiek

...
[   62.995861] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:13:SVIDEO-1]
[   62.995870] [drm:intel_get_load_detect_pipe], [CONNECTOR:13:SVIDEO-1], [ENCODER:14:TV-14]
[   62.995873] 
[   62.995875] =============================================
[   62.995877] [ INFO: possible recursive locking detected ]
[   62.995881] 3.9.0-rc6-00184-gc875d9b #14 Not tainted
# v3.9-rc6-183-gbf81710 + one unrelated local patch.
[   62.995883] ---------------------------------------------
[   62.995885] X/1759 is trying to acquire lock:
[   62.995903]  (&crtc->mutex){+.+.+.}, at: [<803649e4>] intel_get_load_detect_pipe+0x164/0x3f0
[   62.995905] 
[   62.995905] but task is already holding lock:
[   62.995916]  (&crtc->mutex){+.+.+.}, at: [<8032d1da>] drm_modeset_lock_all+0x3a/0x50
[   62.995918] 
[   62.995918] other info that might help us debug this:
[   62.995920]  Possible unsafe locking scenario:
[   62.995920] 
[   62.995921]        CPU0
[   62.995923]        ----
[   62.995926]   lock(&crtc->mutex);
[   62.995930]   lock(&crtc->mutex);
[   62.995931] 
[   62.995931]  *** DEADLOCK ***
[   62.995931] 
[   62.995933]  May be due to missing lock nesting notation
[   62.995933] 
[   62.995936] 3 locks held by X/1759:
[   62.995948]  #0:  (console_lock){+.+.+.}, at: [<802fe726>] vt_ioctl+0xe26/0x1220
[   62.995958]  #1:  (&dev->mode_config.mutex){+.+.+.}, at: [<8032d1b5>] drm_modeset_lock_all+0x15/0x50
[   62.995968]  #2:  (&crtc->mutex){+.+.+.}, at: [<8032d1da>] drm_modeset_lock_all+0x3a/0x50
[   62.995970] 
[   62.995970] stack backtrace:
[   62.995974] Pid: 1759, comm: X Not tainted 3.9.0-rc6-00184-gc875d9b #14
[   62.995976] Call Trace:
[   62.995985]  [<8016d9f8>] __lock_acquire+0x748/0x19e0
[   62.995991]  [<80160008>] ? ktime_get+0xb8/0xf0
[   62.995998]  [<80155f6e>] ? local_clock+0x4e/0x60
[   62.996005]  [<8012c2c5>] ? log_store+0x2d5/0x3b0
[   62.996011]  [<8014fc83>] ? down_trylock+0x13/0x40
[   62.996017]  [<8016b655>] ? mark_held_locks+0x75/0xe0
[   62.996020]  [<8012d9b9>] ? vprintk_emit+0x159/0x4e0
[   62.996020]  [<8016f189>] lock_acquire+0x79/0x90
[   62.996020]  [<803649e4>] ? intel_get_load_detect_pipe+0x164/0x3f0
[   62.996020]  [<8050acf4>] mutex_lock_nested+0x54/0x310
[   62.996020]  [<803649e4>] ? intel_get_load_detect_pipe+0x164/0x3f0
[   62.996020]  [<803649e4>] ? intel_get_load_detect_pipe+0x164/0x3f0
[   62.996020]  [<80327c7a>] ? drm_ut_debug_printk+0x2a/0x50
[   62.996020]  [<803649e4>] intel_get_load_detect_pipe+0x164/0x3f0
[   62.996020]  [<80108707>] ? native_sched_clock+0x27/0xb0
[   62.996020]  [<80155bcc>] ? sched_clock_local.constprop.2+0x3c/0x170
[   62.996020]  [<8038061d>] intel_tv_detect+0x15d/0x570
[   62.996020]  [<8016b98b>] ? trace_hardirqs_off+0xb/0x10
[   62.996020]  [<80155f6e>] ? local_clock+0x4e/0x60
[   62.996020]  [<8012c2c5>] ? log_store+0x2d5/0x3b0
[   62.996020]  [<8014fc83>] ? down_trylock+0x13/0x40
[   62.996020]  [<8031dbd8>] drm_helper_probe_single_connector_modes+0x278/0x330
[   62.996020]  [<80319fc7>] drm_fb_helper_probe_connector_modes.isra.3+0x37/0x60
[   62.996020]  [<8031bfec>] drm_fb_helper_hotplug_event+0x6c/0xc0
[   62.996020]  [<8031c0d3>] drm_fb_helper_set_par+0x93/0xc0
[   62.996020]  [<802afdaa>] fb_set_var+0x1ea/0x4b0
[   62.996020]  [<8016d6bb>] ? __lock_acquire+0x40b/0x19e0
[   62.996020]  [<80108707>] ? native_sched_clock+0x27/0xb0
[   62.996020]  [<80155bcc>] ? sched_clock_local.constprop.2+0x3c/0x170
[   62.996020]  [<802b964a>] fbcon_blank+0x2aa/0x300
[   62.996020]  [<80307371>] do_unblank_screen+0x91/0x1a0
[   62.996020]  [<802fd876>] complete_change_console+0x56/0xe0
[   62.996020]  [<802fea3f>] vt_ioctl+0x113f/0x1220
[   62.996020]  [<8050d8c7>] ? _raw_spin_unlock+0x27/0x50
[   62.996020]  [<802fd900>] ? complete_change_console+0xe0/0xe0
[   62.996020]  [<802f438a>] tty_ioctl+0x26a/0xb70
[   62.996020]  [<80155bcc>] ? sched_clock_local.constprop.2+0x3c/0x170
[   62.996020]  [<802fd900>] ? complete_change_console+0xe0/0xe0
[   62.996020]  [<80155db5>] ? sched_clock_cpu+0x75/0xd0
[   62.996020]  [<8016b98b>] ? trace_hardirqs_off+0xb/0x10
[   62.996020]  [<80155f6e>] ? local_clock+0x4e/0x60
[   62.996020]  [<80169a2d>] ? put_lock_stats.isra.22+0xd/0x30
[   62.996020]  [<802f4120>] ? no_tty+0x20/0x20
[   62.996020]  [<801ca9c3>] do_vfs_ioctl+0x73/0x5d0
[   62.996020]  [<8014ede6>] ? up_read+0x16/0x30
[   62.996020]  [<8012548b>] ? __do_page_fault+0x1bb/0x470
[   62.996020]  [<801d6f18>] ? fget_light+0x2c8/0x410
[   62.996020]  [<8022fcc0>] ? reiserfs_sync_file+0x120/0x120
[   62.996020]  [<801caf57>] sys_ioctl+0x37/0x80
[   62.996020]  [<8050eb78>] sysenter_do_call+0x12/0x36

             reply	other threads:[~2013-04-13 15:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-13 15:41 Krzysztof Mazur [this message]
2013-04-13 17:10 ` Chris Wilson
2013-04-14  6:47   ` Krzysztof Mazur

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130413154146.GA8136@shrek.podlesie.net \
    --to=krzysiek@podlesie.net \
    --cc=airlied@linux.ie \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®