Hello, paranormal.
You wrote 26 января 2013 г., 22:01:03:
p> 70 Jan 26 17:41:48 mbsd kernel: ath0: stuck beacon; resetting (bmiss
p> count 4)
p> 71 Jan 26 17:42:02 mbsd last message repeated 62
p> times
I have almost same problem with my 9220
ath0: mem 0xa00
Hi all,
I'm running a recent -current (r245741) and seem to be getting
interface flaps. Since this machine is mainly used for home mail and a
little light file serving I'm not sure when they started occuring as i
only have logging going back to the 18th Jan.
Sample log messages are:
Jan 24
Hm, see if it's a beacon miss thing:
sysctl dev.ath.0.debug=0x80
adrian
On 27 January 2013 04:31, Vincent Hoffman wrote:
> Hi all,
> I'm running a recent -current (r245741) and seem to be getting
> interface flaps. Since this machine is mainly used for home mail and a
> little light
Are you using it in HT40 or HT20 mode?
For 2GHz in noisy environments, use it in HT20 mode.
adrian
On 27 January 2013 02:06, Lev Serebryakov wrote:
> Hello, paranormal.
> You wrote 26 января 2013 г., 22:01:03:
>
> p> 70 Jan 26 17:41:48 mbsd kernel: ath0: stuck beacon; resetting (bmiss
> p> co
Hello, Adrian.
You wrote 27 января 2013 г., 21:17:48:
AC> Are you using it in HT40 or HT20 mode?
AC> For 2GHz in noisy environments, use it in HT20 mode.
I'm using HT20, and it seems, card in my box overheats with 802.11n
clients (it hangs very hard under load with 802.11n client), so I
don't u
On 27 January 2013 09:44, Lev Serebryakov wrote:
> AC> For 2GHz in noisy environments, use it in HT20 mode.
> I'm using HT20, and it seems, card in my box overheats with 802.11n
> clients (it hangs very hard under load with 802.11n client), so I
> don't use 802.11n on notebook (I want to chang
Hello, Adrian.
You wrote 27 января 2013 г., 21:59:32:
>> AC> For 2GHz in noisy environments, use it in HT20 mode.
>> I'm using HT20, and it seems, card in my box overheats with 802.11n
>> clients (it hangs very hard under load with 802.11n client), so I
>> don't use 802.11n on notebook (I want
On 27/01/2013 17:11, Adrian Chadd wrote:
> Hm, see if it's a beacon miss thing:
>
>
> sysctl dev.ath.0.debug=0x80
now with added debugging.
Jan 27 21:49:09 ostracod kernel: ath0: ath_bmiss_proc: pending 1
Jan 27 21:49:09 ostracod kernel: ath0: ath_beacon_config: nexttbtt
33171100 intval 100 (100)
Right, this looks like you're missing beacons.
My latest -HEAD changes causes a non-loss hardware reset, in case it's
gone deaf.
But if you are going deaf and missing the occasional beacon, it
shouldn't be disconnecting you. I wonder how that logic is working..
Adrian
On 27 January 2013 13:56