htt rx stopped. cannot recover

Michal Kazior michal.kazior at
Fri Nov 14 00:31:51 PST 2014

On 13 November 2014 20:09, Pushpal Sidhu <psidhu at> wrote:
> On Tue, Nov 11, 2014 at 10:31 PM, Michal Kazior <michal.kazior at> wrote:
> Has anyone else been able to recreate this problem? If not, there
> might be something else at play, but until someone else can recreate
> the issue, I can't tell exactly where the problem lies. At first I
> thought it was a 4addr mode issue, but I performed the following
> scenario and believe that it might be related to bridging.
>  {lan1}<--ether-->AP<--wifi-->STA
> In this scenario, the AP bridges eth+wlan, with 4addr turned off (the
> STA has no bridge). When I pass traffic through from lan1 to the
> STAtion, the same issue occurs on the AP, this time with traffic above
> ~220mbps TCP. Does anyone know of any specific kernel configs relating
> to bridging that I might not have enabled?

I've used ath10k AP in a bridge many times and haven't seen this issue yet.

Putting an interface into a bridge enables promiscuous mode on it. In
ath10k this is handled by creating a monitor vdev to implicitly
influence Rx filters so that hw/fw pass everything up to host. I
suspect your RF environment may contain particular traffic patterns
which trigger the problem within firmware code related to monitor

You could try hacking up ath10k to not create/start monitor vdev and
see if you can still reproduce the problem. Keep in mind bridging will
be crippled in some cases since firmware won't deliver some frames to

There's also new WMI_10X_PDEV_PARAM_RX_FILTER that was introduced in
10.2. I didn't have time to play with it yet. In theory it might be
able possible to use it instead of monitor vdev for promisc mode, at
least with 10.2. I'm not really fond of the idea though because this
will add more complexity and different codepaths to the driver
depending on firmware revision.

> I understand that stopping traffic is a safety mechanism, but is there
> a better way to handle the situation? I don't believe resetting
> hardware is the proper solution as this requires reauthentication
> (which takes time), only for the problem to remanifest itself in only
> a few seconds of passing traffic through.

Hmm.. Now that I think about it, after the recent Rx rework it might
be possible to circumvent the problem. ath10k uses very little data
from Rx indication event and instead Rx descriptor is used for most
things. Popping function would need some changes so that it can back
off safely if a frame buffer isn't ready. ath10k would probably need
to poll for Rx too.


More information about the ath10k mailing list