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]

Date:   Sat, 29 May 2021 20:42:37 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Nikolai Zhubr <zhubr.2@...il.com>, netdev@...r.kernel.org,
        Jeff Garzik <jgarzik@...ox.com>
Subject: Re: Realtek 8139 problem on 486.

On 29.05.2021 16:08, Nikolai Zhubr wrote:
> Hello all,
> 
> I'm observing a problem with Realtek 8139 cards on a couple of 486 boxes. The respective driver is 8139too. It starts operation successfully, obtains an ip address via dhcp, replies to pings steadily, but some subsequent communication fails apparently. At least, nfsroot is unusable (it gets stuck in "... not responding, still trying" forever), and also iperf3 -c xxx when run against a neighbour box on a lan prints 2-3 lines with some reasonable 7Mbit/s rate, then just prints 0s and subsequently throws a panic about output queue full or some such.
> 
> My kernel is 4.14.221 at the moment, but I can compile another if necessary.
> I've already tried the "#define RTL8139_DEBUG 3" and "8139TOO_PIO=y" and "#define RX_DMA_BURST 4" and "#define TX_DMA_BURST 4" (in case there is a PCI burst issue, as mentioned somewhere) and nothing changed whatsoever.
> 
> Some additional notes:
> - the problem is 100% reproducable;
> - replacing this 8139 card with some entirely different 8139-based card changes nothing;
> - if I replace this 8139 with a (just random) intel Pro/1000 card, everything seem to work fine;
> - if I insert this 8139 into some other 486 motherboard (with a different chipset), everything seem to work fine again;
> - etherboot and pxelinux work fine.
> 
> I'm willing to do some debugging but unfortunately I'm not anywhere familiar with this driver and network controllers in general, therefore I'm asking for some hints/advice first.
> 
This driver hasn't seen functional changes for ages. Any previous kernel
version that works fine so that you could bisect? It will be hard to
find any developer who has test hw, especially as your issue seems to be
system-dependent.
Please provide a full dmesg log, maybe it provides a hint.

You write: "reasonable 7Mbit/s rate"
So you operate the systems with a 10Mbit hub? Or any other reason why
you consider 7Mbps reasonable?

> 
> Thank you,
> 
> Regards,
> Nikolai
Heiner