Bug 167491 - [ath] TID != hardware queue TID in ath_tx_aggr_comp_aggr()
Summary: [ath] TID != hardware queue TID in ath_tx_aggr_comp_aggr()
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: 10.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-01 16:50 UTC by Adrian Chadd
Modified: 2018-05-28 19:45 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Chadd freebsd_committer 2012-05-01 16:50:09 UTC
After the recent net80211 TX aggregation state handling changes (changing from per-AC to per-TID), I've begun seeing these messages pop up in the log:


ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 9
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 9
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 9
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 9
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 9
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 9
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 9
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 9
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 9
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 4
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 4
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 4
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 4
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 4
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 4
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 4
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 4
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 4
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 13
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 13
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 13
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 13
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 13
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 13
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 13
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 13
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 13
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 13
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 8
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 8
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 8
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 8
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 8
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 8
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 8
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 8
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 8
ath0: ath_tx_aggr_comp_aggr: tid 0 != hw tid 8

The code came over from Linux/atheros with this comment:

        /* Occasionally, the MAC sends a tx status for the wrong TID. */

However, I don't recall seeing this problem whilst the TX aggregation state was being kept per-AC, rather than per-TID.

Fix: 

None yet.
How-To-Repeat: Enable ath(4) 802.11n, use as hostap, do a whole lot of aggregate traffic.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2012-05-01 17:08:43 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-wireless

Over to maintainer(s).
Comment 2 alexander.kuehn 2012-09-08 10:42:47 UTC
I see the same on x86 along with:

messages.4.bz2:Sep  2 17:04:29 cakebox kernel: ath0: stuck beacon;  
resetting (bmiss count 4)
messages.4.bz2:Sep  2 17:04:33 cakebox kernel: ath0: stuck beacon;  
resetting (bmiss count 4)
messages.4.bz2:Sep  2 17:04:33 cakebox kernel: ath0: ath_start:  
sc_inreset_cnt > 0; bailing
messages.4.bz2:Sep  2 17:05:12 cakebox kernel: ath0: ath_tx_tid_drain:  
node 0xc47ea000: bf=0xc350fcc0: addbaw=0, dobaw=0, seqno=0, retry=0
messages.4.bz2:Sep  2 17:05:12 cakebox kernel: ath0: ath_tx_tid_drain:  
node 0xc47ea000: bf=0xc350fcc0: tid txq_depth=1 hwq_depth=0, bar_wait=0
messages.4.bz2:Sep  2 17:05:12 cakebox kernel: ath0: ath_tx_tid_drain:  
node 0xc47ea000: tid 16: txq_depth=64, txq_aggr_depth=0, sched=0,  
paused=0, hwq_depth=0, incomp=0, baw_head=0, baw_tail=0 txa_start=-1,  
ni_txseqs=7
messages.4.bz2:Sep  2 17:06:25 cakebox kernel: ath0: stuck beacon;  
resetting (bmiss count 4)

Unfortunately this causes the transfer rates to drop and occasionally  
even makes it impossible to associate with the AP.

dmesg:
Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
         The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #0: Wed Aug 29 13:01:13 CEST 2012
     root@cakebox.tis:/usr/obj/export/src/sys/net5501 i386
CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU)
   Origin = "AuthenticAMD"  Id = 0x5a2  Family = 5  Model = a  Stepping = 2
   Features=0x88a93d<FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CLFLUSH,MMX>
   AMD Features=0xc0400000<MMX+,3DNow!+,3DNow!>
