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: <60B7A05D.3070704@gmail.com>
Date:   Wed, 02 Jun 2021 18:14:37 +0300
From:   Nikolai Zhubr <zhubr.2@...il.com>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
CC:     Heiner Kallweit <hkallweit1@...il.com>,
        Arnd Bergmann <arnd@...nel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: Realtek 8139 problem on 486.

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. 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.


Thank you,

Regards,
Nikolai

>   It would be the right thing to do IMO; those early PCI systems often got
> these things wrong, and the selection for the trigger mode shouldn't have
> been there in the BIOS setup in the first place (the manufacturer couldn't
> obviously figure it out how to do this correctly by just scanning PCI, so
> they shifted the burden onto the end user; though I have to admit odd hw
> used to be made too, e.g. I remember seeing a PCI PATA option card with an
> extra cable and a tiny PCB stub to be plugged into the upper part of a
> spare ISA slot to get IRQ 14/15 routed from there).
>
>   HTH,
>
>    Maciej
>