Re: git: 0e33c2e6df7a - main - pci: Only re-route IRQs based on firmware on x86

From: Colin Percival <cperciva_at_freebsd.org>
Date: Mon, 31 Mar 2025 20:59:37 UTC 
On 3/31/25 12:14, Jessica Clarke wrote:
> On 29 Mar 2025, at 20:18, Colin Percival <cperciva@FreeBSD.org> wrote:
>> commit 0e33c2e6df7a5de65db40c7cc0fc97f66da28ccd
>> Author:     Colin Percival <cperciva@FreeBSD.org>
>> AuthorDate: 2025-03-28 18:07:01 +0000
>> Commit:     Colin Percival <cperciva@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