On Thu, Feb 12, 2026 at 06:18:17PM -0600, Mario Limonciello wrote: > Since you were able to (relatively) reliably reproduce a problem in amdgpu, > how far in your iterative flow did you get? Did you manage to need the > vendor specific handling? And presumably that helped? >
Every time I've tested it (with my repro) the full modeset has failed and it was able to recover with the vendor specific handling. Though it's worth noting that I strongly suspect a firmware hang in my case[1]. [1] https://lore.kernel.org/r/aYplYyf6Pp20lOAD@hal-station/ > > @@ -1881,13 +1886,43 @@ void drm_atomic_helper_wait_for_flip_done(struct > > drm_device *dev, > > continue; > > ret = wait_for_completion_timeout(&commit->flip_done, 10 * HZ); > > - if (ret == 0) > > - drm_err(dev, "[CRTC:%d:%s] flip_done timed out\n", > > - crtc->base.id, crtc->name); > > + if (!ret) { > > + switch (dev->reset_phase) { > > + case DRM_KMS_RESET_NONE: > > + drm_err(dev, "[CRTC:%d:%s] flip_done timed > > out\n", > > + crtc->base.id, crtc->name); > > + dev->reset_phase = DRM_KMS_RESET_FORCE_MODESET; > > + drm_kms_helper_hotplug_event(dev); > > + break; > > Since you're iterating multiple CRTCs if you manage to recover from one > with this call shouldn't you keep iterating the rest? > Most measures that the can be implemented at the kernel level (including forcing a full modeset), can't save the the current commit. So, in all likelihood we will just end up waiting an extra 10 seconds per CRTC (assuming they haven't completed already, unrelated to the forced modeset).
