Hi,
The ath_tx_default_comp stuff was fixed in -HEAD with a reasonably big
overhaul of the 11n aggregation code. It fixed a whole lot of bugs. I
don't think there's going to be a cheap solution to that besides
running -HEAD or backporting. I was kinda hoping another committer
would step up and backport the net80211 fixes from -HEAD to stable/10
once they're known to work out okay. I'm just too busy and
time-limited to look after both -HEAD and stable branches. :(
The second is a bit odd - mostly that indicates the STA has gone away
and we just haven't timed it out yet. (It'll tell the AP it's going to
sleep so it can scan, and it may just never decide to come back ..)
-adrian
On 15 December 2014 at 14:43, David Blewett <da...@dawninglight.net> wrote:
> I haven't hit a kernel panic, but several times I get to the point where the
> wifi connection from Macbook no longer functions. The icon says it's
> connected, but no network traffic passes. I see this in dmesg on the FreeBSD
> box:
>
> ath0: ath_tx_default_comp: bf 0xfffffe004e7a3b98: seqno 1873: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e78aec0: seqno 1874: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e7787e8: seqno 1875: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e795fa8: seqno 1876: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e786f00: seqno 1877: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e791190: seqno 1878: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e787560: seqno 1879: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e7a9b38: seqno 1880: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e77f910: seqno 1881: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e79e720: seqno 1882: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e777990: seqno 1883: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e7a8e78: seqno 1884: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e792180: seqno 1885: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e7a2878: seqno 1886: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e78f9a8: seqno 1887: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e7a3208: seqno 1888: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e7893a8: seqno 1889: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e7a2218: seqno 1890: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e782f40: seqno 1891: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e77b620: seqno 1892: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e78d368: seqno 1893: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e783738: seqno 1894: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e782748: seqno 1895: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e7a5518: seqno 1896: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e7a79c0: seqno 1897: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e786d68: seqno 1898: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e77d2d0: seqno 1899: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e78b1f0: seqno 1900: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e7a1090: seqno 1901: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e77ac90: seqno 1902: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e77c7a8: seqno 1903: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e786240: seqno 1905: bf_next not
> NULL!
> ath0: ath_tx_default_comp: bf 0xfffffe004e79f578: seqno 1906: bf_next not
> NULL!
> wlan0: [28:cf:e9:12:ed:bb] pwr save q overflow, drops 179 (size 50)
> wlan0: [28:cf:e9:12:ed:bb] pwr save q overflow, drops 180 (size 50)
> wlan0: [28:cf:e9:12:ed:bb] pwr save q overflow, drops 181 (size 50)
> wlan0: [28:cf:e9:12:ed:bb] pwr save q overflow, drops 182 (size 50)
> wlan0: [28:cf:e9:12:ed:bb] pwr save q overflow, drops 183 (size 50)
> wlan0: [28:cf:e9:12:ed:bb] pwr save q overflow, drops 184 (size 50)
> wlan0: [28:cf:e9:12:ed:bb] pwr save q overflow, drops 185 (size 50)
>
>
> Thanks,
>
> David Blewett
>
> On Sun, Dec 14, 2014 at 9:29 PM, David Blewett <da...@dawninglight.net>
> wrote:
>>
>> Okay, I've built a custom kernel with if_ath_pci as a module, rebooted
>> into the new kernel and got it running. I also enabled AH_DEBUG. Will let
>> you know how things go this week.
>>
>> Thanks,
>>
>> David Blewett
>>
>> On Sun, Dec 14, 2014 at 2:58 PM, David Blewett <da...@dawninglight.net>
>> wrote:
>>>
>>> Okay, I can try to give that a go. Will take me a bit. I use ZFS on
>>> encrypted geli devices, and haven't tried building a custom kernel yet with
>>> this config.
>>>
>>> Thanks,
>>>
>>> David Blewett
>>>
>>> On Sun, Dec 14, 2014 at 2:55 PM, Adrian Chadd <adr...@freebsd.org> wrote:
>>>>
>>>> Aha! Listen time is 0. Hm!
>>>>
>>>>
>>>> Just add this at line 1179 and recompile:
>>>>
>>>>
>>>> if (ani_state->listen_time == 0)
>>>> return;
>>>>
>>>> it's possible that it'll happen; it shoud be bailing out sooner rather
>>>> than later.
>>>>
>>>>
>>>>
>>>> -adrian
>>>>
>>>>
>>>> On 14 December 2014 at 11:53, David Blewett <da...@dawninglight.net>
>>>> wrote:
>>>> > If this would be easier on IRC, I'm BlueAidan on Freenode.
>>>> >
>>>> > Output:
>>>> >
>>>> > (kgdb) list *0xffffffff8045161d
>>>> > 0xffffffff8045161d is in ar9300_ani_ar_poll
>>>> > (/usr/src/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_ani.c:1180).
>>>> > 1175 */
>>>> > 1176 if (!DO_ANI(ah)) {
>>>> > 1177 return;
>>>> > 1178 }
>>>> > 1179
>>>> > 1180 ofdm_phy_err_rate =
>>>> > 1181 ani_state->ofdm_phy_err_count * 1000 /
>>>> > ani_state->listen_time;
>>>> > 1182 cck_phy_err_rate =
>>>> > 1183 ani_state->cck_phy_err_count * 1000 /
>>>> > ani_state->listen_time;
>>>> > 1184
>>>> >
>>>> > Thanks,
>>>> >
>>>> > David Blewett
>>>> >
>>>> > On Sun, Dec 14, 2014 at 2:39 PM, Adrian Chadd <adr...@freebsd.org>
>>>> > wrote:
>>>> >>
>>>> >> Hi!
>>>> >>
>>>> >> Hm, an integer divide by zero fault. Tsk.
>>>> >>
>>>> >> can you do this:
>>>> >>
>>>> >> kgdb /boot/kernel/kernel
>>>> >> list *0xffffffff8045161d
>>>> >>
>>>> >> Thanks!
>>>> >>
>>>> >>
>>>> >>
>>>> >> -adrian
>>>> >>
>>>> >>
>>>> >> On 14 December 2014 at 11:24, David Blewett <da...@dawninglight.net>
>>>> >> wrote:
>>>> >> > Hi All:
>>>> >> >
>>>> >> > I've been having issues with a TP-LINK TL-WDN4800 PCI Express
>>>> >> > adapter
>>>> >> > [1]
>>>> >> > that seem to have become worse since upgrading to 10.1-RELEASE.
>>>> >> > Since
>>>> >> > then,
>>>> >> > I've had a couple of kernel panics. I use the adapter in hostapd
>>>> >> > mode as
>>>> >> > my
>>>> >> > main WiFi access point. I would appreciate any help in making my
>>>> >> > setup
>>>> >> > more
>>>> >> > reliable, and am open to trying to just about anything to help
>>>> >> > troubleshoot.
>>>> >> >
>>>> >> > The problems that I see are regular disconnections from a Macbook
>>>> >> > Pro
>>>> >> > client. When this happens, sometimes the wifi icon says it is
>>>> >> > connected,
>>>> >> > but I cannot actually transmit anything to the host (i.e., pings
>>>> >> > fail).
>>>> >> > The
>>>> >> > only recourse is to turn the mbp's wifi off, then back on. This
>>>> >> > *usually*
>>>> >> > succeeds, but sometimes does not. I also have an iPad that has
>>>> >> > similar
>>>> >> > issues; turning wifi off and back on is usually sufficient to
>>>> >> > restore
>>>> >> > connectivity.
>>>> >> >
>>>> >> > This is my /etc/rc.conf:
>>>> >> >
>>>> >> > wlans_ath0="wlan0"
>>>> >> > create_args_wlan0="wlanmode hostap bssid"
>>>> >> > ifconfig_wlan0="HOSTAP ssid MiddleEarth mode 11ng channel 2"
>>>> >> >
>>>> >> > and /etc/hostapd-wlan0.conf:
>>>> >> >
>>>> >> > interface=wlan0
>>>> >> > debug=2
>>>> >> > ctrl_interface=/var/run/hostapd
>>>> >> > ctrl_interface_group=wheel
>>>> >> > ssid=MiddleEarth
>>>> >> > wpa=2
>>>> >> > wpa_passphrase=xxxx
>>>> >> > wpa_key_mgmt=WPA-PSK
>>>> >> > wpa_pairwise=CCMP
>>>> >> >
>>>> >> > I see a lot of this in the logs:
>>>> >> >
>>>> >> > ath0: stuck beacon; resetting (bmiss count 8)
>>>> >> >
>>>> >> > However, from what I've read these are due to channel congestion
>>>> >> > and are
>>>> >> > to
>>>> >> > be expected. The kernel panics look like this:
>>>> >> >
>>>> >> > Fatal trap 18: integer divide fault while in kernel mode
>>>> >> > cpuid = 1; apic id = 11
>>>> >> > instruction pointer = 0x20:0xffffffff8045161d
>>>> >> > stack pointer = 0x28:0xfffffe00e43bb760
>>>> >> > frame pointer = 0x28:0xfffffe00e43bb7b0
>>>> >> > code segment = base 0x0, limit 0xfffff, type 0x1b
>>>> >> > = DPL 0, pres 1, long 1, def32 0, gran 1
>>>> >> > processor eflags = interrupt enabled, ath0: stuck beacon;
>>>> >> > resetting
>>>> >> > (bmiss count 8)
>>>> >> > resume, IOPL = 0
>>>> >> > current process = 12 (swi4: clock)
>>>> >> > trap number = 18
>>>> >> > panic: integer divide fault
>>>> >> > cpuid = 0
>>>> >> > KDB: stack backtrace:
>>>> >> > #0 0xffffffff80963000 at kdb_backtrace+0x60
>>>> >> > #1 0xffffffff80928125 at panic+0x155
>>>> >> > #2 0xffffffff80d24f1f at trap_fatal+0x38f
>>>> >> > #3 0xffffffff80d24b7c at trap+0x75c
>>>> >> > #4 0xffffffff80d0a782 at calltrap+0x8
>>>> >> > #5 0xffffffff8045b248 at ar9300_ani_poll_freebsd+0x48
>>>> >> > #6 0xffffffff804093d6 at ath_calibrate+0xf6
>>>> >> > #7 0xffffffff8093d557 at softclock_call_cc+0x177
>>>> >> > #8 0xffffffff8093d994 at softclock+0x94
>>>> >> > #9 0xffffffff808faf4b at intr_event_execute_handlers+0xab
>>>> >> > #10 0xffffffff808fb396 at ithread_loop+0x96
>>>> >> > #11 0xffffffff808f8b6a at fork_exit+0x9a
>>>> >> >
>>>> >> > Here is the pciconf output:
>>>> >> >
>>>> >> > ath0@pci0:2:0:0: class=0x028000 card=0x3112168c chip=0x0030168c
>>>> >> > rev=0x01
>>>> >> > hdr=0x00
>>>> >> > vendor = 'Atheros Communications Inc.'
>>>> >> > device = 'AR9300 Wireless LAN adaptor'
>>>> >> > class = network
>>>> >> >
>>>> >> > 1. http://www.tp-link.com/lk/products/details/?model=TL-WDN4800
>>>> >> >
>>>> >> > Thanks,
>>>> >> >
>>>> >> > David Blewett
>>>> >> > _______________________________________________
>>>> >> > freebsd-wireless@freebsd.org mailing list
>>>> >> > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
>>>> >> > To unsubscribe, send any mail to
>>>> >> > "freebsd-wireless-unsubscr...@freebsd.org"
_______________________________________________
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
