htt rx stopped. cannot recover

Pushpal Sidhu psidhu at
Thu Nov 13 11:09:31 PST 2014

On Tue, Nov 11, 2014 at 10:31 PM, Michal Kazior <michal.kazior at> wrote:
> That's a safety mechanism to prevent memory corruption on the host.
> The error you see is most likely an indication fw/hw Rx reporting
> broke, i.e. fw says to pop more frames from the Rx ring than it is
> ready to be popped.

So if this seems to indicate a hw/fw issue, how should I go about
fixing it? If it's a fw issue, it just goes to show how keeping this
particular fw closed-source is hurting this project more than anything
in my opinion.

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.

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

Thanks for any input,

More information about the ath10k mailing list