[Intel-gfx] X hang with quirk VT switches

[Takashi Iwai]

Hi,

while checking the reported bug about VT switch hang on openSUSE 13.2,
I also could reproduce a similar issue as reported: namely, X hangs
when repeatedly switching VT quickly.

For example, running the following on KDE results in the stall of X.

	% for i in $(seq 1 100); do chvt 1; chvt 7; done

Looking at the sysrq-t output, it stalls at drm_read().  And after
putting some debug prints at event handling codes, it shows like:

 drm_queue_vblank_event event_space=4064
 send_vblank_event event_space=4064
 drm_poll ENTER event_space=4064
 drm_poll mask=0x41 event_space=4064
 drm_poll ENTER event_space=4064
 drm_poll mask=0x41 event_space=4064
 drm_read ENTER event_space=4064
 drm_read total=32 event_space=4096
 drm_poll ENTER event_space=4096
 drm_poll mask=0x0 event_space=4096
 drm_read ENTER event_space=4096
 drm_read ENTER event_space=4096
 drm_read ENTER event_space=4096

So, after a vblank event, two poll calls succeeded, followed by one
drm_read().  After that, there were one poll call without event,
followed by three(!) drm_read() calls.  The last three drm_read()
never exited, thus X stalled.  So, this looks like a race or a
refcount issue somewhere.

Note that the problem disappears when passing drm.debug=0x0e.  And it
doesn't seem to happen with a 2D desktop, either.  The race window
is supposed to be fairly small.

The problem is reproduced reliably with xf86-video-intel 2.99.916 and
the latest Linus tree on a HP laptop with IVB.  Also seen on HSW and
other chips, too.

Does this ring a bell to anyone?


thanks,

Takashi