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
