> From: Ville Syrjälä <ville.syrj...@linux.intel.com> > On Wed, Sep 29, 2021 at 01:57:45AM +0300, Jani Nikula wrote: > > From: Dave Airlie <airl...@redhat.com> > > > > constify it while here. drop the put function since it was never > > overloaded and always has done the same thing, no point in > > indirecting it for show. > > > > Reviewed-by: Jani Nikula <jani.nik...@intel.com> > > Signed-off-by: Dave Airlie <airl...@redhat.com> > > Signed-off-by: Jani Nikula <jani.nik...@intel.com> > > This has totally broken snb and ivb machines. Total death > ensues somewhere in uncore init after some backtraces fly by. > Didn't get any logs out to disk unfortunately. Please revert. > > Sadly CI is still afraid to report when machines disappear. > For the bat report you at least get a list of machines that > were awol, but the shard run seems to not even mention that > all snbs suddenly vanished. > > I've said it before and I'll say it again. We really should > *not* be loading i915 when the machine boots. That way we'd > at least get the machine up and running and can report that > loading i915 is the thing that killed it...
Added Petri Latvala The best way to handle i915 loading in BAT would be to blacklist i915 in boot and have igt@i915_module_load@load as the first thing in fast-feedback.testlist. This would catch any i915 issue to a test and we wouldn't need to do tricks with ci@boot pseudotest. Most of the CI parts are already in place. The IGT commit to change fast-feedback needs to be coordinated. Tomi
