ath10k: firmware crash in station mode & problem DFS
greearb at candelatech.com
Fri Jun 6 08:50:59 PDT 2014
On 06/06/2014 02:05 AM, Vu Hai NGUYEN wrote:
>> Ok, the difference must be changes I made to the scanning state machine.
>> That patch was fairly big, and did several different things. I have split
>> it up into 4 separate patches to try to narrow down where the problem was
>> Can you try these firmware images in order and let me know the first
>> that fails to do DFS properly? The scan-1 should be white-space and
>> debugging only, so hopefully it works.
> Thank you, I did the test, the first one and second one (scan 1 & 2) can work with DFS, the last 2 cann't.
Ok, looks like the patch where I change the scan state machine logic is the bad one.
I will review it carefully and maybe try splitting it further today.
Are you able to test with a modified kernel? If so, I can add debuglog
messages to the firmware and give you a kernel ath10k patch to print
those out in the kernel logs so you can send them to me for decoding...
Anyone have any ideas what sorts of problems I might be introducing by
changing around the scan logic? Normal scanning seems to at least mostly
work...how is DFS special?
> I also retried to test promiscuous mode, may be yesterday I did something wrong when copy-paste the firmware.
> Today I try the 172 commit firmware and it works in promisc mode, so again with binary search I redo my serie of test,
> the different is between 120 (broken firmware) and 121 (non broken).
> (My serie is: 172 OK => 86 KO => 129 OK => 107 KO => 118 KO => 124 OK => 121 OK => 120 KO, than re-change to
> confirm the different :D)
> Hope that is helpful for you
That is interesting...patch 121 is small and just fixes a firmware crash I was seeing
related to null dereference in beacon config logic. Do you see firmware crashes for
build 120, or does it just silently not work?
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the ath10k