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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
