htt rx stopped. cannot recover

[Michal Kazior]

On 13 November 2014 20:09, Pushpal Sidhu <psidhu at gateworks.com> wrote:
> On Tue, Nov 11, 2014 at 10:31 PM, Michal Kazior <michal.kazior at tieto.com> 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
vdev.

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
ath10k.

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.


Michał