Re: ath not working after a motherboard and ram upgrade
does downgrading the motherboard/ram fix it? You were already running 64 bit, right? What if you just boot with 2gb of ram? adrian On 30 March 2013 18:04, Joshua Isom jri...@gmail.com wrote: I've been longing to upgrade my motherboard and ram, and with a tax refund it came time. The current kernel was working well enough for me, where the only ath problems were my antenna and harmless. After upgrading, 2Gb DDR2 to 32Gb DDR3, I've yet to get ath to be stable. The only system changes were motherboard, a cheap video card, and ram. There's periods where ath will work, then packet loss grows until it's unusable. When I scan, I can find the router, and when I'm connected I get an RSSI of 10.5 after I hung the antenna over the monitor, better than before. I'm getting a lot of kernel debug logs, but when I'm looking I can't notice anything specific. I still need to dig through the logs but I probably couldn't match up the logs with what I was doing at the time. What steps should I try to figure out why a motherboard and ram change would break the networking? ___ 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: ath not working after a motherboard and ram upgrade
I spoke too soon, it can still degrade, it's just takes longer to happen. This is with `ping -i .25 192.168.1.1` 64 bytes from 192.168.1.1: icmp_seq=743 ttl=64 time=1.595 ms 64 bytes from 192.168.1.1: icmp_seq=765 ttl=64 time=1.696 ms 64 bytes from 192.168.1.1: icmp_seq=771 ttl=64 time=3.118 ms 64 bytes from 192.168.1.1: icmp_seq=772 ttl=64 time=1.573 ms 64 bytes from 192.168.1.1: icmp_seq=778 ttl=64 time=1.796 ms 64 bytes from 192.168.1.1: icmp_seq=779 ttl=64 time=9222.495 ms 64 bytes from 192.168.1.1: icmp_seq=780 ttl=64 time=8967.619 ms 64 bytes from 192.168.1.1: icmp_seq=781 ttl=64 time=8701.003 ms 64 bytes from 192.168.1.1: icmp_seq=782 ttl=64 time=8434.659 ms 64 bytes from 192.168.1.1: icmp_seq=865 ttl=64 time=2.744 ms 64 bytes from 192.168.1.1: icmp_seq=871 ttl=64 time=1.548 ms 64 bytes from 192.168.1.1: icmp_seq=872 ttl=64 time=4.107 ms 64 bytes from 192.168.1.1: icmp_seq=873 ttl=64 time=1.570 ms 64 bytes from 192.168.1.1: icmp_seq=876 ttl=64 time=1.534 ms 64 bytes from 192.168.1.1: icmp_seq=900 ttl=64 time=1.530 ms 64 bytes from 192.168.1.1: icmp_seq=903 ttl=64 time=1.520 ms 64 bytes from 192.168.1.1: icmp_seq=904 ttl=64 time=6964.209 ms 64 bytes from 192.168.1.1: icmp_seq=905 ttl=64 time=6697.696 ms 64 bytes from 192.168.1.1: icmp_seq=906 ttl=64 time=7045.536 ms 64 bytes from 192.168.1.1: icmp_seq=907 ttl=64 time=6790.528 ms 64 bytes from 192.168.1.1: icmp_seq=908 ttl=64 time=6524.030 ms It'll be very stable, ping times of less than 2ms, then dropped packets and jumping up to high ping times. My messages file doesn't report anything noticeable other than losing network and regaining. On 3/31/2013 7:06 AM, Joshua Isom wrote: If I drop down to one 8Gb stick, and I don't have other wifi devices near causing interference, I can get a reliable connection and low loss. If I have 16Gb, I can get about a minute or two of decent ping times before it degrades to multi-second pings of the router. Even at 8Gb, it's not guaranteed on boot, but rebooting does seem to fix it. At 16Gb, I tried two different sticks just to see if maybe it was one bad chip but it didn't change it. That means it's probably an address conflict, or cache size issue, right? On 3/31/2013 1:25 AM, Adrian Chadd wrote: does downgrading the motherboard/ram fix it? You were already running 64 bit, right? What if you just boot with 2gb of ram? adrian ___ 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: ath not working after a motherboard and ram upgrade
If I drop down to one 8Gb stick, and I don't have other wifi devices near causing interference, I can get a reliable connection and low loss. If I have 16Gb, I can get about a minute or two of decent ping times before it degrades to multi-second pings of the router. Even at 8Gb, it's not guaranteed on boot, but rebooting does seem to fix it. At 16Gb, I tried two different sticks just to see if maybe it was one bad chip but it didn't change it. That means it's probably an address conflict, or cache size issue, right? On 3/31/2013 1:25 AM, Adrian Chadd wrote: does downgrading the motherboard/ram fix it? You were already running 64 bit, right? What if you just boot with 2gb of ram? adrian ___ 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: ath not working after a motherboard and ram upgrade
I tried updating today to the new code, it seemed to make it worse and never get decent ping times. With the code from before, it's dependent on boot, either it will work fine on boot or fail. But it has to be related to the handled npkts 0 message. When I'm getting no messages, it's perfect. The number and speed of the messages is the inverse of the network quality. When it's an intermittent loss, it degrades a couple seconds before the messages start. On 3/31/2013 7:06 AM, Joshua Isom wrote: If I drop down to one 8Gb stick, and I don't have other wifi devices near causing interference, I can get a reliable connection and low loss. If I have 16Gb, I can get about a minute or two of decent ping times before it degrades to multi-second pings of the router. Even at 8Gb, it's not guaranteed on boot, but rebooting does seem to fix it. At 16Gb, I tried two different sticks just to see if maybe it was one bad chip but it didn't change it. That means it's probably an address conflict, or cache size issue, right? On 3/31/2013 1:25 AM, Adrian Chadd wrote: does downgrading the motherboard/ram fix it? You were already running 64 bit, right? What if you just boot with 2gb of ram? adrian ___ 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: ath not working after a motherboard and ram upgrade
... that message is because it's scanning. :-) Try booting it with only 2GB of physical RAM. It may be something odd to do with how the DMA code works; the ath NIC is a 32 bit PCI device. I need to make sure it's totally 64 bit clean - not only 64 bit pointer clean, but all the mbufs need to be in the lower 32 bits of physical memory :) Adrian On 31 March 2013 08:25, Joshua Isom jri...@gmail.com wrote: I tried updating today to the new code, it seemed to make it worse and never get decent ping times. With the code from before, it's dependent on boot, either it will work fine on boot or fail. But it has to be related to the handled npkts 0 message. When I'm getting no messages, it's perfect. The number and speed of the messages is the inverse of the network quality. When it's an intermittent loss, it degrades a couple seconds before the messages start. On 3/31/2013 7:06 AM, Joshua Isom wrote: If I drop down to one 8Gb stick, and I don't have other wifi devices near causing interference, I can get a reliable connection and low loss. If I have 16Gb, I can get about a minute or two of decent ping times before it degrades to multi-second pings of the router. Even at 8Gb, it's not guaranteed on boot, but rebooting does seem to fix it. At 16Gb, I tried two different sticks just to see if maybe it was one bad chip but it didn't change it. That means it's probably an address conflict, or cache size issue, right? On 3/31/2013 1:25 AM, Adrian Chadd wrote: does downgrading the motherboard/ram fix it? You were already running 64 bit, right? What if you just boot with 2gb of ram? adrian ___ 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: ath not working after a motherboard and ram upgrade
I switched it to 4Gb shortly after you mentioned 32 bit pci. I've been using amd64 for so long I forgot about 32 bit memory limits. On 3/31/2013 1:38 PM, Adrian Chadd wrote: On 31 March 2013 10:49, Joshua Isom jri...@gmail.com wrote: I seems someone working on the kernel's already figured out how to deal with this. The hw.physmem sysctl can be set at boot time, with 2Gb it seems to be working fine. I reinstalled all the sticks, and it's working fine with the sysctl set to 2Gb. Ooo Yay! I mean, damn, that's busted. But yay, now we can narrow down what the problem is! Try bumping it to 4GB. It should be fine at that. If it is, please create a PR with all the above information and I'll start re-reviewing the DMA / buffer code to see what's going on. Thanks! Adrian ___ 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: ath not working after a motherboard and ram upgrade
From if_ath.c:2995: For some situations (eg EDMA TX completion), there isn't a requirement for the ath_buf entries to be allocated. The EDMA code uses malloc, but would contigmalloc work instead? On 3/31/2013 1:38 PM, Adrian Chadd wrote: On 31 March 2013 10:49, Joshua Isom jri...@gmail.com wrote: I seems someone working on the kernel's already figured out how to deal with this. The hw.physmem sysctl can be set at boot time, with 2Gb it seems to be working fine. I reinstalled all the sticks, and it's working fine with the sysctl set to 2Gb. Ooo Yay! I mean, damn, that's busted. But yay, now we can narrow down what the problem is! Try bumping it to 4GB. It should be fine at that. If it is, please create a PR with all the above information and I'll start re-reviewing the DMA / buffer code to see what's going on. Thanks! Adrian ___ 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
Suggested hardware
Hi. I'm looking to get a netbook or small laptop for FreeBSD. I've only run it on servers and desktops in the past, so I'm unsure about some of the hardware requirements. I'd like to be able to connect to wifi with no auth, wep, wpa and wpa2 and be able to fully utilize the aircrack-ng suite of tools. I need regular wifi, monitor mode/ahdemo and packet injection working. Thankfully I saw this PR was added to the port: https://www.freebsd.org/cgi/query-pr.cgi?pr=ports/160564 Any suggestions for either a netbook or an add-on (usb maybe?) wireless card would be greatly appreciated, thanks. ___ 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: [rft] ar9300 HAL updated
Joshua Isom jri...@gmail.com writes: On 3/31/2013 9:49 AM, Raphael Kubo da Costa wrote: The first error I got was in ar9300_radio.c:90 -- clang complained `ichan' was not being used. I keep forgetting about this, but if you open the file go to line 89 and change the ifdef to '#if 0' it'll compile. Yeah, I did something similar and compilation went a little bit further. Also, for your kernel config, generic won't work. Comment out the device lines for ath, ath_pci, and ath_hal. Three options need added, so it'll look like this. Gah, thanks for reminding me about removing those `device' entries from my kernel configuration. I build my kernel as a diff against GENERIC [1], and this is what I'm currently using (the rest of the options are already present in GENERIC): # For the experimental AR9485 support. options ATH_DEBUG options AH_DEBUG options ATH_DIAGAPI nodeviceath nodeviceath_pci nodeviceath_hal nodeviceath_rate_sample [1] http://www.wonkity.com/~wblock/docs/html/kernelconfig.html Anyway, I'm still stuck at those other warnings/errors I posted before. ___ 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: ath not working after a motherboard and ram upgrade
The problem isn't contigmalloc, it's making sure that it gets bounced via the local 32 bits of address space right. I'll talk with other developers and see what the deal is with 64 bit address space for 32 bit nics. Thanks, Adrian Sent from my Palm Pre on ATamp;T On Mar 31, 2013 3:47 PM, Joshua Isom lt;jri...@gmail.comgt; wrote: From if_ath.c:2995: For some situations (eg EDMA TX completion), there isn't a requirement for the ath_buf entries to be allocated. The EDMA code uses malloc, but would contigmalloc work instead? On 3/31/2013 1:38 PM, Adrian Chadd wrote: gt; On 31 March 2013 10:49, Joshua Isom lt;jri...@gmail.comgt; wrote: gt;gt; I seems someone working on the kernel's already figured out how to deal with gt;gt; this. The hw.physmem sysctl can be set at boot time, with 2Gb it seems to gt;gt; be working fine. I reinstalled all the sticks, and it's working fine with gt;gt; the sysctl set to 2Gb. gt; gt; Ooo Yay! I mean, damn, that's busted. But yay, now we can narrow gt; down what the problem is! gt; gt; Try bumping it to 4GB. It should be fine at that. gt; gt; If it is, please create a PR with all the above information and I'll gt; start re-reviewing the DMA / buffer code to see what's going on. gt; gt; Thanks! gt; gt; gt; gt; gt; Adrian gt; ___ 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: [rft] ar9300 HAL updated
Look in ath/makefile .. At the bottom. There's clang warning overrides there. Uncomment them! Adrian Sent from my Palm Pre on ATamp;T On Mar 31, 2013 11:54 AM, Raphael Kubo da Costa lt;rak...@freebsd.orggt; wrote: Adrian Chadd lt;adr...@freebsd.orggt; writes: gt; I've just updated the AR9300 HAL to the March 13 snapshot from QCA. gt; gt; This includes calibration and TX power calibration changes that may gt; improve stability. gt; gt; As always, it's possible I broke something! gt; gt; I'd appreciate it if people would test this in STA and AP mode. I'm at r248944 here using HEAD. After checking out the code, I created the expected symlinks at the new contrib/ location (BTW, are you sure you want sys/contrib/sys/dev/ath instead of sys/contrib/dev/ath, which seems to be the chosen location for other modules?). The first error I got was in ar9300_radio.c:90 -- clang complained `ichan' was not being used. It is now failing like this: cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/usr/src/sys/modules/ath/../.. /dev/ath -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I. -I/usr/src/sys/modules/ath/../../contrib/sys/dev/a th/ath_hal/ -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/ORWELL/opt_global.h -I. -I@ -I@/contrib/a ltq -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/ORWELL -mno-aes -mno-avx -mcmodel=kernel -mno -red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std= iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmiss ing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-pa rentheses-equality -c /usr/src/sys/modules/ath/../../contrib/sys/dev/ath/ath_hal/ar9300/ar9300_eeprom.c In file included from /usr/src/sys/modules/ath/../../contrib/sys/dev/ath/ath_hal/ar9300/ar9300_eeprom.c:27: /usr/src/sys/modules/ath/../../contrib/sys/dev/ath/ath_hal/ar9300/ar9300template_generic.h:113:3: error: implicit conversion from 'int' to 'u_int8_t' (aka 'unsigned char') changes value from -477 to 35 [-Werror,-Wconstant-conversion] FREQ2FBIN(2412, 1), ^~ /usr/src/sys/modules/ath/../../contrib/sys/dev/ath/ath_hal/ar9300/ar9300eep.h:142:65: note: expanded from macro 'FREQ2FBIN' (((y) == HAL_FREQ_BAND_2GHZ) ? ((x) - 2300) : (((x) - 4800) / 5)) ~^~~ The error message is repeated multiple times (one for each FREQ2FBIN call). ___ 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: kern/177465: [iwn] 20%-100% packet loss with iwn driver
Old Synopsis: 20%-100% packet loss with iwn driver New Synopsis: [iwn] 20%-100% packet loss with iwn driver Responsible-Changed-From-To: freebsd-bugs-freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Sun Mar 31 23:03:19 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177465 ___ 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: Suggested hardware
Hi, On Sun, 31 Mar 2013 19:55:46 - s...@tormail.org wrote: Hi. I'm looking to get a netbook or small laptop for FreeBSD. I've only run it on servers and desktops in the past, so I'm unsure about some of the hardware requirements. I'd like to be able to connect to wifi with no auth, wep, wpa and wpa2 and be able to fully utilize the aircrack-ng suite of tools. I need regular wifi, monitor mode/ahdemo and packet injection working. Thankfully I saw this PR was added to the port: https://www.freebsd.org/cgi/query-pr.cgi?pr=ports/160564 Any suggestions for either a netbook or an add-on (usb maybe?) wireless card would be greatly appreciated, thanks. with netbook you mean the low-cost machines? Lenovo was a good pick for me. Erich ___ 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: Suggested hardware
.. anything with an Atheros PCI/PCIe chipset will work. The only chipset I don't have support for atm is: * AR5523, but i doubt you'll ever see this unless you still use cardbus; * QCA9880 and derivates (11ac) - but that won't work at the moment and likely won't do raw injection more for aircrack any time soon. If there are bugs with ahdemo/packet injection then please file bugs and participate on freebsd-wireless. I don't have time to debug that stuff at the moment but I'd love to see ti work. Thanks! Adrian On 31 March 2013 17:37, Erich Dollansky er...@alogt.com wrote: Hi, On Sun, 31 Mar 2013 19:55:46 - s...@tormail.org wrote: Hi. I'm looking to get a netbook or small laptop for FreeBSD. I've only run it on servers and desktops in the past, so I'm unsure about some of the hardware requirements. I'd like to be able to connect to wifi with no auth, wep, wpa and wpa2 and be able to fully utilize the aircrack-ng suite of tools. I need regular wifi, monitor mode/ahdemo and packet injection working. Thankfully I saw this PR was added to the port: https://www.freebsd.org/cgi/query-pr.cgi?pr=ports/160564 Any suggestions for either a netbook or an add-on (usb maybe?) wireless card would be greatly appreciated, thanks. with netbook you mean the low-cost machines? Lenovo was a good pick for me. Erich ___ 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
