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: <alpine.DEB.2.21.2106032014320.2979@angie.orcam.me.uk>
Date:   Thu, 3 Jun 2021 20:32:06 +0200 (CEST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Heiner Kallweit <hkallweit1@...il.com>
cc:     Nikolai Zhubr <zhubr.2@...il.com>, Arnd Bergmann <arnd@...nel.org>,
        netdev <netdev@...r.kernel.org>, Jeff Garzik <jgarzik@...ox.com>
Subject: Re: Realtek 8139 problem on 486.

On Tue, 1 Jun 2021, Heiner Kallweit wrote:

> > Now I'd like to ask, is quality reliable fix still wanted in mainline or rather not? Because I'll personally do my best to create/find a good fix anyway, but if it is of zero interest for mainline, I'll probably not invest much time into communicating it. My understanding was that default rule is "if broken go fix it" but due to the age of both code and hardware, maybe it is considered frozen or some such (I'm just not aware really).
> > 
> Driver 8139too has no maintainer. And you refer to "mainline" like to a number of developers
> who are paid by somebody to maintain all drivers in the kernel. That's not the case in general.
> You provided valuable input, and if you'd contribute to improving 8139too and submit patches for
> fixing the issue you're facing, this would be much appreciated.

 It's an issue in x86 platform code, not the 8139too driver.  Any option 
card wired to PCI in this system somehow could suffer from it.  Depending 
on how you look at it you may or may not qualify it as a bug though, and 
any solution can be considered a workaround (for a BIOS misfeature) rather 
than a bug fix.

 The question is IMHO legitimate, and I can't speak for x86 platform 
maintainers.  If I were one, I'd accept a reasonable workaround and it 
does not appear to me it would be a very complex one to address this case: 
basically a PCI quirk to set "this southbridge has ELCR at the usual 
location" (if indeed it does; you don't want to blindly poke at random 
port I/O locations in generic code), and then a tweak to `pirq_enable_irq' 
or `pcibios_lookup_irq' as Arnd has suggested.

  Maciej