[Intel-gfx] [igt-dev] [PATCH i-g-t] tests/i915_suspend: Free device list after *-without-i915 subtests

Petri Latvala adrinael at adrinael.net
Tue Feb 14 06:15:25 UTC 2023


On Mon, Feb 13, 2023 at 10:51:39AM +0100, Zbigniew Kempczyński wrote:
> On Fri, Feb 10, 2023 at 10:33:21PM +0100, Janusz Krzysztofik wrote:
> > On Thursday, 9 February 2023 20:32:31 CET Janusz Krzysztofik wrote:
> > > If any of *-without-i915 subtests fails or skips for any reason, it may
> > > leave the i915 module unloaded while keeping our device list populated
> > > with initially collected data.  In a follow up igt_fixture section we then
> > > try to reopen the device.  If the test has been executed with a device
> > > filter specified, an attempt to open the device finds a matching entry
> > > that belongs to the no longer existing device in that initially collected
> > > device list, fails to stat() it, concludes that's because of the device
> > > having been already open, and returns an error.
> > > 
> > > Fix this potentially confusing test result by freeing the potentially
> > > outdated device list before continuing with drm_open_driver().
> > 
> > Freeing device list occurred not safe if device scan was not performed before.  
> > I can see 3 potential solutions:
> > 1) force device rescan instead of free before calling drm_open_driver(),
> > 2) teach igt_device_free() to return immediately if the device list has not 
> >    been allocated,
> > 3) provide a has_device_list() helper for to be used if not sure before 
> >    calling igt_device_free().
> > 
> > Any preferences?
> 
> I would enforce rescan.
> 
> BTW I wonder how it can happen if runner is executing each subtest
> in new process so you're starting from scratch and rescan should be
> executed automatically.
> 
> Is is the case you're running few tests from the console?

For the record, igt_runner has --multiple-mode where multiple subtests
are executed in the same exec.


-- 
Petri Latvala


More information about the Intel-gfx mailing list