On Wed, Aug 30, 2017 at 01:56:40PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-08-30 13:23:56) > > Or just the need to add a pile more tests to pm_rpm? > > No. It's just your regular combinatorial explosion. The approach I would > take here would be to register a sysenter callback that attempted to do a > rpm suspend (i.e. so ~every ioctl would start from idle, and controlled > via the faultinjection framework) and then run the minimal test set that > exercises all ioctl paths, and then expand to all driver branches. > > First we need coverage feedback. What I meant to imply: As long as any display is on we will never rpm suspend. Mostly this is the case for CI machines. The new testcases I've had in mind would explicitly dpms off the display before running a set of gem testcases. We don't want to do that everywhere though, because a dpms on/off is very costly. I guess once we switch (eventually, hopefully) to a binary-at-time model for full igt CI we could amortize that over a pile of substests and do it almost everywhere. So I think adding a force rpm suspend won't help, because under normal CI runs we can't ever get there becaus of the active display. And that's why we're not hitting all these tons of problems anywhere else. This might also be good reason for more server chips, or at least fake server chips, where we disable the display entirely. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
