(In reply to Nic Soud=C3=A9e from comment #19)
> Created attachment 142692 [de=
tails] [review] [review]
> Handle INTR 0x00800000 in gf100_fifo_intr
>=20
> Attached is a patch I applied to kernel 4.19.5 to desperately thwart m=
y DELL
> E6420 from randomly getting its video busted (very similar symptons as
> Comment #3 of this ticket, =
and is why I'm posting here). I don't have any
> experience with such low-level programming but I just pretended I knew=
 what
> I was doing and cut and pasted a condition for that INTR 0x00800000 er=
ror
> which pops up every time that catastrophic random event happens.
>=20
> So far, my E6420 is working great despite receiving some of those INTR=
s,
> thanks to this patch. I am posting this in hopes it might be on the ri=
ght
> track towards getting this fixed by someone who knows what they're doi=
ng...

That's a little surprising. The existing logic will mask out further interr=
upts
by writing a 0 into the relevant bit of 2140 (which is the INTR_EN register,
which controls which intr's get surfaced).

Your logic removes that, which means that you'll keep getting the unknown
intr's, and also you add a read from 258c. That's unlikely to matter though.

However now if we *do* ever get an interrupt for that bit in 2100 after
disabling the bit in 2140, then it'll be stuck forever. I suspect that the =
"&
mask" should be removed at the beginning of that function [and thus th=
e read
from 2140].