real memory  = 536870912 (512 MB)
avail memory = 515837952 (491 MB)
K6-family MTRR support enabled (2 registers)
cryptosoft0: <software crypto> on motherboard
pcib0 pcibus 0 on motherboard
pci0: <PCI bus> on pcib0
Geode LX: Soekris net5501 comBIOS ver. 1.33 20070103 Copyright (C) 2000-2007
glxsb0: <AMD Geode LX Security Block (AES-128-CBC, RNG)> mem  
0xa0000000-0xa0003fff irq 10 at device 1.2 on pci0
vr0: <VIA VT6105M Rhine III 10/100BaseTX> port 0xe100-0xe1ff mem  
0xa0004000-0xa00040ff irq 11 at device 6.0 on pci0
vr0: Quirks: 0x2
vr0: Revision: 0x96
miibus0: <MII bus> on vr0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
vr0: Ethernet address: 00:00:24:cb:a6:80
vr1: <VIA VT6105M Rhine III 10/100BaseTX> port 0xe200-0xe2ff mem  
0xa0004100-0xa00041ff irq 5 at device 7.0 on pci0
vr1: Quirks: 0x2
vr1: Revision: 0x96
miibus1: <MII bus> on vr1
ukphy1: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
ukphy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
vr1: Ethernet address: 00:00:24:cb:a6:81
vr2: <VIA VT6105M Rhine III 10/100BaseTX> port 0xe300-0xe3ff mem  
0xa0004200-0xa00042ff irq 9 at device 8.0 on pci0
vr2: Quirks: 0x2
vr2: Revision: 0x96
miibus2: <MII bus> on vr2
ukphy2: <Generic IEEE 802.3u media interface> PHY 1 on miibus2
ukphy2:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
vr2: Ethernet address: 00:00:24:cb:a6:82
vr3: <VIA VT6105M Rhine III 10/100BaseTX> port 0xe400-0xe4ff mem  
0xa0004300-0xa00043ff irq 12 at device 9.0 on pci0
vr3: Quirks: 0x2
vr3: Revision: 0x96
miibus3: <MII bus> on vr3
ukphy3: <Generic IEEE 802.3u media interface> PHY 1 on miibus3
ukphy3:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
vr3: Ethernet address: 00:00:24:cb:a6:83
ath0: <Atheros 5416> mem 0xa0010000-0xa001ffff irq 10 at device 14.0 on pci0
ath0: DMA setup: legacy
ath0: [HT] enabling HT modes
ath0: [HT] RTS aggregates limited to 8 KiB
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR5416 mac 13.10 RF2133 phy 8.1
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00d0
isab0: <PCI-ISA bridge> at device 20.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <AMD CS5536 UDMA100 controller> port  
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 20.2 on pci0
ata0: <ATA channel> at channel 0 on atapci0
ata1: <ATA channel> at channel 1 on atapci0
ohci0: <OHCI (generic) USB controller> mem 0xa0020000-0xa0020fff irq  
15 at device 21.0 on pci0
usbus0 on ohci0
ehci0: <AMD CS5536 (Geode) USB 2.0 controller> mem  
0xa0021000-0xa0021fff irq 15 at device 21.1 on pci0
usbus1: EHCI version 1.0
usbus1 on ehci0
cpu0 on motherboard
orm0: <ISA Option ROM> at iomem 0xc8000-0xd27ff pnpid ORM0000 on isa0
atrtc0: <AT realtime clock> at port 0x70 irq 8 on isa0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0: <AT timer> at port 0x40 on isa0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
uart0: console (19200,n,8,1)
uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0
Timecounters tick every 1.000 msec
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 480Mbps High Speed USB v2.0
ugen0.1: <AMD> at usbus0
uhub0: <AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ugen1.1: <AMD> at usbus1
uhub1: <AMD EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
ad0: 152627MB <SAMSUNG HM160HC LQ100-10> at ata0-master UDMA100
GEOM_SCHED: Initializing global data.
GEOM_SCHED: Loading: mp = 0xc0a9aa20, g_sched_class = 0xc0a9aa20.
Timecounter "TSC" frequency 499912531 Hz quality 800
uhub0: 4 ports with 4 removable, self powered
Root mount waiting for: usbus1
uhub1: 4 ports with 4 removable, self powered
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:45:46 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.