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

[Daniel Vetter <daniel@ffwll.ch>]

On Mon, Apr 01, 2019 at 09:22:34AM +0200, Daniel Vetter wrote:
> 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.

- unplug with multiple busy contexts (from multiple fd) active, to
  exercise scheduler paths.

> 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@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev