From: Arnd Bergmann <arnd@kernel.org>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
Nikolai Zhubr <zhubr.2@gmail.com>,
netdev <netdev@vger.kernel.org>, Jeff Garzik <jgarzik@pobox.com>,
"the arch/x86 maintainers" <x86@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: Realtek 8139 problem on 486.
Date: Fri, 4 Jun 2021 09:36:33 +0200 [thread overview]
Message-ID: <CAK8P3a0oLiBD+zjmBxsrHxdMeYSeNhg6fhC+VPV8TAf9wbauSg@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2106032014320.2979@angie.orcam.me.uk>
On Thu, Jun 3, 2021 at 8:32 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> 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.
I think it would be good though to reinstate the driver workaround in some way,
regardless of whether the x86 platform code gets changed or not.
From the old linux-2.6.2 code it appears that someone had intentionally
added the loop as a hack to make it work on a broken or misconfigured BIOS.
It's hard to know if that was indeed the intention, but it's clear that the
driver change in 2.6.3 broke something that worked (most of the time)
without fixing it in a better way.
> 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.
(adding the x86 maintainers to Cc, the thread is archived at
https://lore.kernel.org/netdev/60B24AC2.9050505@gmail.com/)
Changing the x86 platform code as well would clearly help avoid similar
issues with other PCI cards on these broken platforms, but doing it
correctly seems hard for a couple of reasons.
It sounds like it would have been a good idea 20 years ago when the
broken i486 platforms were still fairly common, but now we don't even
know whether the code was intentional or not. I don't remember a lot of
the specifics of pre-APIC x86, but I do remember IRQ configuration
as a common problem without a single good solution.
There is a realistic chance that other combinations of broken hardware
and drivers rely on the x86 PCI code doing exactly what it does today.
If overriding the BIOS setting breaks something that works today, nothing
is gained, because the next person running into an i486 PCI specific bug
is unlikely to be as persistent and competent as Nikolai in tracking down
the root cause.
Doing a narrower change to a specific chipset, motherboard or BIOS
would be less risky, but would likely miss similar cases. Any x86
specific change would clearly also miss similar problems that may
or may not exist on other architectures.
Arnd
next prev parent reply other threads:[~2021-06-04 7:38 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-29 14:08 Realtek 8139 problem on 486 Nikolai Zhubr
2021-05-29 18:42 ` Heiner Kallweit
2021-05-29 21:44 ` tedheadster
2021-05-30 0:49 ` Nikolai Zhubr
2021-05-30 10:36 ` Nikolai Zhubr
2021-05-30 17:27 ` Nikolai Zhubr
2021-05-30 20:54 ` Arnd Bergmann
2021-05-30 23:17 ` Nikolai Zhubr
2021-05-31 16:53 ` Nikolai Zhubr
2021-05-31 18:39 ` Arnd Bergmann
2021-05-31 22:18 ` Nikolai Zhubr
2021-05-31 22:30 ` Heiner Kallweit
2021-06-01 7:20 ` Arnd Bergmann
2021-06-01 10:53 ` Nikolai Zhubr
2021-06-01 11:42 ` Heiner Kallweit
2021-06-01 16:09 ` Nikolai Zhubr
2021-06-01 21:48 ` Heiner Kallweit
2021-06-01 23:37 ` Nikolai Zhubr
2021-06-02 9:12 ` Arnd Bergmann
2021-06-07 23:07 ` Nikolai Zhubr
2021-06-08 7:44 ` Arnd Bergmann
2021-06-08 20:32 ` Nikolai Zhubr
2021-06-08 20:45 ` Arnd Bergmann
2021-06-08 22:07 ` Nikolai Zhubr
2021-06-09 7:09 ` Arnd Bergmann
2021-06-12 17:40 ` Nikolai Zhubr
2021-06-12 22:41 ` Arnd Bergmann
2021-06-13 14:10 ` Nikolai Zhubr
2021-06-13 21:52 ` Arnd Bergmann
2021-06-03 18:32 ` Maciej W. Rozycki
2021-06-04 7:36 ` Arnd Bergmann [this message]
2021-06-20 0:34 ` Thomas Gleixner
2021-06-20 10:19 ` Arnd Bergmann
2021-06-21 4:10 ` Maciej W. Rozycki
2021-06-21 11:22 ` Arnd Bergmann
2021-06-21 14:42 ` Maciej W. Rozycki
2021-06-21 15:20 ` Arnd Bergmann
2021-06-22 11:12 ` David Laight
2021-06-22 12:42 ` Nikolai Zhubr
2021-06-22 13:22 ` Arnd Bergmann
2021-06-22 18:42 ` Nikolai Zhubr
2021-06-22 19:26 ` Arnd Bergmann
2021-06-23 1:04 ` Maciej W. Rozycki
2021-06-24 17:56 ` Nikolai Zhubr
2021-06-24 18:25 ` Maciej W. Rozycki
2021-07-14 23:32 ` Maciej W. Rozycki
2021-07-15 7:32 ` Nikolai Zhubr
2021-07-16 23:48 ` Maciej W. Rozycki
2021-06-23 16:31 ` Nikolai Zhubr
2021-06-23 23:39 ` Maciej W. Rozycki
2021-06-24 8:28 ` Arnd Bergmann
2021-07-02 19:02 ` Nikolai Zhubr
2021-07-03 9:10 ` Arnd Bergmann
2021-07-08 19:21 ` Nikolai Zhubr
2021-07-09 7:31 ` Arnd Bergmann
2021-07-09 12:43 ` David Laight
2021-06-01 17:44 ` Maciej W. Rozycki
2021-06-02 15:14 ` Nikolai Zhubr
2021-06-02 15:28 ` Arnd Bergmann
2021-05-31 19:05 ` Heiner Kallweit
2021-05-31 18:29 ` Denis Kirjanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK8P3a0oLiBD+zjmBxsrHxdMeYSeNhg6fhC+VPV8TAf9wbauSg@mail.gmail.com \
--to=arnd@kernel.org \
--cc=bp@alien8.de \
--cc=hkallweit1@gmail.com \
--cc=hpa@zytor.com \
--cc=jgarzik@pobox.com \
--cc=macro@orcam.me.uk \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=zhubr.2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.