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: <CAK8P3a0h4jaTdg9CmjQKNK+YniThmp4JyNbSdNJMEBj4czHGdg@mail.gmail.com>
Date:   Wed, 2 Jun 2021 17:28:56 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     Nikolai Zhubr <zhubr.2@...il.com>
Cc:     "Maciej W. Rozycki" <macro@...am.me.uk>,
        Heiner Kallweit <hkallweit1@...il.com>,
        netdev <netdev@...r.kernel.org>
Subject: Re: Realtek 8139 problem on 486.

On Wed, Jun 2, 2021 at 5:14 PM Nikolai Zhubr <zhubr.2@...il.com> wrote:
>
> Hi all,
>
> 01.06.2021 20:44, Maciej W. Rozycki:
> [...]
> >   You might be able to add a quirk based on your chipset's vendor/device ID
> > though, which would call `elcr_set_level_irq' for interrupt lines claimed
> > by PCI devices.  You'd have to match on the southbridge's ID I imagine, if
> > any (ISTR at least one Intel chipset did not have a southbridge visible on
> > PCI), as it's where the 8259A cores along with any ELCR reside.
>
> I'm looking at this comment in arch/x86/kernel/acpi/boot.c:
>
>         /*
>          * Make sure all (legacy) PCI IRQs are set as level-triggered.
>          */
>
> Doesn't it target exactly the case in question? If so, why it does not
> actually work?
>
> By legacy they likely mean non-ACPI IRQs, so for 486 it's just all of
> them.

I think this means non-MSI interrupts

> So I'd suppose, if the kernel readily knows a particular IRQ is
> assigned to PCI bus (I'm almost sure it does) shouldn't it already take
> care of proper triggering mode automatically? Because then there would
> be no need to add workarounds to individual drivers.

Without ACPI, this code is never called, instead of acpi_pci_irq_enable(),
you use pirq_enable_irq()/pcibios_lookup_irq(). There are already
some hardware specific quirks in there, it's possible this could be
changed to address your case as well, but it already looks a bit fragile.

       Arnd