linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Bjorn Helgaas <helgaas@kernel.org>, Kalle Valo <kvalo@codeaurora.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, Christoph Hellwig <hch@lst.de>
Subject: Re: pci_alloc_irq_vectors fails ENOSPC for XPS 13 9310
Date: Tue, 03 Nov 2020 22:08:49 +0100	[thread overview]
Message-ID: <874km61732.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20201103160838.GA246433@bjorn-Precision-5520>

On Tue, Nov 03 2020 at 10:08, Bjorn Helgaas wrote:
> On Tue, Nov 03, 2020 at 08:49:06AM +0200, Kalle Valo wrote:
>> Bjorn Helgaas <helgaas@kernel.org> writes:
>> > On Mon, Nov 02, 2020 at 08:49:51PM +0200, Kalle Valo wrote:
>> >> 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 :)

Interrupt remapping only helps when the device supports only MSI (not
MSI-X) because x86 (kernel) does not support multiple MSI interrupts
without remapping.

So if only MSI is available then you get exactly _one_ MSI vector
without remapping.

>> >> > CONFIG_IRQ_REMAP did not do the trick.

The config alone does not help. The hardware has to support it and the
BIOS has to enable it.

Check the BIOS for a switch which is named 'VT-d' or such. It might
depend on 'Intel Virtualization Technology' or such.

>> >   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]

So I grabbed the PCI info from the link and it has:

     Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit-

So no MSI-X, ergo only one MSI interrupt without remapping.
 
>> >> 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]
>
>> > 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.

Right, even most high end network cards work with one interrupt.

>> 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.

Great design.

> I do see a couple other drivers that are completely inflexible (they
> request min==max).  But I don't know the system constraint you're
> hitting.  CC'd Thomas & Christoph in case they have time to give us a
> hint.

Can I have a full dmesg please?

Please enable CONFIG_IRQ_REMAP and CONFIG_INTEL_IOMMU (not strictly
required, but it's a Dell BIOS after all). Also set
CONFIG_INTEL_IOMMU_DEFAULT_ON.

Or simply try a distro kernel.

Thanks,

        tglx

  reply	other threads:[~2020-11-03 21:19 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2849fd39-a7a6-8366-7c78-fc9fec4dffa4@posteo.de>
     [not found] ` <87tuuqhc1i.fsf@codeaurora.org>
     [not found]   ` <1ce6f735-21ff-db7e-c8dc-d567761964aa@posteo.de>
2020-11-02 18:49     ` pci_alloc_irq_vectors fails ENOSPC for XPS 13 9310 Kalle Valo
2020-11-02 20:57       ` Bjorn Helgaas
2020-11-03  3:01         ` Carl Huang
2020-11-03  6:49         ` Kalle Valo
2020-11-03 16:08           ` Bjorn Helgaas
2020-11-03 21:08             ` Thomas Gleixner [this message]
2020-11-03 22:42               ` Thomas Gleixner
2020-11-09 18:44                 ` Kalle Valo
     [not found]               ` <fa26ac8b-ed48-7ea3-c21b-b133532716b8@posteo.de>
2020-11-04 15:26                 ` Thomas Gleixner
2020-11-05 13:23                   ` Kalle Valo
2020-11-10  8:33                     ` Kalle Valo
2020-11-11  8:53                       ` Thomas Krause
2020-11-11  9:22                         ` Kalle Valo
2020-11-11 19:10                           ` Kalle Valo
2020-11-11 19:24                             ` wi nk
2020-11-11 19:30                               ` wi nk
2020-11-11 19:45                                 ` Kalle Valo
2020-11-11 20:12                                   ` wi nk
2020-11-11 21:35                             ` Stefani Seibold
2020-11-11 22:02                             ` Stefani Seibold
2020-11-12  0:24                               ` wi nk
2020-11-12  1:10                                 ` wi nk
2020-11-12  1:11                                   ` wi nk
2020-11-12  2:31                                     ` wi nk
2020-11-12  6:29                                       ` Carl Huang
2020-11-12  7:05                                   ` Stefani Seibold
2020-11-12  7:15                                     ` Kalle Valo
2020-11-12  7:41                                       ` wi nk
2020-11-12  8:59                                         ` Kalle Valo
2020-11-12 15:44                                           ` wi nk
2020-11-13  9:52                                             ` wi nk
2020-11-15 13:30                                             ` Thomas Krause
2020-11-15 19:55                                               ` wi nk
2020-11-17 15:49                                                 ` wi nk
2020-11-17 20:59                                                   ` Thomas Gleixner
2020-11-18 10:22                                                     ` wi nk
2020-11-11  9:39                         ` Thomas Gleixner
2020-11-06 11:45               ` Devin Bayer
2020-11-09 18:48             ` Kalle Valo
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=874km61732.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=ath11k@lists.infradead.org \
    --cc=dev@doubly.so \
    --cc=govinds@codeaurora.org \
    --cc=hch@lst.de \
    --cc=helgaas@kernel.org \
    --cc=kvalo@codeaurora.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 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).