On Thu, Jan 12, 2012 at 1:36 AM, Kim Lidström wrote:
> And here is a complete log.
thanks, don't know why desc processing is not completed. it fails
frequently in your case.
adding list
--
shafi
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.or
Hi Ben,
On Thu, Jan 12, 2012 at 3:25 AM, Ben Greear wrote:
> I have an ath9k AP, running 3.0.8 kernel (with a few tweaks).
> nohwcrypt is enabled.
>
> I set up some other machines with virtual stations, a total of
> around 450 and had them associate with the AP.
>
> It seems to have worked, at le
Hi All,
My laptop's wireless adaptor is Atheros ar9285, does the latest ath9k driver
support the Wi-Fi Direct ?
If does, how to make it work?
Any information is appreciated!
Thanks!___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://list
On 01/12/2012 12:27 AM, Mohammed Shafi wrote:
> Hi Ben,
>
> On Thu, Jan 12, 2012 at 3:25 AM, Ben Greear wrote:
>> I have an ath9k AP, running 3.0.8 kernel (with a few tweaks).
>> nohwcrypt is enabled.
>>
>> I set up some other machines with virtual stations, a total of
>> around 450 and had them a
.. well, nohwcrypt still populates the keycache, just with no-crypt entries.
I just wonder what other state is being kept in the keycache (eg
filtered frame handling lives there IIRC, I don't recall where the
aggregation state cache sits, but it shouldn't be required - it just
means the bitmap wou
Hi
I guess I see the problem on 3.2 (and compat-wireless) with two Atheros
cards - AR9380 and AR5416.
Debugging is impossible without special hardware, too, because there is
no panic/kernel output whatsoever.
At some point, the box hangs itself completely. A soft reset won't work,
I have to shut
On 01/12/2012 11:46 AM, Adrian Chadd wrote:
> .. well, nohwcrypt still populates the keycache, just with no-crypt entries.
>
> I just wonder what other state is being kept in the keycache (eg
> filtered frame handling lives there IIRC, I don't recall where the
> aggregation state cache sits, but it
Here's a bit that looks questionable to me. This is from
ath9k_rx_skb_postprocess
I'm thinking maybe that else clause should not re-assign
keyix if keyix is RXKEYIX_INVALID (and never set the RX_FLAG_DECRYPTED
flag in rxs->flag?
if (!(keyix == ATH9K_RXKEYIX_INVALID) && !decrypt_error &&
Remember, kim though it was a hang until we enabled some ath9k
debugging. We then discovered the driver was sitting in a very tight
interrupt handling loop...
adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailm
Hm, shouldn't the kernel actually detect something like this (i.e.,
detect when it's running in kernel mode for too long and not letting
userspace processes run)?
* On 12.01.2012 09:51 PM, Adrian Chadd wrote:
> Remember, kim though it was a hang until we enabled some ath9k
> debugging. We then di
At least I've seen messages like this when my kernel handled disk IO
(and actually the filesystem was buggy) - it echo'd a warning message
with a backtrace claiming that it has spend more than 120 seconds in
kernel mode or something.
* On 12.01.2012 09:56 PM, Mihai Moldovan wrote:
> Hm, shouldn't
On 01/12/2012 12:34 PM, Ben Greear wrote:
> Here's a bit that looks questionable to me. This is from
> ath9k_rx_skb_postprocess
>
> I'm thinking maybe that else clause should not re-assign
> keyix if keyix is RXKEYIX_INVALID (and never set the RX_FLAG_DECRYPTED
> flag in rxs->flag?
>
> if (!
Let me go and hit up the MAC guys and find exactly what the heck is
being kept in the keycache. There may be some good reasons it's being
done that I'm not yet aware of.
At least the (legacy, but not sure for Kite/similar) fast diversity
stuff is kept in the keycache? As well as the filtered frame
On 01/12/2012 03:53 PM, Adrian Chadd wrote:
> Let me go and hit up the MAC guys and find exactly what the heck is
> being kept in the keycache. There may be some good reasons it's being
> done that I'm not yet aware of.
>
> At least the (legacy, but not sure for Kite/similar) fast diversity
> stuff
14 matches
Mail list logo
