# brcmsmac: bcma0:1: START: tid 2 is not agg'able

## engineermdr

My kern.log is huge and full of these messages after installing Gentoo on an old laptop, and it's logging messages at a rate of several per second.

```
Feb 22 20:11:04 vir kernel: [311497.582397] brcmsmac bcma0:1: START: tid 2 is not agg'able

Feb 22 20:11:04 vir kernel: [311497.594350] brcmsmac bcma0:1: START: tid 2 is not agg'able

Feb 22 20:11:04 vir kernel: [311497.991389] brcmsmac bcma0:1: START: tid 2 is not agg'able

Feb 22 20:11:04 vir kernel: [311497.999353] brcmsmac bcma0:1: START: tid 2 is not agg'able
```

A google search is not turning up much help as to what it means, just that this has been and issue for others for a long time.  Wireless is working fine as far as I can tell.  I found where the message is printed in the driver (/usr/src/linux-4.14.83-gentoo/drivers/net/wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c), but the surrounding code makes no sense to me. 

```
                spin_lock_bh(&wl->lock);

                status = brcms_c_aggregatable(wl->wlc, tid);

                spin_unlock_bh(&wl->lock);

                if (!status) {

                        brcms_err(wl->wlc->hw->d11core,

                                  "START: tid %d is not agg\'able\n", tid);

                        return -EINVAL;

                }

                ieee80211_start_tx_ba_cb_irqsafe(vif, sta->addr, tid);

                break;

```

I could edit the source to disable the message, but I'd rather understand if something's wrong before hiding the message.  Anyone know what this error means?

----------

## Hu

Looking at the surrounding source, I think this is triggered by some application trying to configure the device, the kernel rejecting that configuration, and the application ignoring the error and retrying after a short delay.  You could probably eliminate the message if you find the offending application and make it respect the first failure.  The request is not likely to start working after repeated retries.  The request is IEEE80211_AMPDU_TX_START.  Based on comments elsewhere in the kernel source, I think this is a feature for aggregating frames.  Your device is probably sending the frames without aggregation, which is not as good, but still works for your use.  This may cost more power or have other downsides, so if it can be corrected without changing hardware, it would likely be a good change to make.

You could try running a more current kernel in case newer kernels know how to enable aggregation on this device.  I don't know if the current device is marked as not-aggregatable because the hardware cannot support it or because the kernel you are using does not know how to enable it.  If the former, an upgrade will not help.  If the latter, an upgrade might help or might not.

----------

## ISHAIM

Hello,

I'm having this problem as well, and not wanting to comment out that line in /usr/src/linux-4.14.83-gentoo/drivers/net/wireless/broadcom/brcm80211/brcmsmac/mac80211_if.c as that seems hack-y.

An lspci -n and lspci -k may be helpful here. Mine's:

```
# lspci -n

07:00.0 0280: 14e4:4727 (rev 01)
```

```
# lspci -k

07:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4313 802.11bgn Wireless Network Adapter (rev 01)

   Subsystem: Foxconn International, Inc. BCM4313 802.11bgn Wireless Network Adapter

   Kernel driver in use: bcma-pci-bridge

   Kernel modules: bcma, wl
```

It seems not to matter whether I choose b43 or b43legacy in "menuconfig". In fact, menuconfig Shift+/ on either says an "underlying glue layer" will pick the right one, even if you enable both. Furthermore, I disabled both and was still able to have the device recognized and ssh in from another host.

Lastly, this "kernel message" seems to occur with *every-single-keypress* I make in a remote shell. It seems like Hu is saying, where it seems it's sending frames "without" aggregation-- just how to make this work? BCM4313 does seem to be a lower power device to me so if it's a "low-power" device then that it cannot "aggregate" frames makes sense, if in fact "aggregating frames" consumes more power.

This is a lot better situation than when I hacked in an Intel driver to get it working while dealing with rando kernel panics...   :Twisted Evil: 

Would be nice to have an alternative to hacking mac80211_if.c to avoid all the /var/log/messages spam... If I can even manage that... BCM4313 such a PITA   :Crying or Very sad: 

----------

