> From: Theo de Raadt <[email protected]> > Date: Fri, 07 Mar 2014 09:15:20 -0700 > > > On Fri, Mar 07, 2014 at 10:51:50AM +0100, Landry Breuil wrote: > > > [...] > > > To everyone experiencing this issue, can you try with this diff: > > > [...] > > > > Seems to work. I get consistent ~60 FPS with glxgears during > > suspend/resume cycles where before I'd get ~60 until the first suspend > > and after resuming it'd cap at ~15. > > > > Would there be a downside to doing the thawing and mode restoration both > > in DVACT_WAKEUP and DVACT_RESUME? > > Somewhat sad. If this is what is causing the problem, it indicates > that a bug lies somewhere else. The difference between DVACT_RESUME > and DVACT_WAKEUP are as follows: > > In the resume sequence, after handling some very base or ISA principle > parts of the machine, we still have interrupts disabled. > > We then traverse the device tree telling each driver that now is the > time for doing some resume work, we request DVACT_RESUME work. In > this phase, they should not call any function which might "sleep", > because there will be nothing to wake things up. > > After that is done, we enable interrupts, and now traverse the device > tree again with the second method DVACT_WAKEUP. In this case, any > driver which decides to do work may call something which sleeps. > > This two step operation has managed to get suspend/resume to where it > is. > > Now why was inteldrm changed to use DVACT_RESUME? > > Well, this driver is imported/modified from KMS upstream, and we have > found a quite long code path that is difficult to verify as sleep > free. Some tests were run, and DVACT_WAKEUP seemed to work. As a > general principle if we can get DVACT_WAKEUP to work, we are better > off. There are some big benefits if we can get it working...
Yes. Allthough the inteldrm code wasn't quite as bad in this respect as the radeondrm code. My hopethesis about what's causing the problem here is that during the DVACT_WAKEUP phase, some drivers actually sleep and that userland processes actually get to run. This causes the X server (directly or indirectly) to issue some drm ioctls when the hardware isn't quite ready to deal with this, making the ioctl return with an error. And the xf86-video-intel driver doesn't deal with this very well. The question here is who is at fault here: the kernel (because it shouldn't make the ioctl fail or perhaps make it fail with a different error code), or the xf86-video-intel driver because it should recognize this as a temporary failure and try again later. If it is the latter case, we're probably fucked.
