Just as a reference, does madwifi exhibit this behaviour?
Adrian
On 3 March 2011 13:14, Fabrice wrote:
> I'm now able able to prevent the CM9 to lock up.
> I changed the RX/TX DMA burst size from 128 bytes to 16 bytes.
> When I stream TCP data, I still some issues. The TX queue gets stuck and
I'm now able able to prevent the CM9 to lock up.
I changed the RX/TX DMA burst size from 128 bytes to 16 bytes.
When I stream TCP data, I still some issues. The TX queue gets stuck and when
it
tries to reset it cannot stop the RX dma.
ath5k phy0: (ath5k_tx_complete_poll_work:2306): TX queue stuc
Well, the first thing that immediately springs to mind there is 11g == OFDM
and CCK, but 11a == OFDM only. You may find the CCK stuff behaves
differently in the presence of noise.
You could also try fiddling with ANI (is there ani in ath5k?) which has some
parameters for controlling CCK sensitivit
I'll try this thanks.
Another thing i've noticed is that whenever Ath5k works in g mode, it
reports no PHY or CRC errors, although inteferer is running.
This is not the case when the driver is in 802.11a mode.
Alex
On 3/3/2011 9:59 ??, Adrian Chadd wrote:
Have you also added a hook or two
Have you also added a hook or two to monitor what's going on to the noise
floor?
IIRC, atheros radios report RSSI as an offset from the current NF; if the NF
raises but the signal doesn't, RSSI will "decrease".
Adrian
On 3 March 2011 11:50, Alex wrote:
> Hi,
>
> i'd list to ask the members
Hi,
i'd list to ask the members of this list regarding the value rs->rs_rssi
ath5k reports in the ath5k_receive_frame function.
I use a monitor node (its interface set to promiscuous mode) and i
collect the rssi values (rs->rs_rssi) in a per packet basis (i'
vemodified base.c).
I use an in
Hi Maxim,
I'm facing a similar issue as the one you described.
I noticed that changing the RX and TX burst sizes have an effect
but did not solve the issue completely.
Did you found a workaround?
Thanks.
___
ath5k-devel mailing list
ath5k-devel@lists.a
