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? -Rajkumar -- 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
