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: <ca333156-f839-9850-6e3d-696d7b725b09@gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