The patch https://patchwork.freedesktop.org/patch/166512/ which relies on HW tracking for frontbuffer flushes/invalidations leads to an indefinite block when running any of the *psr* subtests of the kms_frontbuffer_tracking test. ===Failure analysis=== Subtest: kms_frontbuffer_tracking --run-subtest psr-1p-rte The test gets blocked (indefinitely) at the openat system call while trying to open "crtc-%d/crc/data" (crtc-0 in this case). On the kernel side, the crtc_crc_open call waits in the crc wait queue until the display_pipe_crc_irq_handler wakes it up which never happens. On the PSR side, the intel_psr_flush returns without the SW initiating psr_exit since we are relying on HW tracking. So either the HW tracking is not working as expected (because pipe CRC generation is stuck) OR the test is not designed for HW tracking. Either way, it should not get blocked indefinitely. Can we have: A timeout in this igt test. OR Wait_event_interruptible_lock_irq_timeout instead of Wait_event_interruptible_lock_irq inside crtc_crc_open() OR Skip the test if HW tracking is enabled. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
