Re: hashing error in hacked 4.4.6+ kernel.

2016-03-28 Thread Ben Greear
So, it appears at least part of the problem is that the station is not added to the hash to begin with, and existing code does not check for that failure or deal with it. I added a check and I see this below. That -16 value means EBUSY from what I can tell, because two rehashes are scheduled at

Re: hashing error in hacked 4.4.6+ kernel.

2016-03-26 Thread Ben Greear
On 03/26/2016 12:20 PM, Johannes Berg wrote: On Fri, 2016-03-25 at 17:56 -0700, Ben Greear wrote: Mar 25 17:02:05 ath10k.candelatech.com kernel: sta28: deauthenticating from 04:f0:21:f6:85:1c by local choice (Reason: 3=DEAUTH_LEAVING) Mar 25 17:02:05 ath10k.candelatech.com kernel: ---

Re: hashing error in hacked 4.4.6+ kernel.

2016-03-26 Thread Johannes Berg
On Fri, 2016-03-25 at 17:56 -0700, Ben Greear wrote: >  > Mar 25 17:02:05 ath10k.candelatech.com kernel: sta28: > deauthenticating from 04:f0:21:f6:85:1c by local choice (Reason: > 3=DEAUTH_LEAVING) > Mar 25 17:02:05 ath10k.candelatech.com kernel: [ cut here > ] > Mar 25 17:

hashing error in hacked 4.4.6+ kernel.

2016-03-25 Thread Ben Greear
First, this kernel has lots of patches, including patches to the station hashing. http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary But, my hashing patches cannot cause an error return as far as I can tell, so I'm not sure this is my bug or not. And, I'm running custom wave-2 ath10