On 02/01/2012 10:50 AM, Rajkumar Manoharan wrote:
On Wed, Feb 01, 2012 at 09:31:50AM -0800, Ben Greear wrote:
On 02/01/2012 08:05 AM, Rajkumar Manoharan wrote:
In the following scenario, where the distance b/w STA and AP is ~10m
or in a shield environment by placing an attenuator with reduced AP
txpower, the station started reporting with beacon loss and got
disconnected whenever the chariot endpoint was initiated with BiDi
traffic. In such state, two different stuck cases were observed.
* rx clear is stuck at low for more than 100ms
* dcu chain and complete state is stuck.
This patch detects the stuck state if the beacons are not received for
more than 300ms. In the above matching conditions, trigger a chip
reset to recover. This issue was originally reported in 3.0 kernel with
AR9382 chip by having two stations associated with two different APs in
the same channel and was attenuated/controlled by Azimuth ADEPT-n box.
Can't the AP be configured for larger beacon intervals? Maybe have it
be some multiple of that instead of a fixed 300ms?
Yes. It can. But the detection log will look for specific signature and
meanwhile if the beacons are received, the inprogress logic will be aborted.
I believe that 300ms is not too short or too long to trigger the detection.
Isn't it?
If the beacon interval is 500ms, then you could easily not get a beacon
during your 300ms interval. If the beacon logic is just a backup, and it doesn't
matter if you don't see the beacon, then probably there is no problem.
I just wanted to make sure you had thought about that issue and that there
would not be spurious fixup logic called if the beacon timer is large.
Thanks,
Ben
-Rajkumar
--
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
