From: Thomas Gleixner <tglx@linutronix.de>
To: Arnd Bergmann <arnd@kernel.org>, "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>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: Realtek 8139 problem on 486.
Date: Sun, 20 Jun 2021 02:34:16 +0200 [thread overview]
Message-ID: <877dipgyrb.ffs@nanos.tec.linutronix.de> (raw)
In-Reply-To: <CAK8P3a0oLiBD+zjmBxsrHxdMeYSeNhg6fhC+VPV8TAf9wbauSg@mail.gmail.com>
On Fri, Jun 04 2021 at 09:36, Arnd Bergmann wrote:
> On Thu, Jun 3, 2021 at 8:32 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>> 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.
Why?
> 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.
The usual fix the symptom not the root cause approach. So, no.
> 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.
Correct. Any legacy PCI interrupt #A..#D must be level triggered. Edge
is simply wrong for those. But of course that's wishful thinking. See
below.
Vs. ELCR: it's documented to be 0x4d0, 0x4d1 and the kernel has it hard
coded. So that's really the least of my worries.
> (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.
Yes. It still is because even today BIOS tinkerers get it wrong.
> 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.
Legacy PCI interrupts are specified as being level triggered because
legacy PCI requires to share interrupts and you cannot share edge
triggered interrupts reliably. PCI got a lot of things wrong, but this
part is completely correct.
From experience I know that 8139 depends on that and I debugged that
myself many years ago on an ARM system which had the trigger type
configuration wrong.
Let me clarify why this breaks first. The interesting things to look at
are:
- the device internal interrupt condition which in this case are
package received or transmitted and status change
- the interrupt line
Let's look at the timing diagram of simple RX events:
___________________ _____...
RX ___| |_____________|
___________________ ____...
INTA ____| |_____________|
_ INT handler _____ RETI _ __...
Kernel ______| |______|
Trivial case which works with both edge and level. Now let me add TX
complete for the level triggered case:
___________________
RX ___| |_____________
_______________
TX _____________________|
________________________________
INTA ____|
_ INT handle RX ___ RETI_ __ INT handle TX
Kernel ______| |_|
Works as expected. Now the same with edge mode on the i8259 side:
___________________
RX ___| |_____________
_______________
TX _____________________|
________________________________
INTA ____|
_ INT handle RX ___ RETI_
Kernel ______| |_____ <- FAIL
Edge mode loses the TX interrupt when it arrives before the RX condition
is cleared because INTA will not go low.
The driver cannot do anything about it reliably because all of this is
asynchronous. The loop approach is a bandaid and kinda works, but can it
work reliably? No. Aside of that it's curing the symptom which is the
wrong approach.
The only reasonable solution to this is to enforce level even if that
BIOS switch says otherwise.
> 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.
Yes, sigh. The reason why this BIOS switch exists, which should have
never existed, is that during the transition from EISA which was edge
triggered to PCI some card manufacturers just changed the bus interface
of their cards but completely missed the edge -> level change in
hardware either by stupidity or intentionally so they did not have to
make any changes to the rest of the hardware and to drivers.
The predominant OS'es at that time of course did not have an easy way to
add a quirk to fix this, so the way out was to add the chicken bit
option to the BIOS which then either tells the OS the trigger mode for
INTA..INTD and just sets up ELCR before booting the OS. I have faint
memories that I had to use such a BIOS switch long time ago to get some
add-on PCI card working.
So the right thing to do is to leave 8139 as is and add a PCI quirk
which enforces level trigger type for 8139 in legacy PCI interrupt mode.
Alternatively we can just emit a noisy warning when a legacy PCI
interrupt is configured as edge by the BIOS and tell people to toggle
that switch if stuff does not work. Though that might be futile because
not all BIOSes have these toggle options.
Thanks,
tglx
next prev parent reply other threads:[~2021-06-20 0:34 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
2021-06-20 0:34 ` Thomas Gleixner [this message]
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=877dipgyrb.ffs@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=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=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.