On Tue, Jan 29, 2013 at 06:13:32PM +0200, ville.syrjala at linux.intel.com wrote: > Someone mentioned on irc that intel_crtc_wait_for_pending_flips() was > getting stuck in some cases. This rang a bell since I was poking around > that stuff last year. > > The issue that I'm trying to fix here is processes getting stuck in D > state when a GPU reset happens while page flips have been scheduled. > > Testing is easy 1) fire up 'glxgears -fullscreen', run 'gem_hang 0', > try to VT switch. Without this series X and some kworker soon get stuck > in D state and you're left with a useless box. With the patch set, you > wait a while, the GPU hangcheck kicks in, and you get your console back. Broken record maintainer request: Can you please bake that into an i-g-t? I think (hope) that running one of the delayed flip tests vs. the hangman (gem_hang is a bit evil since it can kill boxes for real) should do the trick. Then maybe also run one of the wf-vblank tests vs. hangman to check that we cancel those correctly, too. > The irc discussion was apparently about [1], but since the dmesg there > doesn't show a GPU hang, I don't see this patch set fixing it. Frankly, > I have no idea what's happening there. > > Additional work after this would involve sending out pending page flip > events. Currently if you don't do the VT switch after a hang, glxgears > remains stuck because the X server didn't get the page flip event from > the kernel. Also we should probably do an explicit intel_pipe_set_base() > with the current fb, to make sure we show the correct fb after the hang. > But I'm not going to touch these right now. Actually I'm hoping someone > else will volunteer for these tasks ;) Hm ... I guess we need to walk the file_priv event list somewhere an fire them all off, indicating somehow that things went kaboom. I think we should aim for a drm generic way to singal those even. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
