AP mode firmware crash on QCA9880-BR4A

[Sebastian Gottschall]

xo just revert that commit and test again. okay. i will do that that evening

Am 14.07.2015 um 12:50 schrieb Michal Kazior:
> + 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>
>>> wrote:
>>>> you can reproduce this issue with a standard compex wle 600v card. its a
>>>> on
>>>> 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
>>> machines?
>> yes. with older firmwares :-)
> I assume it's the same as Martin.
>
> Do you guys know if 10.2-00082[1] crashes as well?
>
> [1]: https://github.com/kvalo/ath10k-firmware/blob/master/10.2/firmware-3.bin_10.2-00082-4-2
>
>
>> 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
>>> memory.
>> 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 [2]
> 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.
>
> [2]: https://github.com/kvalo/ath/commit/748afc4735361e21ad655c0dc021ea3aaeeb3efd
>
>
> Michał
>