Date: Mon, 31 Mar 2025 13:59:37 -0700 From: Colin Percival <cperciva@freebsd.org> To: Jessica Clarke <jrtc27@freebsd.org>, John Baldwin <jhb@freebsd.org> Cc: "src-committers@freebsd.org" <src-committers@FreeBSD.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@FreeBSD.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@FreeBSD.org> Subject: Re: git: 0e33c2e6df7a - main - pci: Only re-route IRQs based on firmware on x86 Message-ID: <8897817f-b403-4e72-8fa7-87db143695cd@freebsd.org> In-Reply-To: <F51D8FD7-4EB5-4EE8-A1AB-867B0FC392CD@freebsd.org> References: <202503292018.52TKI7va048377@gitrepo.freebsd.org> <F51D8FD7-4EB5-4EE8-A1AB-867B0FC392CD@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8897817f-b403-4e72-8fa7-87db143695cd>