[Intel-gfx] [PATCH v3 0/3] Reduce context clear batch size to avoid gpu hang

[rwright at hpe.com]

On Mon, Nov 02, 2020 at 10:48:54AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 11/1/20 6:41 PM, rwright at hpe.com wrote:
> > From: Randy Wright <rwright at hpe.com>
> > 
> > For several months, I've been experiencing GPU hangs when  starting
> > Cinnamon on an HP Pavilion Mini 300-020 if I try to run an upstream
> > kernel.  I reported this recently in
> > https://gitlab.freedesktop.org/drm/intel/-/issues/2413 where I have
> > attached the requested evidence including the state collected from
> > /sys/class/drm/card0/error and debug output from dmesg.
> > 
> > I ran a bisect to find the problem, which indicates this is the
> > troublesome commit:
> > 
> >   [47f8253d2b8947d79fd3196bf96c1959c0f25f20] drm/i915/gen7: Clear all EU/L3 residual contexts
> > ...
> > I've now cleaned up the patch to employ a new QUIRK_RENDERCLEAR_REDUCED.
> > The quirk is presently set only for the aforementioned HP Pavilion Mini
> > 300-020.  The patch now touches three files to define the quirk, set it,
> > and then check for it in function batch_get_defaults.
> 
> Note I'm not really an i915 dev.
> 
> With that said I do wonder if we should not use the
> reduced batch size in a lot more cases, the machine in question uses a
> 3558U CPU if the iGPU of that CPU has this issue, then I would expect
> pretty much all Haswell U models (at a minimum) to have this issue.
> 
> So solving this with a quirk for just the HP Pavilion Mini 300-020
> seems wrong to me. I think we need a more generic way of enabling
> the reduced batch size. I even wonder if we should not simply use
> it everywhere. Since you do have a proper Haswell CPU, I guess
> it being an U model makes the hang easier to trigger, but I suspect
> the higher TPD ones may also still be susceptible ...
> 
> Regards,
> 
> Hans
> 

Hi Hans,

As you noted, the 3558U cpu is one of the least powerful processors
to be designated as a Haswell, but there are others at the low end
of the Haswell architecture that I also suspect might exhibit
similar problems.

That leads me to think that more gpu hangs like mine will be reported
when commit 47f8253d makes its way into widely used kernels. And that's
why I chose to implement a quirk that would allow enrolling other
systems as they are identified.

Your remark about applying the reduced batch size in all cases certainly
would simplify the patch.   However, I don't have any other systems
using the i915 driver on which I could try to measure the putative
performance penalty of reducing the batch size on a system that worked
properly with the large size.   So I couldn't thoroughly investigate
the consequences of a broader change.

That said, if the i915 maintainers respond in favor of the simpler
unconditional reduction of the batch size, I will be glad to
propose a much simpler version of my patch.

I probably should clarify that this patch is to resolve a problem on a
personally owned system that I use at home.  It is not related to a
problem with any of HPE's products, and so I don't have a lab full of
systems using the i915 driver on which I can test a change that would
have an effect many products.  The consumer products like Pavilions
stayed with HP when HPE split from HP five years ago.

--
Randy Wright            Usmail: Hewlett Packard Enterprise
Email: rwright at hpe.com          Servers Linux Enablement
Phone: (970) 898-0998           3404 E. Harmony Rd, Mailstop 36
                                Fort Collins, CO 80528-9599