Possible regression in 3.17-rc2 in i915 driver

[Tibor Billes]

Hi!

I tried to upgrade my kernel from 3.16 to 3.17-rc2 and I found that my laptop
was unable to boot. The boot process hangs after 2-3 seconds (according to
timestamps of log messages). The last kernel log line I usually see is the
discovery of my touchpad: "input: SynPS/2 Synaptics TouchPad as
/devices/platform/i8042/serio2/input/input11".

I did a git bisect and it pointed me to the following commit:
commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44
Author: Ville SyrjÃlà <ville.syrjala@xxxxxxxxxxxxxxx>
Date:ÂÂ Mon Aug 11 13:15:35 2014 +0300
Â
ÂÂÂ drm/i915: Fix locking for intel_enable_pipe_a()
Â
ÂÂÂ intel_enable_pipe_a() gets called with all the modeset locks already
ÂÂÂ held (by drm_modeset_lock_all()), so trying to grab the same
ÂÂÂ locks using another drm_modeset_acquire_ctx is going to fail miserably.
ÂÂÂ Â
ÂÂÂ Move most of the drm_modeset_acquire_ctx handling (init/drop/fini)
ÂÂÂ out from intel_{get,release}_load_detect_pipe() into the callers
ÂÂÂ (intel_{crt,tv}_detect()). Only the actual locking and backoff
ÂÂÂ handling is left in intel_get_load_detect_pipe(). And in
ÂÂÂ intel_enable_pipe_a() we just share the mode_config.acquire_ctx from
ÂÂÂ drm_modeset_lock_all() which is already holding all the relevant locks.
ÂÂÂ Â
ÂÂÂ It's perfectly legal to lock the same ww_mutex multiple times using the
ÂÂÂ same ww_acquire_ctx. drm_modeset_lock() will convert the returned
ÂÂÂ -EALREADY into 0, so the caller doesn't need to do antyhing special.
ÂÂÂ Â
ÂÂÂ Fixes a hang on resume on my 830.
ÂÂÂ Â
 Signed-off-by: Ville SyrjÃlà <ville.syrjala@xxxxxxxxxxxxxxx>
ÂÂÂ Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
ÂÂÂ Cc: stable@xxxxxxxxxxxxxxx
ÂÂÂ Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx>
Â
I tried booting with the above commit reverted on top of 3.17-rc2 and it
booted successfully.
Â
I also did a MagicSyrq-W (Display list of blocked (D state) tasks) after the
boot process stopped (using plain 3.17-rc2, without reverting the above commit)
and it showed that plymouthd was blocked with the following call trace (hand
copied):
irq_exit
common_interrupt
schedule_preemt_disabled
__mutex_lock_slowpath
mutex_lock
drm_modeset_lock
drm_getconnector
drm_mode_getcrttc
drm_ioctl
...
Â
This may have something to do with the hang or it may not, I don't know but is
related to drm locking so I thought it was a good idea to mention it.
Â
My laptop is an old Fujitsu-Siemens Amilo M1450g, running Linux Mint 16.
Â
Let me know if I can help further debug this issue.
Â
Tibor Billes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/