Hi Ville, hi Daniel, dear intel experts,
just went through the problem I send around, and I guess I understand
now what happens here. The reason *why* resume fails is that there is a
deadlock situation in intel_display.c:
*) loading the module calls intel_modeset_init()
*) intel_modeset_init() calls intel_modeset_setup_hw_state(), but
protects access to it with a global lock.
*) intel_modeset_setup_hw_state() calls intel_sanitize_crtc()
*) intel_sanitize_crtc() finds that the pipe-a quirk is enabled and
calls intel_enable_pipe_a()
*) intel_enable_pipe_a() calls intel_release_load_detect_pipe(), however
not using the same mutex context as the caller (intel_modeset_init()).
*) intel_release_load_detect_pipe() again gets the mutex of the crtc.
Unfortunately, at this time, the caller (intel_modeset_init()) had
already everything locked.
Needless to say, this deadlocks and blocks the kernel completely,
causing the problem I found above.
To verify my hypothesis, I removed the locks in
intel_release_load_detect_pipe(), (obviously risking race conditions,
but never mind for the test).
The result is that the machine is responsive after the resume. It still
does not show a display (apparently, intel_sanitize_crtc() is
insufficient and does not sanitize enough), but at least one can
force-enable it again.
Thus, two bugs:
1) attempting to lock the same lock twice, nested, causing a deadlock.
The pipe A quirk is not working correctly by requiring a call into a
method that requires a lock that is already held.
2) not sanitizing the chipset sufficiently, still keeping the display
black. (This, being, of course a side effect of the buggy bios).
Hope this helps!
Thomas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
