> Yes. Allthough the inteldrm code wasn't quite as bad in this respect > as the radeondrm code.
No kidding. > 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. Yes, that is my theory too, about this specific driver. Let's follow that thought. If in DVACT_WAKEUP phase it is sleeping, then it follows that the previous code path through DVACT_RESUME was sleeping as well. And hitting that incredibly evil "if (cold) return;" path. > 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. Well, the DVACT_WAKEUP should have finished it's job. The device-tree walking does not make progress until everyone wakes up, serially. Something went wrong in that path.
