Problem with Atheros adapter (TP-LINK TL-WDN4800, AR9380)
Dear FreeBSD friends, Excuse me, I just became member of this mailling list, so I could not respond to the correct mail thread. About two months ago (December 14 and 15, there were some mails posted concerning trouble with the TP-LINK TL-WDN4800 PCI Express adapter. David and Adrian had a conversation about it. Adrian suggested David to switch to HEAD in order to fix some connection problems with some iMAC devices and the TP-LINK. I wonder if this has fixed the problem with the TP-LINK TL-WDN4800 PCI Express card. I'm just about to order the same card and I want to use it in the same way David did. Of course I don't want to end up with unexpected disconnections. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.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
Re: Problem with Atheros adapter (TP-LINK TL-WDN4800, AR9380)
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 0xfe004e7a3b98: seqno 1873: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e78aec0: seqno 1874: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e7787e8: seqno 1875: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e795fa8: seqno 1876: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e786f00: seqno 1877: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e791190: seqno 1878: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e787560: seqno 1879: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e7a9b38: seqno 1880: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e77f910: seqno 1881: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e79e720: seqno 1882: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e777990: seqno 1883: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e7a8e78: seqno 1884: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e792180: seqno 1885: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e7a2878: seqno 1886: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e78f9a8: seqno 1887: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e7a3208: seqno 1888: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e7893a8: seqno 1889: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e7a2218: seqno 1890: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e782f40: seqno 1891: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e77b620: seqno 1892: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e78d368: seqno 1893: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e783738: seqno 1894: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e782748: seqno 1895: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e7a5518: seqno 1896: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e7a79c0: seqno 1897: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e786d68: seqno 1898: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e77d2d0: seqno 1899: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e78b1f0: seqno 1900: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e7a1090: seqno 1901: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e77ac90: seqno 1902: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e77c7a8: seqno 1903: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e786240: seqno 1905: bf_next not
NULL!
ath0: ath_tx_default_comp: bf 0xfe004e79f578: 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 *0x8045161d
0x8045161d is in ar9300_ani_ar_poll
(/usr/src/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_ani.c:1180).
1175 */
1176if (!DO_ANI(ah)) {
1177return;
1178}
1179
1180ofdm_phy_err_rate =
1181ani_state-ofdm_phy_err_count * 1000 /
ani_state-listen_time;
1182cck_phy_err_rate =
1183ani_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
Re: Problem with Atheros adapter (TP-LINK TL-WDN4800, AR9380)
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 0xfe004e7a3b98: seqno 1873: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e78aec0: seqno 1874: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e7787e8: seqno 1875: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e795fa8: seqno 1876: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e786f00: seqno 1877: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e791190: seqno 1878: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e787560: seqno 1879: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e7a9b38: seqno 1880: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e77f910: seqno 1881: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e79e720: seqno 1882: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e777990: seqno 1883: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e7a8e78: seqno 1884: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e792180: seqno 1885: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e7a2878: seqno 1886: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e78f9a8: seqno 1887: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e7a3208: seqno 1888: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e7893a8: seqno 1889: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e7a2218: seqno 1890: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e782f40: seqno 1891: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e77b620: seqno 1892: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e78d368: seqno 1893: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e783738: seqno 1894: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e782748: seqno 1895: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e7a5518: seqno 1896: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e7a79c0: seqno 1897: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e786d68: seqno 1898: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e77d2d0: seqno 1899: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e78b1f0: seqno 1900: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e7a1090: seqno 1901: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e77ac90: seqno 1902: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e77c7a8: seqno 1903: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e786240: seqno 1905: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xfe004e79f578: 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
Problem with Atheros adapter (TP-LINK TL-WDN4800, AR9380)
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= 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:0x8045161d stack pointer = 0x28:0xfe00e43bb760 frame pointer = 0x28:0xfe00e43bb7b0 code segment= base 0x0, limit 0xf, 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 0x80963000 at kdb_backtrace+0x60 #1 0x80928125 at panic+0x155 #2 0x80d24f1f at trap_fatal+0x38f #3 0x80d24b7c at trap+0x75c #4 0x80d0a782 at calltrap+0x8 #5 0x8045b248 at ar9300_ani_poll_freebsd+0x48 #6 0x804093d6 at ath_calibrate+0xf6 #7 0x8093d557 at softclock_call_cc+0x177 #8 0x8093d994 at softclock+0x94 #9 0x808faf4b at intr_event_execute_handlers+0xab #10 0x808fb396 at ithread_loop+0x96 #11 0x808f8b6a 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
Re: Problem with Atheros adapter (TP-LINK TL-WDN4800, AR9380)
Hi! Hm, an integer divide by zero fault. Tsk. can you do this: kgdb /boot/kernel/kernel list *0x8045161d 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= 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:0x8045161d stack pointer = 0x28:0xfe00e43bb760 frame pointer = 0x28:0xfe00e43bb7b0 code segment= base 0x0, limit 0xf, 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 0x80963000 at kdb_backtrace+0x60 #1 0x80928125 at panic+0x155 #2 0x80d24f1f at trap_fatal+0x38f #3 0x80d24b7c at trap+0x75c #4 0x80d0a782 at calltrap+0x8 #5 0x8045b248 at ar9300_ani_poll_freebsd+0x48 #6 0x804093d6 at ath_calibrate+0xf6 #7 0x8093d557 at softclock_call_cc+0x177 #8 0x8093d994 at softclock+0x94 #9 0x808faf4b at intr_event_execute_handlers+0xab #10 0x808fb396 at ithread_loop+0x96 #11 0x808f8b6a 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
Re: Problem with Atheros adapter (TP-LINK TL-WDN4800, AR9380)
If this would be easier on IRC, I'm BlueAidan on Freenode.
Output:
(kgdb) list *0x8045161d
0x8045161d is in ar9300_ani_ar_poll
(/usr/src/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_ani.c:1180).
1175 */
1176if (!DO_ANI(ah)) {
1177return;
1178}
1179
1180ofdm_phy_err_rate =
1181ani_state-ofdm_phy_err_count * 1000 /
ani_state-listen_time;
1182cck_phy_err_rate =
1183ani_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 *0x8045161d
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=
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:0x8045161d
stack pointer = 0x28:0xfe00e43bb760
frame pointer = 0x28:0xfe00e43bb7b0
code segment= base 0x0, limit 0xf, 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 0x80963000 at kdb_backtrace+0x60
#1 0x80928125 at panic+0x155
#2 0x80d24f1f at trap_fatal+0x38f
#3 0x80d24b7c at trap+0x75c
#4 0x80d0a782 at calltrap+0x8
#5 0x8045b248 at ar9300_ani_poll_freebsd+0x48
#6 0x804093d6 at ath_calibrate+0xf6
#7 0x8093d557 at softclock_call_cc+0x177
#8 0x8093d994 at softclock+0x94
#9 0x808faf4b at intr_event_execute_handlers+0xab
#10 0x808fb396 at ithread_loop+0x96
#11 0x808f8b6a 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
Re: Problem with Atheros adapter (TP-LINK TL-WDN4800, AR9380)
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 *0x8045161d
0x8045161d is in ar9300_ani_ar_poll
(/usr/src/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_ani.c:1180).
1175 */
1176if (!DO_ANI(ah)) {
1177return;
1178}
1179
1180ofdm_phy_err_rate =
1181ani_state-ofdm_phy_err_count * 1000 /
ani_state-listen_time;
1182cck_phy_err_rate =
1183ani_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 *0x8045161d
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=
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:0x8045161d
stack pointer = 0x28:0xfe00e43bb760
frame pointer = 0x28:0xfe00e43bb7b0
code segment= base 0x0, limit 0xf, 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 0x80963000 at kdb_backtrace+0x60
#1 0x80928125 at panic+0x155
#2 0x80d24f1f at trap_fatal+0x38f
#3 0x80d24b7c at trap+0x75c
#4 0x80d0a782 at calltrap+0x8
#5 0x8045b248 at ar9300_ani_poll_freebsd+0x48
#6 0x804093d6 at ath_calibrate+0xf6
#7 0x8093d557 at softclock_call_cc+0x177
#8 0x8093d994 at softclock+0x94
#9 0x808faf4b at intr_event_execute_handlers+0xab
#10 0x808fb396 at ithread_loop+0x96
#11 0x808f8b6a 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
Re: Problem with Atheros adapter (TP-LINK TL-WDN4800, AR9380)
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 *0x8045161d
0x8045161d is in ar9300_ani_ar_poll
(/usr/src/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_ani.c:1180).
1175 */
1176if (!DO_ANI(ah)) {
1177return;
1178}
1179
1180ofdm_phy_err_rate =
1181ani_state-ofdm_phy_err_count * 1000 /
ani_state-listen_time;
1182cck_phy_err_rate =
1183ani_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 *0x8045161d
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=
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:0x8045161d
stack pointer = 0x28:0xfe00e43bb760
frame pointer = 0x28:0xfe00e43bb7b0
code segment= base 0x0, limit 0xf, 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 0x80963000 at kdb_backtrace+0x60
#1 0x80928125 at panic+0x155
#2 0x80d24f1f at trap_fatal+0x38f
#3 0x80d24b7c at trap+0x75c
#4 0x80d0a782 at calltrap+0x8
#5 0x8045b248 at ar9300_ani_poll_freebsd+0x48
#6 0x804093d6 at ath_calibrate+0xf6
#7 0x8093d557 at softclock_call_cc+0x177
#8 0x8093d994 at softclock+0x94
#9 0x808faf4b at intr_event_execute_handlers+0xab
#10 0x808fb396 at ithread_loop+0x96
#11 0x808f8b6a 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
Re: Problem with Atheros adapter (TP-LINK TL-WDN4800, AR9380)
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 *0x8045161d
0x8045161d is in ar9300_ani_ar_poll
(/usr/src/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_ani.c:1180).
1175 */
1176if (!DO_ANI(ah)) {
1177return;
1178}
1179
1180ofdm_phy_err_rate =
1181ani_state-ofdm_phy_err_count * 1000 /
ani_state-listen_time;
1182cck_phy_err_rate =
1183ani_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 *0x8045161d
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=
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:0x8045161d
stack pointer = 0x28:0xfe00e43bb760
frame pointer = 0x28:0xfe00e43bb7b0
code segment= base 0x0, limit 0xf, 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 0x80963000 at kdb_backtrace+0x60
#1 0x80928125 at panic+0x155
#2 0x80d24f1f at trap_fatal+0x38f
#3 0x80d24b7c at trap+0x75c
#4 0x80d0a782 at calltrap+0x8
#5 0x8045b248 at ar9300_ani_poll_freebsd+0x48
#6 0x804093d6 at ath_calibrate+0xf6
#7 0x8093d557 at softclock_call_cc+0x177
#8 0x8093d994 at softclock+0x94
#9 0x808faf4b at intr_event_execute_handlers+0xab
#10 0x808fb396 at ithread_loop+0x96
#11 0x808f8b6a 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
