AP mode firmware crash on QCA9880-BR4A

Michal Kazior michal.kazior at tieto.com
Wed Jul 29 00:38:37 PDT 2015


On 29 July 2015 at 02:04, Martin Blumenstingl
<martin.blumenstingl at googlemail.com> wrote:
> Hi Michal,
>
> sorry for the delay, I was very busy for the past week.
> But now I am back with news.
> To keep it simple, all of my new findings below are with ath10k
> firmware 10.2.4.70-2.
> The wireless drivers were also updated in OpenWrt: "Loading modules
> backported from Linux version master-2015-07-21-0-g47cd203"
>
> On Thu, Jul 23, 2015 at 7:50 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
>> Yes, this should be enough. You'll want to add/keep a print to know
>> how many SWBA event come in though.
> I have used this patch [0] to make ath10k_wmi_event_host_swba only do
> printk("%s()\n", __func__);
> Result: firmware is not crashing - kernel log can be seen here: [1]
>
>> Perhaps not submitting beacons will prevent the crash or it'll postpone it until
>> after more SWBA events are delivered than before.
> I also tried that by #if 0'ing everything starting at "if
> (!arvif->beacon_buf)" until "trace_ath10k_tx_payload(ar, bcn->data,
> bcn->len);". The patch for this can be seen here: [2]
> The result: firmware is still not crashing - kernel log can be seen here: [3]
>
> Without any patches at all (only a printk at the start of
> ath10k_wmi_event_host_swba), this is the result the same as with old
> wireless driver versions: firmware crashes, see [5]
>
> Let me know what the next steps are - I'm sure we can fix this nasty bug! :-)

Awesome report, thanks!

It's good we narrowed the problem down to beacon transmission.

I can't get smart antenna out of my head at this point - it wasn't
supported in 10.1 firmware (which works with your device). However
10.2 seems to report that your hardware itself isn't capable of it so
it shouldn't be a problem (in theory).

I guess you could try playing with the WMI_BCN_TX_REF_DEF_ANTENNA in
the driver and try things like: 0x1, 0x7, 0xf, 0xff, 0xff00, 0xffff,
0xff0000, 0xffffff.

I doubt it'll help though. I guess other management frames would crash
firmware as well but I don't think they do. Can you verify that by
running scan from any station around to see if the ath10k AP responds
with a Probe Response and is hence visible in station's scan results,
please?


Michał



More information about the ath10k mailing list