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
