[igt-dev] [PATCH] tests: Add a new test for driver/device hot remove

[Daniel Vetter]

On Fri, Mar 29, 2019 at 12:47:32PM +0200, Petri Latvala wrote:
> On Thu, Mar 28, 2019 at 05:47:19PM +0100, Janusz Krzysztofik wrote:
> > Run a dummy load in background to put some workload on a device, then try
> > to either remove (unplug) the device from its bus, or unbind the device's
> > driver from it, depending on which subtest has been selected.
> > 
> > The driver hot unbind / device hot unplug operation is expected to succeed
> > in a reasonable time, however long timeouts are used to allow kernel
> > level timeouts pop up first if any.
> > 
> > Please note that if running both subtests consecutively, the second one
> > is always skipped as the device is no longer available as soon as the
> > first subtest is completed.  The most reliable way to run another subtest
> > is to reboot the system first, then select next subtest to be run.
> 
> This is a requirement that won't fly for CI use. Is the
> rebinding/whatever of the device not possible to do? By the test?
> 
> Does it also apply to running other test binaries after running the
> first subtest? As in, is it just a timing issue?

Yeah like the module reload testcase this testcase needs to restore the
driver to working state afterwards. I think there's a corresponding rebind
sysfs file too.

btw since you started with this, bunch more subtests we need to validate
this:
- unbind while an ioctl is called. Especially fun with all the ones that
  can block. We need a subtest for each ioctl to make sure stuff works
  correctly. At least, complex ioctl probably need more than that.

- unplug while atomic commit pending

- unplug with dma-buf exported, with various external users doing stuff to
  that dma-buf

- unplug with dma-fence exported (either as syncpt, drm_syncobj or
  implicitly attached to a dma-buf), this one probably needs lots of
  a few variants to cover everything.

There's probably a lot more (you should discover endless amounts of oops,
this area is full of bugs), but this should at least get you started.

And you probably want an entire team of engineers fixing the kernel bugs
you uncover :-/

Cheers, Daniel

> > +	igt_subtest("unplug") {
> > +		igt_spin_t *spin;
> > +
> > +		/* Verify if a suitable DRM device/driver exists */
> > +		igt_skip_on(device < 0);
> > +
> > +		/* Run background workload */
> > +		spin = igt_spin_batch_new(device, .flags = IGT_SPIN_POLL_RUN);
> 
> 
> igt_spin_batch_new requires DRIVER_INTEL, doesn't it?
> 
> 
> > +		igt_spin_busywait_until_running(spin);
> > +
> > +		/* Make the device disappear */
> > +		igt_set_timeout(60, "Device unplug timeout!");
> > +		device_unplug(device);
> > +		igt_reset_timeout();
> > +
> > +		close(device);
> > +		device = -1;
> > +	}
> > +
> > +	igt_subtest("unbind") {
> > +		igt_spin_t *spin;
> > +
> > +		/* Verify if a suitable DRM device/driver exists */
> > +		igt_skip_on(device < 0);
> 
> 
> Ah, I see. The skip if running consecutively is because the previous
> subtest closed the fd.
> 
> Another fixture before this subtest, get the device plugged back,
> reopen driver?
> 
> 
> 
> -- 
> Petri Latvala
> _______________________________________________
> igt-dev mailing list
> igt-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch