On Mon, Jan 23, 2023 at 10:44 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > On Mon, Jan 23, 2023 at 10:00:43PM +0100, Mateusz Jończyk wrote: > > W dniu 23.01.2023 o 21:33, Bjorn Helgaas pisze: > > > On Sat, Jan 21, 2023 at 04:33:14PM +0100, Mateusz Jończyk wrote: > > >> On some platforms, the ACPI _PRT function returns duplicate interrupt > > >> routing entries. Linux uses the first matching entry, but sometimes the > > >> second matching entry contains the correct interrupt vector. > > >> > > >> Print an error to dmesg if duplicate interrupt routing entries are > > >> present, so that we could check how many models are affected. > > > > > > It shouldn't be too hard to use qemu to figure out whether Windows > > > uses the last matching entry, i.e., treating _PRT entries as > > > assignments. If so, maybe Linux could just do the same. > > > > > > Is anybody up for that? > > > > The hardware in question has a working Windows XP installation, > > and I could in theory check which interrupt vector it uses - but > > I think that such reverse engineering is forbidden by Windows' EULA. > > I'm not talking about any sort of disassembly or anything like that; > just that we can observe what Windows does given the _PRT contents. > You've already figured out that on your particular hardware, the _PRT > has two entries, and Linux uses the first one while Windows uses the > second one, right? > > On qemu, we have control over the BIOS and can easily update _PRT to > whatever we want, and then we could boot Windows and see what it uses. > But I guess maybe that wouldn't tell us anything more than what you > already discovered. > > So my inclination would be to make Linux use the last matching entry. But it would be able to log a diagnostic message anyway IMO. So maybe two steps can be taken here, (1) adding the message printout (this patch) and (2) changing the behavior?
