From: Kalle Valo <kvalo@codeaurora.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Govind Singh <govinds@codeaurora.org>,
linux-pci@vger.kernel.org, linux-wireless@vger.kernel.org,
Devin Bayer <dev@doubly.so>,
Thomas Krause <thomaskrause@posteo.de>,
ath11k@lists.infradead.org
Subject: Re: pci_alloc_irq_vectors fails ENOSPC for XPS 13 9310
Date: Tue, 03 Nov 2020 08:49:06 +0200 [thread overview]
Message-ID: <87k0v3szod.fsf@codeaurora.org> (raw)
In-Reply-To: <20201102205752.GA34153@bjorn-Precision-5520> (Bjorn Helgaas's message of "Mon, 2 Nov 2020 14:57:52 -0600")
Bjorn Helgaas <helgaas@kernel.org> writes:
> [+cc Govind, author of 5697a564d369 ("ath11k: pci: add MSI config
> initialisation")]
>
> On Mon, Nov 02, 2020 at 08:49:51PM +0200, Kalle Valo wrote:
>> + linux-wireless, linux-pci, devin
>>
>> Thomas Krause <thomaskrause@posteo.de> writes:
>>
>> >> I had the same problem as well back in the days, for me enabling
>> >> CONFIG_IRQ_REMAP helped. If it helps for you also I wonder if we should
>> >> mention that in the ath11k warning above :)
>> >
>> > CONFIG_IRQ_REMAP did not do the trick. I noticed that the Wi-Fi card
>> > is behind a PCI bridge which is also disabled, could this be a
>> > problem?
>> >
>> > 00:1c.0 PCI bridge: Intel Corporation Device a0b8 (rev 20) (prog-if 00
>> > [Normal decode])
>> > Flags: bus master, fast devsel, latency 0, IRQ 123
>> > Bus: primary=00, secondary=56, subordinate=56, sec-latency=0
>> > I/O behind bridge: [disabled]
>> > Memory behind bridge: 8c300000-8c3fffff [size=1M]
>> > Prefetchable memory behind bridge: [disabled]
>> > Capabilities: [40] Express Root Port (Slot+), MSI 00
>> > Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
>> > Capabilities: [90] Subsystem: Dell Device 0991
>> > Capabilities: [a0] Power Management version 3
>> > Capabilities: [100] Advanced Error Reporting
>> > Capabilities: [220] Access Control Services
>> > Capabilities: [150] Precision Time Measurement
>> > Capabilities: [200] L1 PM Substates
>> > Capabilities: [a00] Downstream Port Containment
>> > Kernel driver in use: pcieport
>>
>> I don't know enough about PCI to say if the bridge is a problem or not.
>
> I don't think the bridge is an issue here. AFAICT the bridge's I/O
> and prefetchable memory windows are disabled, but the non-prefetchable
> window *is* enabled and contains the space consumed by the ath11k
> device:
>
> 00:1c.0 PCI bridge: Intel Corporation Device a0b8 (rev 20)
> Bus: primary=00, secondary=56, subordinate=56, sec-latency=0
> Memory behind bridge: 8c300000-8c3fffff [size=1M]
> 56:00.0 Network controller: Qualcomm Device 1101 (rev 01)
> Region 0: Memory at 8c300000 (64-bit, non-prefetchable) [size=1M]
Good to know that the bridge shouldn't be the problem. Do you have any
ideas how to make more vectors available to ath11k, besides
CONFIG_IRQ_REMAP? Because QCA6390 works in Windows I doubt this is a
hardware problem.
>> To summarise: Thomas is reporting[1] a problem with ath11k on QCA6390
>> PCI device where he is not having enough MSI vectors. ath11k needs 32
>> vectors but pci_alloc_irq_vectors() returns -ENOSPC. PCI support is new
>> for ath11k and introduced in v5.10-rc1. The irq allocation code is in
>> drivers/net/wireless/ath/ath11k/pci.c. [2]
>
> This code is needlessly complicated. If you absolutely need
> msi_config.total_vectors and can't settle for any less, you can do
> this:
>
> num_vectors = pci_alloc_irq_vectors(ab_pci->pdev,
> msi_config.total_vectors,
> msi_config.total_vectors,
> PCI_IRQ_MSI);
>
> if (num_vectors < 0) {
> ath11k_err(ab, "failed to get %d MSI vectors (%d)\n",
> msi_config.total_vectors, num_vectors);
> return num_vectors;
> }
True, this should be cleaned up. But of course this won't solve the
actual problem.
> But it seems a little greedy if the device can't operate at all unless
> it gets 32 vectors. Are you sure that's a hard requirement? Most
> devices can work with fewer vectors, even if it reduces performance.
This was my first reaction as well when I saw the code for the first
time. And the reply I got is that the firmware needs all 32 vectors, it
won't work with less.
>> I would first try with a full distro kernel config, just in case there's
>> some another important kernel config missing.
>>
>> [1] http://lists.infradead.org/pipermail/ath11k/2020-October/000466.html
>
> Tangent: have you considered getting this list archived on
> https://lore.kernel.org/lists.html?
Good point, actually I have not. I'll add both ath10k and ath11k lists
to lore. It's even more important now that lists.infradead.org had a
hard drive crash and lost years of archives.
Thanks for the help!
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
--
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k
WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@codeaurora.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Govind Singh <govinds@codeaurora.org>,
linux-pci@vger.kernel.org, linux-wireless@vger.kernel.org,
Devin Bayer <dev@doubly.so>,
Thomas Krause <thomaskrause@posteo.de>,
ath11k@lists.infradead.org
Subject: Re: pci_alloc_irq_vectors fails ENOSPC for XPS 13 9310
Date: Tue, 03 Nov 2020 08:49:06 +0200 [thread overview]
Message-ID: <87k0v3szod.fsf@codeaurora.org> (raw)
In-Reply-To: <20201102205752.GA34153@bjorn-Precision-5520> (Bjorn Helgaas's message of "Mon, 2 Nov 2020 14:57:52 -0600")
Bjorn Helgaas <helgaas@kernel.org> writes:
> [+cc Govind, author of 5697a564d369 ("ath11k: pci: add MSI config
> initialisation")]
>
> On Mon, Nov 02, 2020 at 08:49:51PM +0200, Kalle Valo wrote:
>> + linux-wireless, linux-pci, devin
>>
>> Thomas Krause <thomaskrause@posteo.de> writes:
>>
>> >> I had the same problem as well back in the days, for me enabling
>> >> CONFIG_IRQ_REMAP helped. If it helps for you also I wonder if we should
>> >> mention that in the ath11k warning above :)
>> >
>> > CONFIG_IRQ_REMAP did not do the trick. I noticed that the Wi-Fi card
>> > is behind a PCI bridge which is also disabled, could this be a
>> > problem?
>> >
>> > 00:1c.0 PCI bridge: Intel Corporation Device a0b8 (rev 20) (prog-if 00
>> > [Normal decode])
>> > Flags: bus master, fast devsel, latency 0, IRQ 123
>> > Bus: primary=00, secondary=56, subordinate=56, sec-latency=0
>> > I/O behind bridge: [disabled]
>> > Memory behind bridge: 8c300000-8c3fffff [size=1M]
>> > Prefetchable memory behind bridge: [disabled]
>> > Capabilities: [40] Express Root Port (Slot+), MSI 00
>> > Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
>> > Capabilities: [90] Subsystem: Dell Device 0991
>> > Capabilities: [a0] Power Management version 3
>> > Capabilities: [100] Advanced Error Reporting
>> > Capabilities: [220] Access Control Services
>> > Capabilities: [150] Precision Time Measurement
>> > Capabilities: [200] L1 PM Substates
>> > Capabilities: [a00] Downstream Port Containment
>> > Kernel driver in use: pcieport
>>
>> I don't know enough about PCI to say if the bridge is a problem or not.
>
> I don't think the bridge is an issue here. AFAICT the bridge's I/O
> and prefetchable memory windows are disabled, but the non-prefetchable
> window *is* enabled and contains the space consumed by the ath11k
> device:
>
> 00:1c.0 PCI bridge: Intel Corporation Device a0b8 (rev 20)
> Bus: primary=00, secondary=56, subordinate=56, sec-latency=0
> Memory behind bridge: 8c300000-8c3fffff [size=1M]
> 56:00.0 Network controller: Qualcomm Device 1101 (rev 01)
> Region 0: Memory at 8c300000 (64-bit, non-prefetchable) [size=1M]
Good to know that the bridge shouldn't be the problem. Do you have any
ideas how to make more vectors available to ath11k, besides
CONFIG_IRQ_REMAP? Because QCA6390 works in Windows I doubt this is a
hardware problem.
>> To summarise: Thomas is reporting[1] a problem with ath11k on QCA6390
>> PCI device where he is not having enough MSI vectors. ath11k needs 32
>> vectors but pci_alloc_irq_vectors() returns -ENOSPC. PCI support is new
>> for ath11k and introduced in v5.10-rc1. The irq allocation code is in
>> drivers/net/wireless/ath/ath11k/pci.c. [2]
>
> This code is needlessly complicated. If you absolutely need
> msi_config.total_vectors and can't settle for any less, you can do
> this:
>
> num_vectors = pci_alloc_irq_vectors(ab_pci->pdev,
> msi_config.total_vectors,
> msi_config.total_vectors,
> PCI_IRQ_MSI);
>
> if (num_vectors < 0) {
> ath11k_err(ab, "failed to get %d MSI vectors (%d)\n",
> msi_config.total_vectors, num_vectors);
> return num_vectors;
> }
True, this should be cleaned up. But of course this won't solve the
actual problem.
> But it seems a little greedy if the device can't operate at all unless
> it gets 32 vectors. Are you sure that's a hard requirement? Most
> devices can work with fewer vectors, even if it reduces performance.
This was my first reaction as well when I saw the code for the first
time. And the reply I got is that the firmware needs all 32 vectors, it
won't work with less.
>> I would first try with a full distro kernel config, just in case there's
>> some another important kernel config missing.
>>
>> [1] http://lists.infradead.org/pipermail/ath11k/2020-October/000466.html
>
> Tangent: have you considered getting this list archived on
> https://lore.kernel.org/lists.html?
Good point, actually I have not. I'll add both ath10k and ath11k lists
to lore. It's even more important now that lists.infradead.org had a
hard drive crash and lost years of archives.
Thanks for the help!
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2020-11-03 13:28 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-17 11:01 pci_alloc_irq_vectors fails ENOSPC for XPS 13 9310 Thomas Krause
2020-10-19 8:09 ` Kalle Valo
2020-10-20 20:46 ` Thomas Krause
2020-11-02 18:34 ` Kalle Valo
2020-11-02 18:49 ` Kalle Valo
2020-11-02 18:49 ` Kalle Valo
2020-11-02 20:57 ` Bjorn Helgaas
2020-11-02 20:57 ` Bjorn Helgaas
2020-11-03 3:01 ` Carl Huang
2020-11-03 3:01 ` Carl Huang
2020-11-03 6:49 ` Kalle Valo [this message]
2020-11-03 6:49 ` Kalle Valo
2020-11-03 16:08 ` Bjorn Helgaas
2020-11-03 16:08 ` Bjorn Helgaas
2020-11-03 21:08 ` Thomas Gleixner
2020-11-03 21:08 ` Thomas Gleixner
2020-11-03 22:42 ` Thomas Gleixner
2020-11-03 22:42 ` Thomas Gleixner
2020-11-09 18:44 ` Kalle Valo
2020-11-09 18:44 ` Kalle Valo
2020-11-04 13:04 ` Thomas Krause
2020-11-04 13:04 ` Thomas Krause
2020-11-04 15:26 ` Thomas Gleixner
2020-11-04 15:26 ` Thomas Gleixner
2020-11-05 13:23 ` Kalle Valo
2020-11-05 13:23 ` Kalle Valo
2020-11-06 11:57 ` Stefani Seibold
2020-11-10 8:33 ` Kalle Valo
2020-11-10 8:33 ` Kalle Valo
2020-11-11 8:53 ` Thomas Krause
2020-11-11 8:53 ` Thomas Krause
2020-11-11 9:22 ` Kalle Valo
2020-11-11 9:22 ` Kalle Valo
2020-11-11 19:10 ` Kalle Valo
2020-11-11 19:10 ` Kalle Valo
2020-11-11 19:24 ` wi nk
2020-11-11 19:24 ` wi nk
2020-11-11 19:30 ` wi nk
2020-11-11 19:30 ` wi nk
2020-11-11 19:45 ` Kalle Valo
2020-11-11 19:45 ` Kalle Valo
2020-11-11 20:12 ` wi nk
2020-11-11 20:12 ` wi nk
2020-11-11 21:35 ` Stefani Seibold
2020-11-11 21:35 ` Stefani Seibold
2020-11-11 22:02 ` Stefani Seibold
2020-11-11 22:02 ` Stefani Seibold
2020-11-12 0:24 ` wi nk
2020-11-12 0:24 ` wi nk
2020-11-12 1:10 ` wi nk
2020-11-12 1:10 ` wi nk
2020-11-12 1:11 ` wi nk
2020-11-12 1:11 ` wi nk
2020-11-12 2:31 ` wi nk
2020-11-12 2:31 ` wi nk
2020-11-12 6:29 ` Carl Huang
2020-11-12 6:29 ` Carl Huang
2020-11-12 7:05 ` Stefani Seibold
2020-11-12 7:05 ` Stefani Seibold
2020-11-12 7:15 ` Kalle Valo
2020-11-12 7:15 ` Kalle Valo
2020-11-12 7:41 ` wi nk
2020-11-12 7:41 ` wi nk
2020-11-12 8:59 ` Kalle Valo
2020-11-12 8:59 ` Kalle Valo
2020-11-12 15:44 ` wi nk
2020-11-12 15:44 ` wi nk
2020-11-13 9:52 ` wi nk
2020-11-13 9:52 ` wi nk
2020-11-15 13:30 ` Thomas Krause
2020-11-15 13:30 ` Thomas Krause
2020-11-15 19:55 ` wi nk
2020-11-15 19:55 ` wi nk
2020-11-17 15:49 ` wi nk
2020-11-17 15:49 ` wi nk
2020-11-17 20:59 ` Thomas Gleixner
2020-11-17 20:59 ` Thomas Gleixner
2020-11-18 10:22 ` wi nk
2020-11-18 10:22 ` wi nk
2020-11-11 9:39 ` Thomas Gleixner
2020-11-11 9:39 ` Thomas Gleixner
2020-11-06 11:45 ` Devin Bayer
2020-11-06 11:45 ` Devin Bayer
2020-11-09 18:48 ` Kalle Valo
2020-11-09 18:48 ` Kalle Valo
2020-11-03 11:20 ` Devin Bayer
2020-11-03 11:20 ` Devin Bayer
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=87k0v3szod.fsf@codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=ath11k@lists.infradead.org \
--cc=dev@doubly.so \
--cc=govinds@codeaurora.org \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=thomaskrause@posteo.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.