Re: pci_alloc_irq_vectors fails ENOSPC for XPS 13 9310

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Am 12.11.20 um 16:44 schrieb wi nk:
On Thu, Nov 12, 2020 at 10:00 AM Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote:
wi nk <wink@xxxxxxxxxxx> writes:

On Thu, Nov 12, 2020 at 8:15 AM Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote:
Stefani Seibold <stefani@xxxxxxxxxxx> writes:

Am Donnerstag, den 12.11.2020, 02:10 +0100 schrieb wi nk:
I've yet to see any instability after 45 minutes of exercising it, I
do see a couple of messages that came out of the driver:

[    8.963389] ath11k_pci 0000:55:00.0: Unknown eventid: 0x16005
[   11.342317] ath11k_pci 0000:55:00.0: Unknown eventid: 0x1d00a

then when it associates:

[   16.718895] wlp85s0: send auth to ec:08:6b:27:01:ea (try 1/3)
[   16.722636] wlp85s0: authenticated
[   16.724150] wlp85s0: associate with ec:08:6b:27:01:ea (try 1/3)
[   16.726486] wlp85s0: RX AssocResp from ec:08:6b:27:01:ea
(capab=0x411 status=0 aid=8)
[   16.738443] wlp85s0: associated
[   16.764966] IPv6: ADDRCONF(NETDEV_CHANGE): wlp85s0: link becomes
ready

The adapter is achieving around 500 mbps on my gigabit connection, my
2018 mbp sees around 650, so it's doing pretty well so far.

Stefani - when you applied the patch that Kalle shared, which branch
did you apply it to?  I applied it to ath11k-qca6390-bringup and when
I revert 7fef431be9c9 there is a small merge conflict I needed to
resolve.  I wonder if either the starting branch, or your chosen
resolution are related to the instability you see (or I'm just lucky
so far! :)).

I used the vanilla kernel tree
https://git.kernel.org/torvalds/t/linux-5.10-rc2.tar.gz. On top of this
i applied the

RFT-ath11k-pci-support-platforms-with-one-MSI-vector.patch

and reverted the patch 7fef431be9c9
I did also my testing on v5.10-rc2 and I recommend to use that as the
baseline when debuggin these ath11k problems. It helps to compare the
results if everyone have the same baseline.

--
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Absolutely, I'll rebuild to 5.10 later today and apply the same series
of patches and report back.
Great, thanks.

I'll also test out the patch on both versions from Carl to fix
resuming. It stands to reason that we may be seeing another regression
between Stefani (5.10) and myself (5.9 bringup branch) as I don't see
any disconnections or instability once the interface is online.
Yeah, there is something strange happening between v5.9 and v5.10 we
have not yet figured out. Most likely it has something to do with memory
allocations and DMA transfers failing, but no clear understanding yet.

But to keep things simple let's only discuss the MSI problem on this
thread, and discuss the timeouts in the another thread:

http://lists.infradead.org/pipermail/ath11k/2020-November/000641.html

I'll include you and other reporters to that thread.

--
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Ok, I've tried a clean checkout of 5.10-rc2 with the one MSI patch
applied and 7fef431be9c9 reverted.  I can't get my machine to  boot
into anything usable with that configuration.  I'm running ubuntu so
its starting right into X and sometime between showing the available
users and me clicking the icon to login the machine freezes.  I can
see in the system tray that the wifi adapter is being activated and
appears to have associated with an AP, I just can't do much beyond
that as the keyboard backlight wakes up, but the caps lock key doesn't
work.  I see similar behavior with the 5.9 configuration, but after a
reboot or two I win whatever race is occuring.  With 5.10, I tried
maybe 10-15 times with 0 success.

I can confirm this behavior on my configuration. I managed to login once and select the Wifi and connect to it. It seemed curiously enough be stable long enough to enter the Wifi passphrase. After the connection was established, the system hang and on each attempt to reboot into the graphical system it would freeze at some point (sometimes even before showing the login screen).

Kernel was both based on 5.10-rc2 and 5.10-rc3 (I did see the same behavior) with the patch applied, 7fef431be9c9 reverted and firmware downloaded and copied to /lib/firmware/ath11k/QCA6390/hw2.0/.






[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux