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: <60D1DAC1.9060200@gmail.com>
Date:   Tue, 22 Jun 2021 15:42:41 +0300
From:   Nikolai Zhubr <zhubr.2@...il.com>
To:     Arnd Bergmann <arnd@...nel.org>
CC:     "Maciej W. Rozycki" <macro@...am.me.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Heiner Kallweit <hkallweit1@...il.com>,
        netdev <netdev@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: Realtek 8139 problem on 486.

21.06.2021 14:22, Arnd Bergmann:
[...]
> I looked some more through the git history and found at least one time
> that the per-chipset ELCR fixup came up for discussion[1], and this
> appears to have resulted in generalizing an ALI specific fixup into
> common code into common code[2], so we should already be doing
> exactly this in many cases. If Nikolai can boot the system with debugging
> enabled for arch/x86/pci/irq.c, we should be able to see exactly
> which code path is his in his case, and why it doesn't go through
> setting that register at the moment.

Here is my dmesg with debugging (hopefully) added to irq.c:

https://pastebin.com/tnC2rRDM

This is unmodified kernel, except for 8139too.c.
I've now realized maybe some usefull config option(s) related to pci irq 
handling are not enabled because due to size considerations it was 
initially configured as very minimalistic with just some really 
necessary features enabled (although ACPI, PCI_BIOS, PCI, EISA, ISA are 
enabled)

Just rechecked it again with the 8259A.pl script:

# 8259A.pl
irq 0: 00, edge
irq 1: 00, edge
irq 2: 00, edge
irq 3: 00, edge
irq 4: 00, edge
irq 5: 00, edge
irq 6: 00, edge
irq 7: 00, edge
irq 8: 00, edge
irq 9: 00, edge
irq 10: 00, edge
irq 11: 00, edge
irq 12: 00, edge
irq 13: 00, edge
irq 14: 00, edge
irq 15: 00, edge


Thank you,

Regards,
Nikolai

> I also found an slightly more recent discussion, from where it seems
> that the authoritative decision when it came up in the past was that edge
> triggered interrupts are supposed to work as long as they are not
> shared [3][4].
>
>         Arnd
>
> [1] https://lore.kernel.org/lkml/Pine.LNX.4.10.10011230901580.7992-100000@penguin.transmeta.com/
> [2] https://repo.or.cz/davej-history.git/commitdiff/e3576079d9e2#patch63
> [3] https://yarchive.net/comp/linux/edge_triggered_interrupts.html
> [4] https://lore.kernel.org/lkml/Pine.LNX.4.64.0604241156340.3701@g5.osdl.org/
>