Re: ✗ Fi.CI.BAT: failure for drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 (rev2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 04, 2021 at 10:37:28AM -0800, Chiou, Cooper wrote:
> > <3> [198.221812] [drm:wa_verify [i915]] *ERROR* engine workaround lost
> > on application! (reg[b004]=0x0, relevant bits were 0x0 vs expected 0x80) <3>
> > [198.222751] [drm:wa_verify [i915]] *ERROR* engine workaround lost on
> > application! (reg[b118]=0x0, relevant bits were 0x0 vs expected 0x200000)
> > <3> [198.223076] [drm:wa_verify [i915]] *ERROR* engine workaround lost
> > on application! (reg[b11c]=0x0, relevant bits were 0x0 vs expected 0x4)
> >
> > ?
> >
> > CI does not think they are old warnings and registers are the MCR affected
> > range. So more digging would be needed to be sure. You are saying those
> > happen in our CI without the patch?
> 
> Hi Tvrtko,
> This patch only programmed 0xfdc register in reg[fdc]=0x12000000, no touch
> reg[b004]=0x0 & reg[b118]=0x0 & reg[b11c]=0x0, so I don't think this error
> is caused by this change.

0xFDC is the multicast steering register --- it controls how accesses to
other multicast registers operate.  According to bspec page 66673, range
0xB000-0xB0FF is a multicast range that uses slice steering and
0xB100-0xB3FF is a multicast range that uses L3BANK steering.  So the
regressions here are likely due to your patch introducing invalid
steering (i.e., making register accesses target fused-off or
non-existent instances of those registers).

> This error might be due to wa_write_masked_or()
> 
> Meanwhile, as you can see this 2 kbl devices has different CI result.
> 1. fi-kbl-7500u - no any error log -
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19752/fi-kbl-7500u/igt@gem_exec_suspend@xxxxxxxxxxxxx
> 
> 2. fi-kbl-7567u- has register read/write error log:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19752/fi-kbl-7567u/igt@gem_exec_suspend@xxxxxxxxxxxxx

Multi-cast fusing depends on the fusing of the specific part you're
running on.  When you see these kind of failures on one KBL and not on
another, it's an indiction that you probably need to take a look at the
steering logic being used (i.e., the programming of 0xFDC) for mistakes.
Incorrect steering logic can result in things working fine on platforms
with certain fusing configs, but still cause major regressions on
platforms with different fusing.


Matt

> 
> Cooper
> >
> > Then with regards to the reported perf drop - something to check would be if
> > the CML system you tested on has the same slice/subslice config as the one
> > from which the original report originated. Might be hard if the test farm has
> > been re-configured. But essentially running the benchmark on a few Gen9
> > machine with fused ss would be needed I think.
> >
> > And finally I couldn't find the WA entry in bspec, but maybe I just don't know
> > where to look. Someone better versed to finding WA. Maybe Matt you would
> > have time for a quick check if
> > WaProgramMgsrForCorrectSliceSpecificMmioReads is documented as
> > applicable to Gen9?
> >
> > Regards,
> >
> > Tvrtko

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux