ath0 performence issues "ar9300_Stub_GetCTSTimeout" "ar9300_Stub_GetCTSTimeout

[Adrian Chadd]

ifconfig -v wlan0 ; if you see powersave CAM rather than powersave
NONE, then it's trying to do powersave.


-a


On 15 February 2015 at 11:00, Miguel Clara <miguelmclara at gmail.com> wrote:
>
> On Sun, Feb 15, 2015 at 6:49 PM, Adrian Chadd <adrian at freebsd.org> wrote:
>>
>> On 15 February 2015 at 10:47, Miguel Clara <miguelmclara at gmail.com> wrote:
>> >
>> > On Sat, Feb 14, 2015 at 2:40 AM, Miguel Clara <miguelmclara at gmail.com>
>> > wrote:
>> >>
>> >>
>> >> On Sat, Jan 31, 2015 at 7:00 PM, Adrian Chadd <adrian at freebsd.org>
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> please try updating to -HEAD. It's possible that'll fix things.
>> >>
>> >>
>> >> Hi,
>> >>
>> >> I've update to head and still see the messages in dmesg.
>> >>
>> >> And the same slowness... rebooting seems to fix the issue, but it was
>> >> the
>> >> same in 10 and randomly (surely there's a reason only I'm not noticing
>> >> what)
>> >> it goes back to this state.
>> >>
>> >> Is there any debugging I can try to figure whats going on when this
>> >> happens?
>> >
>> >
>> > Also just now I lost network and saw this in dmesg:
>> > ath0: ath_intr: TSFOOR
>> > ath0: ath_intr: TSFOOR
>> > ath0: ath_intr: TSFOOR
>> > ath0: ath_intr: TSFOOR
>> > ath0: ath_intr: TSFOOR
>> > ath0: ath_intr: TSFOOR
>> > ath0: ath_intr: TSFOOR
>> > ath0: ath_intr: TSFOOR
>> > ath0: ath_intr: TSFOOR
>> >
>> >
>> > It was just during a few seconds.
>>
>> Ok, so that happens because you haven't heard a beacon for a while,
>> and the "TSF out of range" interrupt has fired.
>>
>> Try creating the VAP again, but this time do it with -bgscan -powersave .
>>
>>
> I just did that manually and added "-bgscan -powersave" to rc.conf.
>
> Is there a way I can verify those changes were applied?
>
> ifconfig wlan0 doesn't show anything related.
>
>>
>> -adrian
>>
>> >>
>> >>>
>> >>> On 31 January 2015 at 09:19, Miguel Clara <miguelmclara at gmail.com>
>> >>> wrote:
>> >>> > I've just upgrade to the latest 10/stable.
>> >>> >
>> >>> > trying to git clone a repo was giving me horrible speed, and I
>> >>> > honestly
>> >>> > tough it was at their side, until I noticed issues while browsing
>> >>> > and
>> >>> > this
>> >>> > in dmesg:
>> >>> >
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetCTSTimeout: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> > ar9300_Stub_GetAntennaSwitch: called
>> >>> >
>> >>> > Speedtest either gives me and ok result or very poor, and pings also
>> >>> > prove
>> >>> > that something is not quite right:
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=7 ttl=59 time=18.096 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=8 ttl=59 time=149.083 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=9 ttl=59 time=18.376 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=10 ttl=59 time=19.084 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=11 ttl=59 time=18.305 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=12 ttl=59 time=18.140 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=13 ttl=59 time=16.700 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=14 ttl=59 time=105.554 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=15 ttl=59 time=34.336 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=16 ttl=59 time=76.410 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=17 ttl=59 time=34.400 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=18 ttl=59 time=73.521 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=19 ttl=59 time=154.728 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=20 ttl=59 time=126.120 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=21 ttl=59 time=170.920 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=22 ttl=59 time=137.330 ms
>> >>> > 64 bytes from 216.58.210.110: icmp_seq=23 ttl=59 time=17.424 ms
>> >>> >
>> >>> > (tried other host with similar results)
>> >>> >
>> >>> > It seems to settle for a while but randomly comes back..
>> >>> >
>> >>> > uname -a
>> >>> > FreeBSD r2d2 10.1-STABLE FreeBSD 10.1-STABLE #7 r277979M: Sat Jan 31
>> >>> > 16:05:30 WET 2015     root at r2d2:/usr/obj/usr/src/sys/GENERIC  amd64
>> >>> > _______________________________________________
>> >>> > freebsd-wireless at freebsd.org mailing list
>> >>> > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
>> >>> > To unsubscribe, send any mail to
>> >>> > "freebsd-wireless-unsubscribe at freebsd.org"
>> >>
>> >>
>> >
>
>