Kalle, Thanks so much for your and your teams efforts. I've applied the patch, and I'm receiving some errors similar to what you thought might occur: [ 7.802756] ath11k_pci 0000:55:00.0: WARNING: ath11k PCI support is experimental! [ 7.802797] ath11k_pci 0000:55:00.0: BAR 0: assigned [mem 0x8e300000-0x8e3fffff 64bit] [ 7.802815] ath11k_pci 0000:55:00.0: enabling device (0000 -> 0002) [ 7.803291] ath11k_pci 0000:55:00.0: MSI vectors: 1 [ 8.172623] ath11k_pci 0000:55:00.0: Respond mem req failed, result: 1, err: 48 [ 8.172624] ath11k_pci 0000:55:00.0: qmi failed to respond fw mem req:-22 I've reverted the commit you mentioned and am rebuilding now. I'll test in a few minutes. Thanks! On Wed, Nov 11, 2020 at 8:10 PM Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote: > > Kalle Valo <kvalo@xxxxxxxxxxxxxx> writes: > > > Thomas Krause <thomaskrause@xxxxxxxxx> writes: > > > >> Am 10.11.20 um 09:33 schrieb Kalle Valo: > >>> > >>>> I was told that on Dell XPS 15 (with a working QCA6390 setup) there's a > >>>> separate "Virtualisation" setting in BIOS. See if you have that and try > >>>> enabling it. > >>> I was informed about another setting to test: try disabling "Enable > >>> Secure Boot" in the BIOS. I don't know yet why it would help, but that's > >>> what few people have recommended. > >>> > >>> Please let me know how it goes. > >>> > >> I have two options under "Virtualization" in the BIOS: "Enable Intel > >> Virtualization Technology (VT)" and "VT for Direct I/O". Both were > >> enabled. Secure boot was also turned off. BIOS version is also at the > >> most current version 1.1.1. > > > > This is good to know, thanks for testing. Now we have explored all > > possible BIOS options as I know of. > > > >> Because of the dmesg errors Thomas Gleixner mentioned, I assume it > >> would be best to contact Dell directly (even if I'm not sure if and > >> how fast they will respond). > > > > I have asked our people to report this to Dell, but no response yet. > > > >> If the driver would manage to work with only 1 vector, I assume this > >> would also make it work on my configuration, even with possible > >> performance hits. > > > > This is the workaround we are working on at the moment. There's now a > > proof of concept patch but I'm not certain if it will work. I'll post it > > as soon as I can and will provide the link in this thread. > > The proof of concept patch for v5.10-rc2 is here: > > https://patchwork.kernel.org/project/linux-wireless/patch/1605121102-14352-1-git-send-email-kvalo@xxxxxxxxxxxxxx/ > > Hopefully it makes it possible to boot the firmware now. But this is a > quick hack and most likely buggy, so keep your expectations low :) > > In case there are these warnings during firmware initialisation: > > ath11k_pci 0000:05:00.0: qmi failed memory request, err = -110 > ath11k_pci 0000:05:00.0: qmi failed to respond fw mem req:-110 > > Try reverting this commit: > > 7fef431be9c9 mm/page_alloc: place pages to tail in __free_pages_core() > > That's another issue which is debugged here: > > http://lists.infradead.org/pipermail/ath11k/2020-November/000550.html > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
