On 02/22/2013 04:55 AM, Ben Greear wrote:
On 02/22/2013 04:38 AM, Felix Fietkau wrote:
On 2013-02-22 1:25 PM, Sujith Manoharan wrote:
Felix Fietkau wrote:
Please also check if the station(s) that the frames are queued for are
in powersave state for some reason. That would prevent the tx path from
throwing them in the hw queue, yet they'd still take up pending-frame
slots. I was planning on fixing this eventually by expiring frames that
stay in the queue for too long, but haven't decided on the exact
approach yet.
PS is disabled for multi-VIF.
What about off-channel PS due to scans, etc.
Scan is always locked to the same channel in this setup (once
a single station is associated).
The stations stay associated while this problem happens (the
high-priority queue seems to work just fine, which may be
the reason they stay associated just fine.)
In some cases, I see packets delivered around 30 seconds late...
aside from PS and off-channel..any idea what could make a packet
stick around that long in the tx queues?
One of our customers on a 3.5.7+ kernel hit the problem without
using any RF attenuator...just over-the-air communication to
their AP. It happened on both 2.4 and 5Ghz bands. Seems rx
signal is around 40 in their environment. It took them around
24 hours to hit the problem on average.
Last we checked, we could fairly easily reproduce this in
our lab using an attenuator and a certain setup, so if there
is any debugging we could add to help narrow down what
might be causing this, we can give that a try.
For instance, is there any good way to know for certain
if packets in the queue are in power-save or not? I know
we at least attempt to disable power-save, but possibly
it gets re-enabled somehow?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
