Re: CI igt-all on drm-intel-next-fixes gem_exec_* and other gem_*

Chris Wilson
2018-02-01T21:24:37Z

Quoting Rodrigo Vivi (2018-02-01 21:00:45)
> Ok, things look much cleaner(greener) on last run after I rebased on
> top of a more recent drm-next.
>
> https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/shards.html
>
> My only concern right now is this one:
>
> https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/CI_DINF_97/shard-kbl5/igt@gem_softpin@noreloc-s3.html
>
> <7>[ 256.521580] [IGT] gem_softpin: starting subtest noreloc-S3
> <7>[ 256.561583] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus dpc] timed
> out, falling back to bit banging on pin 4
> <7>[ 256.564321] [drm:drm_dp_dual_mode_detect] DP dual mode HDMI ID: (err -6)
> <7>[ 256.564326] [drm:drm_helper_hpd_irq_event]
> [CONNECTOR:70:HDMI-A-1] status updated from disconnected to
> disconnected
> �������������������������������������������
>
> Could this be caused by?:
>
> commit 90024a5951029685acc5396258f1b0de9b23cf4a
> Author: Stefan Brüns <stefan.bruens@rwth-aachen.de>
> Date: Sun Dec 31 23:34:54 2017 +0100
>
> drm/i915: Try EDID bitbanging on HDMI after failed read

Indeterminate. The loss of the log does suggest that something went
catastrophically wrong on suspend, and we have the circumspect evidence
that hpd was active at that time. But we do flush those workqueues,
right? So it may just be the grue that sometimes likes to eat machines
for no reason.
-Chris