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@xxxxxxxxxxxxxxx > > <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@xxxxxxxxxxxxxx> > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
