On Wed, 01 Mar 2017, Jani Nikula <jani.nikula@xxxxxxxxx> wrote: > On Wed, 01 Mar 2017, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: >> On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote: >>> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c. >>> >>> I assumed it's ok, but really should have double-checked - CI caught >>> tons of fail :( > > Considering the velocity of drm-tip, I think any CI results for patches > have a rather limited best before date. The patch should've been resent > and gone through testing again before merging. > >> For the record, the failure comes from the error message in >> intel_dp_get_link_train_fallback_values() as take the fallback path. As >> userspace is informed, we don't need an *ERROR* at that point. >> >> The really interesting question is why we are seeing link-training >> failures in CI at all, and whether igt should be checking and reporting >> link-status=BAD. > > It's possible (I didn't check the logs) this pertains to the failure > mode I've sometimes seen, where clock recovery fails, but as we continue > with channel equalization anyway (without this patch), everything > succeeds there. At worst we need to root cause and fix that issue > first. :( Also, possibly to "avoid noise" in CI, the relevant error messages in intel_dp_link_training_clock_recovery() have been brushed under the carpet by demoting them to DRM_DEBUG_KMS, so we don't really see this happening unless we actually eyeball the logs. > > BR, > Jani. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
