Date: Sun, 28 Apr 2013 12:38:20 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Lev Serebryakov <lev@freebsd.org> Cc: freebsd-wireless@freebsd.org Subject: Re: New hardware, old problem: stuck beacon when here is WiFi traffic Message-ID: <CAJ-VmokLKdwckXjzH64P=mYm9pZQzkCkJhDV4iojzJehXmJLLA@mail.gmail.com> In-Reply-To: <1467048277.20130428225006@serebryakov.spb.ru> References: <2810538978.20130423164137@serebryakov.spb.ru> <CAJ-Vmom4UDoz7EgdnVeQ%2BALuFFXkH9t_Uj7=FwL77S5rKfUD1g@mail.gmail.com> <1813905823.20130423184528@serebryakov.spb.ru> <CAJ-VmomhRaKODxis09MjAhUbAUOw%2B6jWBY48JpZR_JgfZZLKcQ@mail.gmail.com> <184105677.20130424002002@serebryakov.spb.ru> <CAJ-VmokVmHDXwE7S5koSqtFjPXQ_VUPhj8gfMruDM2k-DyUMPw@mail.gmail.com> <1936997795.20130424003555@serebryakov.spb.ru> <CAJ-Vmokx2QhcjcsgA-_kqjX63Vu4CLk7HkuyALautbnzp61ywQ@mail.gmail.com> <886711115.20130424004702@serebryakov.spb.ru> <CAJ-VmoksSTBC7jmC-_hvBeJFSD0k28HoZodaWdHm0AF0d1yZJg@mail.gmail.com> <6010292503.20130426001447@serebryakov.spb.ru> <CAJ-VmomUsPgHTVGaKHZ_YE%2Bu1ZOjGqrVfh2uYmvOs6gKmhnxOw@mail.gmail.com> <CAJ-VmokZBbmHbruKJV-8kvTyOTsiq5_XHnfqUYo3vO68872Q=w@mail.gmail.com> <99510815.20130426122508@serebryakov.spb.ru> <CAJ-VmoktRPbnDRbRuwA4i8w50kExs2pwD4yBawL6iOz7F4Bknw@mail.gmail.com> <CAJ-VmonCao99MOrm97tQS_f1xS9tieQfg-nQUB4APWVmdJJUBg@mail.gmail.com> <777510536.20130427123352@serebryakov.spb.ru> <CAJ-Vmonpc6rMKfT3qHme4Yzwkcj0zij8dYzXktpbz3bbSmT0=Q@mail.gmail.com> <1467048277.20130428225006@serebryakov.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 April 2013 11:50, Lev Serebryakov <lev@freebsd.org> wrote:
> 300M. Only 11-30M seen by client now, but no beacon stucks.
> After AP hangs several forced beacon stucks + hostaptd restart
> allow client to re-associate.
Right. That's likely because 11n aggregation wasn't enabled. I don't know why.
> Log with dev.ath.0.debug=0x900000020 attached ("sudo" messages are left as
> "time marks").
Cool, thanks.
It's odd. The descriptor list(s) look fine - ie, the descriptors
aren't out of order or anything. (Ie, the descriptor and link pointers
line up with the order that the ath_buf's are in the TXQ.)
And the descriptors in your particular setup aren't chained into
multi-descriptor lists, they're one descriptor per frame. There used
to be bugs with my 11n TX code and which ath_buf to check the status
of in a list of ath_bufs, but this last test is with no aggregation.
So that's not a problem.
The next step is seeing whether the hardware queue is actually just
plain stuck, or whether it's idle. If it's idle, it may just be
waiting for another call to ath_hal_txstart() or whatever the call is
to re-trigger it. The only reason it would be idle like that though is
if it hit the end of the descriptor list at about the same time we
appended a frame to the list. However, every time we append a frame to
the hardware queue, we also call ath_hal_txstart() to re-kick TX.
There's some race condition hack that Sam threw in that gets enabled
only if you compile things with TDMA support enabled. Would you mind
compiling in TDMA support (add options IEEE80211_SUPPORT_TDMA) to your
kernel config and rebuild? I'd like to see if that TX queue workaround
is effective at helping us out here.
Does this happen with tcp iperf? or only udp iperf?
adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokLKdwckXjzH64P=mYm9pZQzkCkJhDV4iojzJehXmJLLA>