<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Xorg freezes (only mouse and ssh are still working)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=92961#c20">Comment # 20</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Xorg freezes (only mouse and ssh are still working)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=92961">bug 92961</a>
              from <span class="vcard"><a class="email" href="mailto:imirkin@alum.mit.edu" title="Ilia Mirkin <imirkin@alum.mit.edu>"> <span class="fn">Ilia Mirkin</span></a>
</span></b>
        <pre>(In reply to Nic Soudée from <a href="show_bug.cgi?id=92961#c19">comment #19</a>)
<span class="quote">> Created <span class=""><a href="attachment.cgi?id=142692" name="attach_142692" title="Handle INTR 0x00800000 in gf100_fifo_intr">attachment 142692</a> <a href="attachment.cgi?id=142692&action=edit" title="Handle INTR 0x00800000 in gf100_fifo_intr">[details]</a></span> <a href='page.cgi?id=splinter.html&bug=92961&attachment=142692'>[review]</a> [review]
> Handle INTR 0x00800000 in gf100_fifo_intr

> Attached is a patch I applied to kernel 4.19.5 to desperately thwart my DELL
> E6420 from randomly getting its video busted (very similar symptons as
> <a href="show_bug.cgi?id=92961#c3">Comment #3</a> 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 error
> which pops up every time that catastrophic random event happens.

> So far, my E6420 is working great despite receiving some of those INTRs,
> thanks to this patch. I am posting this in hopes it might be on the right
> track towards getting this fixed by someone who knows what they're doing...</span >

That's a little surprising. The existing logic will mask out further interrupts
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 the read
from 2140].</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>