AP mode firmware crash on QCA9880-BR4A
michal.kazior at tieto.com
Tue Jul 14 03:50:39 PDT 2015
+ ath10k list back, martin
Make sure to reply to everyone next time and not just me, please ;-)
On 14 July 2015 at 12:18, Sebastian Gottschall <s.gottschall at dd-wrt.com> wrote:
> Am 14.07.2015 um 07:45 schrieb Michal Kazior:
>> On 14 July 2015 at 00:57, Sebastian Gottschall <s.gottschall at dd-wrt.com>
>>> you can reproduce this issue with a standard compex wle 600v card. its a
>>> board eeprom card. so calibration issues will not occur.
>>> but this card will also crash with recent firmwares on any platform. but
>>> (and now the big thing) it will only happen in ap mode.
>>> if you initialize it in station mode, it will work
>> That's interesting. Did the card ever work as AP with ath10k for you?
>> By "any platform" you mean you tested on both little- and big- endian
> yes. with older firmwares :-)
I assume it's the same as Martin.
Do you guys know if 10.2-00082 crashes as well?
> tested on AR71XX (MIPS BE) , Gateworks Ventana ( ARM Little endian), and
> Gateworks Laguna ( ARM Little Endian)
> all 3 devices crash the firmware. , e
Thanks for the details.
>> My current guess is this could have something to do with AP beaconing
>> - if it was to get an invalid dma pointer it could crash the device so
>> hard as to effectively prevent host from accessing register dump
> but whats the difference? some cards work and some are not. so something in
> the otp must be likelly responsible for crashing the firmware.
> just a guess
I can imagine firmware could execute some code based on board data or
device specific bits which do extra preparations on beacon path and
which presence or lack of could prompt a crash. This is merely a
speculation on my part.
The OTP most likely isn't the problem because - as proven by Martin -
the crash occurs with caldata at apparently same spot as when
board+otp. When caldata is used driver does not execute OTP program at
all. Maybe caldata itself is misinterpreted by newer firmware?
If someone is brave enough with spare time one could attempt to
re-implement the old by-copy beaconing (which copies entire beacon
frame into WMI command instead of passing just dma pointer; see 
for reference) to see if it makes any difference. If that helps it
would imply the crash is indeed related to dma beaconing. If it
doesn't it would prove nothing though.
More information about the ath10k