Re: [PATCH] ath10k: Clean the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE flag
On 11/24/2021 3:46 PM, Kalle Valo wrote:
Fabio Estevam writes:
Hi Kalle,
On Mon, Nov 15, 2021 at 3:06 PM Fabio Estevam wrote:
Hi Kalle,
On Wed, Sep 15, 2021 at 1:05 PM Fabio Estevam wrote:
On an imx6dl-pico-pi board with a QCA9377 SDIO chip, the following
errors are observed when the board works in STA mode:
Simply running "ssh user@192.168.0.1" causes:
[ 55.824159] ath10k_sdio mmc1:0001:1: failed to transmit packet, dropping: -12
[ 55.832169] ath10k_sdio mmc1:0001:1: failed to submit frame: -12
[ 55.838529] ath10k_sdio mmc1:0001:1: failed to push frame: -12
[ 55.905863] ath10k_sdio mmc1:0001:1: failed to transmit packet, dropping: -12
[ 55.913650] ath10k_sdio mmc1:0001:1: failed to submit frame: -12
[ 55.919887] ath10k_sdio mmc1:0001:1: failed to push frame: -12
and it is not possible to connect via ssh to the other machine.
One user inspected the size of frames on Wireshark and reported
the followig:
"I was able to narrow the issue down to the mtu. If I set the mtu for
the wlan0 device to 1486 instead of 1500, the issue does not happen.
The size of frames that I see on Wireshark is exactly 1500 after
setting it to 1486."
Clearing the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE avoids the problem and
the ssh command works successfully after that.
Tested with QCA9377 SDIO with firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1.
Fixes: 2f918ea98606 ("ath10k: enable alt data of TX path for sdio")
Signed-off-by: Fabio Estevam
A gentle ping on this one.
Any comments, please? Without this fix, we can not log via ssh to other machine.
I don't have much time for ath10k nowadays, so expect long delays in
reviews.
I'm worried that this breaks QCA6174 SDIO support. Wen, what do you
think of this? Is this because of differences between firmware versions
or what?
it is added by below commit, if disable it, will significant effect
performance.
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/drivers/net/wireless/ath/ath11k?id=2f918ea98606100f3a6d47db7ff7c200838ec4f3
ath10k: enable alt data of TX path for sdio
The default credit size is 1792 bytes, but the IP mtu is 1500 bytes,
then it has about 290 bytes's waste for each data packet on sdio
transfer path for TX bundle, it will reduce the transmission utilization
ratio for data packet.
This patch enable the small credit size in firmware, firmware will use
the new credit size 1556 bytes, it will increase the transmission
utilization ratio for data packet on TX patch. It results in significant
performance improvement on TX path.
This patch only effect sdio chip, it will not effect PCI, SNOC etc.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00017-QCARMSWP-1.
Signed-off-by: Wen Gong
Signed-off-by: Kalle Valo
Link: https://lore.kernel.org/r/20200410061400.14231-3-wg...@codeaurora.org
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: Clean the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE flag
Fabio Estevam writes:
> Hi Kalle,
>
> On Mon, Nov 15, 2021 at 3:06 PM Fabio Estevam wrote:
>>
>> Hi Kalle,
>>
>> On Wed, Sep 15, 2021 at 1:05 PM Fabio Estevam wrote:
>> >
>> > On an imx6dl-pico-pi board with a QCA9377 SDIO chip, the following
>> > errors are observed when the board works in STA mode:
>> >
>> > Simply running "ssh user@192.168.0.1" causes:
>> >
>> > [ 55.824159] ath10k_sdio mmc1:0001:1: failed to transmit packet,
>> > dropping: -12
>> > [ 55.832169] ath10k_sdio mmc1:0001:1: failed to submit frame: -12
>> > [ 55.838529] ath10k_sdio mmc1:0001:1: failed to push frame: -12
>> > [ 55.905863] ath10k_sdio mmc1:0001:1: failed to transmit packet,
>> > dropping: -12
>> > [ 55.913650] ath10k_sdio mmc1:0001:1: failed to submit frame: -12
>> > [ 55.919887] ath10k_sdio mmc1:0001:1: failed to push frame: -12
>> >
>> > and it is not possible to connect via ssh to the other machine.
>> >
>> > One user inspected the size of frames on Wireshark and reported
>> > the followig:
>> >
>> > "I was able to narrow the issue down to the mtu. If I set the mtu for
>> > the wlan0 device to 1486 instead of 1500, the issue does not happen.
>> >
>> > The size of frames that I see on Wireshark is exactly 1500 after
>> > setting it to 1486."
>> >
>> > Clearing the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE avoids the problem and
>> > the ssh command works successfully after that.
>> >
>> > Tested with QCA9377 SDIO with firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1.
>> >
>> > Fixes: 2f918ea98606 ("ath10k: enable alt data of TX path for sdio")
>> > Signed-off-by: Fabio Estevam
>>
>> A gentle ping on this one.
>
> Any comments, please? Without this fix, we can not log via ssh to other
> machine.
I don't have much time for ath10k nowadays, so expect long delays in
reviews.
I'm worried that this breaks QCA6174 SDIO support. Wen, what do you
think of this? Is this because of differences between firmware versions
or what?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: Clean the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE flag
Hi Kalle,
On Mon, Nov 15, 2021 at 3:06 PM Fabio Estevam wrote:
>
> Hi Kalle,
>
> On Wed, Sep 15, 2021 at 1:05 PM Fabio Estevam wrote:
> >
> > On an imx6dl-pico-pi board with a QCA9377 SDIO chip, the following
> > errors are observed when the board works in STA mode:
> >
> > Simply running "ssh user@192.168.0.1" causes:
> >
> > [ 55.824159] ath10k_sdio mmc1:0001:1: failed to transmit packet,
> > dropping: -12
> > [ 55.832169] ath10k_sdio mmc1:0001:1: failed to submit frame: -12
> > [ 55.838529] ath10k_sdio mmc1:0001:1: failed to push frame: -12
> > [ 55.905863] ath10k_sdio mmc1:0001:1: failed to transmit packet,
> > dropping: -12
> > [ 55.913650] ath10k_sdio mmc1:0001:1: failed to submit frame: -12
> > [ 55.919887] ath10k_sdio mmc1:0001:1: failed to push frame: -12
> >
> > and it is not possible to connect via ssh to the other machine.
> >
> > One user inspected the size of frames on Wireshark and reported
> > the followig:
> >
> > "I was able to narrow the issue down to the mtu. If I set the mtu for
> > the wlan0 device to 1486 instead of 1500, the issue does not happen.
> >
> > The size of frames that I see on Wireshark is exactly 1500 after
> > setting it to 1486."
> >
> > Clearing the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE avoids the problem and
> > the ssh command works successfully after that.
> >
> > Tested with QCA9377 SDIO with firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1.
> >
> > Fixes: 2f918ea98606 ("ath10k: enable alt data of TX path for sdio")
> > Signed-off-by: Fabio Estevam
>
> A gentle ping on this one.
Any comments, please? Without this fix, we can not log via ssh to other machine.
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
[kvalo-ath:master-pending] BUILD SUCCESS 593172ab9902dfa8c849912077f617d3a097c534
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git master-pending branch HEAD: 593172ab9902dfa8c849912077f617d3a097c534 Merge branch 'pending' into master-pending elapsed time: 1304m configs tested: 159 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig i386 randconfig-c001-20211122 arm omap2plus_defconfig arm axm55xx_defconfig arc haps_hs_defconfig arm aspeed_g5_defconfig powerpcamigaone_defconfig powerpc64 defconfig ia64generic_defconfig armmagician_defconfig sh ecovec24_defconfig nios2 3c120_defconfig sh microdev_defconfig mips capcella_defconfig h8300alldefconfig xtensasmp_lx200_defconfig m68k m5475evb_defconfig arc axs103_smp_defconfig arm pxa255-idp_defconfig arm collie_defconfig sh se7206_defconfig powerpcmvme5100_defconfig armoxnas_v6_defconfig shsh7757lcr_defconfig s390 alldefconfig powerpc canyonlands_defconfig ia64 gensparse_defconfig arm hackkit_defconfig openriscdefconfig sh r7785rp_defconfig ia64 tiger_defconfig sh se7343_defconfig mips db1xxx_defconfig powerpc mpc8560_ads_defconfig powerpc cm5200_defconfig arm sama7_defconfig arm spear13xx_defconfig mipsvocore2_defconfig armvt8500_v6_v7_defconfig mips rbtx49xx_defconfig powerpc mpc837x_rdb_defconfig armzeus_defconfig powerpc xes_mpc85xx_defconfig powerpc ep8248e_defconfig sh sdk7786_defconfig powerpc acadia_defconfig arm ezx_defconfig armhisi_defconfig m68km5272c3_defconfig powerpc mpc512x_defconfig sh se7722_defconfig arm corgi_defconfig ia64 bigsur_defconfig mips sb1250_swarm_defconfig arm randconfig-c002-20211122 arm randconfig-c002-20211123 ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig i386 allyesconfig i386defconfig i386 debian-10.3 sparcallyesconfig sparc defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a001-20211123 x86_64 randconfig-a003-20211123 x86_64 randconfig-a006-20211123 x86_64 randconfig-a004-20211123 x86_64 randconfig-a005-20211123 x86_64 randconfig-a002-20211123 i386 randconfig-a001-20211123 i386
Intermittent issues with Atheros QCA6174 on XPS 13 9380
I'm experiencing intermittent wifi issues with an Atheros QCA6174 on an XPS 13 9380 notebook. I started pinging my AP and noticed that ping times go from <10ms to >10,000ms when this happens. 64 bytes from 192.168.0.1: icmp_seq=1154 ttl=64 time=3.18 ms 64 bytes from 192.168.0.1: icmp_seq=1160 ttl=64 time=8572 ms 64 bytes from 192.168.0.1: icmp_seq=1161 ttl=64 time=7549 ms 64 bytes from 192.168.0.1: icmp_seq=1162 ttl=64 time=17518 ms 64 bytes from 192.168.0.1: icmp_seq=1163 ttl=64 time=16497 ms 64 bytes from 192.168.0.1: icmp_seq=1169 ttl=64 time=10412 ms There's also huge package loss. Various observations: * There's no warning in dmesg when this happens. * I'm only 1-2 meters from the AP and connection quality is good. Other devices connected to the same AP don't have problems. * rmmod & modprobe solves the issue, but only temporarily. * I tried to set a lower speed with "iwconfig wlp2s0 rate 11M" but that made no difference. * This is with 2.412 GHz. My AP doesn't have 5 GHz * The problem doesn't happen all the time. I haven't found a clear pattern yet. However, watching videos on YouTube usually (but not always) triggers it. (It also shows without YouTube, but YouTube is a good way to trigger it.) * When it happens, it happens every few minutes (without an obvious pattern). Sometimes it goes back to normal quickly (less than a minute) but sometimes it takes a long time and then I do 'rmmod'. * I've tried with different kernels: 5.15, 5.14, 5.10 (all from Debian) - all show this issue * I downloaded the latest firmware from https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0/4.4.1 (WLAN.RM.4.4.1-00288) This made no difference * The mainboard of my laptop was swapped about two weeks ago. I don't think I had this problem in the past (there were Internet issues from time to time, and I assumed it's the broadband; but maybe it was a wifi issue. It doesn't wasn't as bad as now though because I would have noticed. Now wifi is pretty much unusuable, at least for YouTube). The Atheros chip is the same brand, so not sure if the mainboard switch matters. (But it's weird because I didn't have the issues before.)I'm not sure about software changes in recent times but I can't think of anything too obvious. * I booted into Windows 10 and watched YouTube for two hours and didn't notice the same problem there. Is this a known issue? How can I provide more debugging info? Below is some more info about my system. I've also attached some ping logs. iwconfig Mode:Managed Frequency:2.412 GHz Access Point: ... Bit Rate=144.4 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr:off Fragment thr:off Power Management:on Link Quality=61/70 Signal level=-49 dBm dmesg when loading driver: ath10k_pci :02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 ath10k_pci :02:00.0: firmware: failed to load ath10k/pre-cal-pci-:02:00.0.bin (-2) ath10k_pci :02:00.0: firmware: failed to load ath10k/cal-pci-:02:00.0.bin (-2) ath10k_pci :02:00.0: firmware: direct-loading firmware ath10k/QCA6174/hw3.0/firmware-6.bin ath10k_pci :02:00.0: qca6174 hw3.2 target 0x0503 chip_id 0x00340aff sub 1a56:143a ath10k_pci :02:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0 ath10k_pci :02:00.0: firmware ver WLAN.RM.4.4.1-00288- api 6 features wowlan,ignore-otp,mfp crc32 bf907c7c ath10k_pci :02:00.0: firmware: direct-loading firmware ath10k/QCA6174/hw3.0/board-2.bin ath10k_pci :02:00.0: board_file api 2 bmi_id N/A crc32 e57aadc7 ath10k_pci :02:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1 ath: EEPROM regdomain: 0x6c ath: EEPROM indicates we should expect a direct regpair map ath: Country alpha2 being used: 00 ath: Regpair used: 0x6c ath10k_pci :02:00.0 wlp2s0: renamed from wlan0 lspci: 02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32) Subsystem: Rivet Networks Killer 1435 Wireless-AC Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- https://www.cyrius.com/ 64 bytes from 192.168.0.1: icmp_seq=1110 ttl=64 time=3.67 ms 64 bytes from 192.168.0.1: icmp_seq= ttl=64 time=4.44 ms 64 bytes from 192.168.0.1: icmp_seq=1112 ttl=64 time=3.15 ms 64 bytes from 192.168.0.1: icmp_seq=1113 ttl=64 time=7.35 ms 64 bytes from 192.168.0.1: icmp_seq=1115 ttl=64 time=4.04 ms 64 bytes from 192.168.0.1: icmp_seq=1116 ttl=64 time=5.71 ms 64 bytes from 192.168.0.1: icmp_seq=1117 ttl=64 time=6.77 ms 64 bytes from 192.168.0.1: icmp_seq=1118 ttl=64 time=12.9 ms 64 bytes from 192.168.0.1: icmp_seq=1119 ttl=64 time=3.41 ms 64 bytes from 192.168.0.1: icmp_seq=1120 ttl=64 time=4.20 ms 64 bytes from 192.168.0.1: icmp_seq=1121 ttl=64 time=4.60 ms 64 bytes
