netdev - Re: Realtek 8139 problem on 486.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a2PEQgC1GQTVHafKyxSbKNigiTDD6rzAC=6=FY1rqBJhw@mail.gmail.com>
Date:   Tue, 1 Jun 2021 09:20:17 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Nikolai Zhubr <zhubr.2@...il.com>, netdev <netdev@...r.kernel.org>,
        Jeff Garzik <jgarzik@...ox.com>
Subject: Re: Realtek 8139 problem on 486.

On Tue, Jun 1, 2021 at 12:31 AM Heiner Kallweit <hkallweit1@...il.com> wrote:
> On 01.06.2021 00:18, Nikolai Zhubr wrote:
> > But meanwhile, I tried a dumb thing instead, and it worked!
> > I've put back The Loop:
> > ---------------------------
> > +       int boguscnt = 20;
> >
> >         spin_lock (&tp->lock);
> > +       do {
> >         status = RTL_R16 (IntrStatus);
> >
> >         /* shared irq? */
> > @@ -2181,6 +2183,8 @@
> >                 if (status & TxErr)
> >                         RTL_W16 (IntrStatus, TxErr);
> >         }
> > +       boguscnt--;
> > +       } while (boguscnt > 0);
> >   out:
> > ---------------------------
> > With this added, connection works fine again. Of course it is silly, but hopefully it gives a path for a real fix.
> >
>
> What was discussed here 16 yrs ago should sound familiar to you.
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg92234.html
> "It was an option in my BIOS PCI level/edge settings as I posted."
> You could check whether you have same/similar option in your BIOS
> and play with it.

So it appears that the interrupt is lost if new TX events come in after the
status register is read, and that checking it again manages to make that
race harder to hit, but maybe not reliably.

The best idea I have for a proper fix would be to move the TX processing
into the poll function as well, making sure that by the end of that function
the driver is either still in napi polling mode, or both RX and TX interrupts
are enabled and acked.

         Arnd