Comment 47 for bug 1275794

Created attachment 90101
dmesg 3.13.0-rc1 with hack from comment #24

dmesg 3.13.0-rc1 with:
- hack from comment #24
- DRM_DEBUG_KMS messages before, inside and when leaving a lock on mode_config.mutex
- DRM_DEBUG_KMS messages before schedule/cancel_delayed_work(_sync) on panel_vdd_work (That's why "XXX: schedule work (msecs_to_jiffies)..." shows up.)

I've to recall my statement in comment #24:
> I know that's not atomic. But, in case of the bug it runs into the if-clause (so, the mutex is locked) and gives a warning about an unbalanced unlock. Then it moves on and ironlake_panel_vdd_work() gets stuck when trying to lock mode_config.mutex.

With the hack applied it doesn't deadlock in ironlake_panel_vdd_work() when aquiring the lock on mode_config.mutex. Comparing the dmesg output with the preemption workaround, see attachment #89947, I miss intel_dp_set_signal_levels() and friends between haswell_write_eld() and ironlake_panel_vdd_work().

Notes on dmesg:
@57.286024 I've plugged in the monitor and wait.

@263.064377 More than 120s are gone and no "task kworker/xyz blocked for more than 120 seconds" message showed up. Try to start Xorg and wait.

@480.271406 "INFO: task Xorg:152 blocked for more than 120 seconds." Yep, last message in Xorg.0.log is "xfree86: Adding drm device (/dev/dri/card0)". The nice retro pattern never showed up. ;)

@480.307359 "INFO: lockdep is turned off." Heee? I've definitly enabled lockdep, made a `make clean && make` in the kernel tree and in /proc/config.gz I can find CONFIG_LOCKDEP=y.