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: <60D22F1D.1000205@gmail.com>
Date:   Tue, 22 Jun 2021 21:42:37 +0300
From:   Nikolai Zhubr <zhubr.2@...il.com>
To:     Arnd Bergmann <arnd@...nel.org>
CC:     "Maciej W. Rozycki" <macro@...am.me.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Heiner Kallweit <hkallweit1@...il.com>,
        netdev <netdev@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: Realtek 8139 problem on 486.

22.06.2021 16:22, Arnd Bergmann:
[...]
> In this case, the function gives up with the  "can't route interrupt\n"
> output and does not call elcr_set_level_irq(newirq). Adding the call
> to elcr_set_level_irq() in that code path as well probably makes it
> set the irq to level mode:
>
> --- a/arch/x86/pci/irq.c
> +++ b/arch/x86/pci/irq.c
> @@ -984,6 +984,7 @@ static int pcibios_lookup_irq(struct pci_dev *dev,
> int assign)
>                          irq = newirq;
>                  } else {
>                          dev_dbg(&dev->dev, "can't route interrupt\n");
> +                       elcr_set_level_irq(newirq);
>                          return 0;
>                  }
>          }

Yes, it does indeed:

[    0.765886] 8139too 0000:00:0d.0: can't route interrupt
[    0.765886] PCI: setting IRQ 9 as level-triggered
[    0.781734] 8139too 0000:00:0d.0 eth0: RealTek RTL8139 at 0xc4804000, 
00:11:6b:32:85:74, IRQ 9

And also here:

# 8259A.pl
irq 0: 00, edge
irq 1: 00, edge
irq 2: 00, edge
irq 3: 00, edge
irq 4: 00, edge
irq 5: 00, edge
irq 6: 00, edge
irq 7: 00, edge
irq 8: 02, edge
irq 9: 02, level
irq 10: 02, edge
irq 11: 02, edge
irq 12: 02, edge
irq 13: 02, edge
irq 14: 02, edge
irq 15: 02, edge

Now connection also works fine with unmodified 8139too driver.
The percentage of low-level errors stays very small:

RX packets:13953 errors:1 dropped:2 overruns:1 frame:0
TX packets:37346 errors:0 dropped:0 overruns:13 carrier:0

This fix looks really nice. Maybe it is right thing to do.


Thank you,

Regards,
Nikolai

>
> No idea if doing this is a good idea though, in particular I have no clue
> about whether this is a common scenario or not.
>
>          Arnd
>