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"

Reply via email to