From: Bjorn Helgaas <helgaas@kernel.org>
To: "Mateusz Jończyk" <mat.jonczyk@o2.pl>
Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-i2c@vger.kernel.org,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>, Borislav Petkov <bp@suse.de>,
Jean Delvare <jdelvare@suse.com>, Jean Delvare <jdelvare@suse.de>
Subject: Re: [PATCH v3 RESEND] acpi,pci: warn about duplicate IRQ routing entries returned from _PRT
Date: Mon, 23 Jan 2023 15:44:14 -0600 [thread overview]
Message-ID: <20230123214414.GA987407@bhelgaas> (raw)
In-Reply-To: <0113ca60-acf2-f4db-3230-959e9bb15726@o2.pl>
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.
Bjorn
next prev parent reply other threads:[~2023-01-23 21:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-21 15:33 [PATCH v3 RESEND] acpi,pci: warn about duplicate IRQ routing entries returned from _PRT Mateusz Jończyk
2023-01-23 20:33 ` Bjorn Helgaas
2023-01-23 21:00 ` Mateusz Jończyk
2023-01-23 21:44 ` Bjorn Helgaas [this message]
2023-01-30 15:56 ` Rafael J. Wysocki
2023-01-30 17:45 ` Bjorn Helgaas
2023-01-30 19:36 ` Mateusz Jończyk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230123214414.GA987407@bhelgaas \
--to=helgaas@kernel.org \
--cc=bp@suse.de \
--cc=jdelvare@suse.com \
--cc=jdelvare@suse.de \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mat.jonczyk@o2.pl \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).