On 3/31/25 12:14, Jessica Clarke wrote:
On 29 Mar 2025, at 20:18, Colin Percival <cperc...@freebsd.org> wrote:
commit 0e33c2e6df7a5de65db40c7cc0fc97f66da28ccd
Author: Colin Percival <cperc...@freebsd.org>
AuthorDate: 2025-03-28 18:07:01 +0000
Commit: Colin Percival <cperc...@freebsd.org>
CommitDate: 2025-03-29 20:17:29 +0000
pci: Only re-route IRQs based on firmware on x86
There is a (very historical) call to pci_assign_interrupt for the
purpose of routing IRQs which may have been set up wrong by x86 BIOS
or firmware. On non-x86 systems, this is unnecessary; and on INTRNG
systems it results in a (synthetic) IRQ leak and ultimately a kernel
panic after many hotplug/unplug cycles.
This is in fact incorrect. Whilst there may well be a leak that needs
fixing, the rerouting is absolutely needed on non-x86 platforms. See
5884fab46153dee52bda660bcabca95c3cc97f44 and
7de649170fd804668da78f005c7966941b402106 for some of the history behind
this. As a result of this commit the problem described in the second
commit is reintroduced.
Interesting. I also got an email telling me that this broke vtnet on
powerpc64.
BTW in addition to causing a leak (which ultimately happens in intr_map_irq)
on arm64 I'm seeing the synthetic value from intr_map_irq being returned
into PCI code as a *real* IRQ and causing a panic when PCI_INVALID_IRQ is
returned. So there's something very wonky going on here...
I'll back this out for now though; this is clearly not the right fix.
--
Colin Percival
FreeBSD Release Engineering Lead & EC2 platform maintainer
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
