Re: please (re) test if_ath in -HEAD
On Thu 03 March 2011 at 02:31:05PM -0800, Adrian Chadd wrote: Hi all, For those of you who are testing out my if_ath changes, I'd really appreciate it if you'd update to -HEAD and re-test. I've done a variety of changes to the radio setup and found/fixed a few bugs in the TX path. It's quite possible these have introduced regressions. I'd like to make sure that I haven't broken legacy (11abg) support in weird/wonderful ways. I'd also like to make sure that I haven't broken/changed the behaviour or performance of the NICs in any way. Please give things a good thrashing and let me know the results. I'm still working towards debugging and enabling basic 11n support, but I need to first make sure that I haven't broken legacy operation in any way. Are you interested by tests on an old atheros card (Atheros 5212, AR2413 mac 7.9 RF2413 phy 4.5) ? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: em0 with latest driver hangs again and again (without Watchdogtimeout message!)
Hello, Steven. You wrote 5 марта 2011 г., 3:06:32: Silly question but have you checked your ram for issues, we had a machine with seemingly unexplained problems and hangs and it turned out to be a duff stick of ram which wasn't being chip killed. Yes, two full days (48h) of memtest86+ -- no problems... -- // Black Lion AKA Lev Serebryakov l...@serebryakov.spb.ru ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: please (re) test if_ath in -HEAD
Absolutely! Let me know if I've broken anything! Adrian On 5 March 2011 00:45, Urankar Mikael mikael.uran...@ujf-grenoble.frwrote: On Thu 03 March 2011 at 02:31:05PM -0800, Adrian Chadd wrote: Hi all, For those of you who are testing out my if_ath changes, I'd really appreciate it if you'd update to -HEAD and re-test. I've done a variety of changes to the radio setup and found/fixed a few bugs in the TX path. It's quite possible these have introduced regressions. I'd like to make sure that I haven't broken legacy (11abg) support in weird/wonderful ways. I'd also like to make sure that I haven't broken/changed the behaviour or performance of the NICs in any way. Please give things a good thrashing and let me know the results. I'm still working towards debugging and enabling basic 11n support, but I need to first make sure that I haven't broken legacy operation in any way. Are you interested by tests on an old atheros card (Atheros 5212, AR2413 mac 7.9 RF2413 phy 4.5) ? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/155177: [route] [panic] Panic when inject routes in kernel
The following reply was made to PR kern/155177; it has been noted by GNATS. From: Luiz Otavio O Souza lists...@gmail.com To: Eduardo Schoedler eschoed...@gmail.com Cc: bug-follo...@freebsd.org, freebsd-net@FreeBSD.org Subject: Re: kern/155177: [route] [panic] Panic when inject routes in kernel Date: Sat, 5 Mar 2011 10:18:56 -0300 --Apple-Mail-135-1048872824 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 4, 2011, at 9:10 AM, Eduardo Schoedler wrote: Hello, =20 I've found another (easy) way to reproduce the problem with two = scripts: routes-add.sh and routes-remove.sh. First run routes-add.sh for a while; then execute routes-remove.sh. Cancel with CTRL+C and execute routes-remove.sh again. =20 snip Hi Eduardo, I've found another problem while trying something like you'd proposed, = but it can be easily reproduced by just trying to remove a network route = that is not in the table (probably what your script does when you press = ctrl+c and restart it). The problem i've found produces the following backtrace: #0 doadump () at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:244 #1 0xc04d7de9 in db_fncall (dummy1=3D1, dummy2=3D0, dummy3=3D-1056933504,= =20 dummy4=3D0xe69ee798 ) at /usr/src/sys/ddb/db_command.c:548 #2 0xc04d81e1 in db_command (last_cmdp=3D0xc0e303dc, cmd_table=3D0x0, = dopager=3D1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04d833a in db_command_loop () at = /usr/src/sys/ddb/db_command.c:498 #4 0xc04da25d in db_trap (type=3D3, code=3D0) at = /usr/src/sys/ddb/db_main.c:229 #5 0xc0902672 in kdb_trap (type=3D3, code=3D0, tf=3D0xe69ee948) at /usr/src/sys/kern/subr_kdb.c:533 #6 0xc0c137bb in trap (frame=3D0xe69ee948) at = /usr/src/sys/i386/i386/trap.c:717 #7 0xc0bfc7ec in calltrap () at /usr/src/sys/i386/i386/exception.s:168 #8 0xc09024fa in kdb_enter (why=3D0xc0ce86fa panic, msg=3D0xc0ce86fa = panic) at cpufunc.h:71 #9 0xc08cea24 in panic (fmt=3D0xc0cfedcb radix node disappeared) at /usr/src/sys/kern/kern_shutdown.c:574 #10 0xc0996900 in rtrequest1_fib (req=3D2, info=3D0xe69eea50, = ret_nrt=3D0xe69eea84,=20 fibnum=3DVariable fibnum is not available. ) at /usr/src/sys/net/route.c:968 #11 0xc099abbd in route_output (m=3D0xc43a6b00, so=3D0xc48b) at /usr/src/sys/net/rtsock.c:630 #12 0xc09959da in raw_usend (so=3D0xc48b, flags=3DVariable flags = is not available. ) at /usr/src/sys/net/raw_usrreq.c:228 #13 0xc0999275 in rts_send (so=3D0xc48b, flags=3D0, m=3D0xc43a6b00, = nam=3D0x0,=20 control=3D0x0, td=3D0xc49d18a0) at /usr/src/sys/net/rtsock.c:354 #14 0xc093ceed in sosend_generic (so=3D0xc48b, addr=3D0x0, = uio=3D0xe69eec28,=20 top=3D0xc43a6b00, control=3D0x0, flags=3D0, td=3D0xc49d18a0) at /usr/src/sys/kern/uipc_socket.c:1301 #15 0xc0938ddf in sosend (so=3D0xc48b, addr=3D0x0, uio=3D0xe69eec28, = top=3D0x0,=20 control=3D0x0, flags=3D0, td=3D0xc49d18a0) at /usr/src/sys/kern/uipc_socket.c:1345 #16 0xc0920ae3 in soo_write (fp=3D0xc4690d58, uio=3D0xe69eec28,=20 active_cred=3D0xc47e8e00, flags=3D0, td=3D0xc49d18a0) at /usr/src/sys/kern/sys_socket.c:100 #17 0xc0919a65 in dofilewrite (td=3D0xc49d18a0, fd=3D3, fp=3D0xc4690d58,=20= auio=3D0xe69eec28, offset=3D-1, flags=3D0) at file.h:238 #18 0xc091b208 in kern_writev (td=3D0xc49d18a0, fd=3D3, auio=3D0xe69eec28)= at /usr/src/sys/kern/sys_generic.c:447 #19 0xc091b31f in write (td=3D0xc49d18a0, uap=3D0xe69eecec) at /usr/src/sys/kern/sys_generic.c:363 #20 0xc090fda3 in syscallenter (td=3D0xc49d18a0, sa=3D0xe69eece4) at /usr/src/sys/kern/subr_trap.c:344 #21 0xc0c13064 in syscall (frame=3D0xe69eed28) at /usr/src/sys/i386/i386/trap.c:1080 #22 0xc0bfc851 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266 #23 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)=20 Are you sure that your scripts produce the backtrace you'd posted ? I = cannot reproduce that here... Well, about the problem i've found (radix node disappeared) when = removing a nonexistent route (route delete x.y.w.z/24 - where x.y.w.z/24 = is _not_ in the route table), it was related to the code that check for = a gateway when there are multiple gateways for a route, which clearly = was not the case. After some thought i've crafted the following patch which fix the radix = node disappeared problem (for me obviously...), can you try your = scripts with this patch ? Not sure yet if this is related to the first = problem you'd reported. Thanks, Luiz --Apple-Mail-135-1048872824 Content-Disposition: attachment; filename=radix_remove_gateway.diff Content-Type: application/octet-stream; name=radix_remove_gateway.diff Content-Transfer-Encoding: 7bit Index: sys/net/route.c
Re: please (re) test if_ath in -HEAD
On Thu, Mar 3, 2011 at 19:31, Adrian Chadd adrian.ch...@gmail.com wrote: Hi all, For those of you who are testing out my if_ath changes, I'd really appreciate it if you'd update to -HEAD and re-test. I've done a variety of changes to the radio setup and found/fixed a few bugs in the TX path. It's quite possible these have introduced regressions. I'd like to make sure that I haven't broken legacy (11abg) support in weird/wonderful ways. I'd also like to make sure that I haven't broken/changed the behaviour or performance of the NICs in any way. Please give things a good thrashing and let me know the results. I'm still working towards debugging and enabling basic 11n support, but I need to first make sure that I haven't broken legacy operation in any way. Hi Adrian. I compiled your changes and everything worked. I'm using hostapd with WEP key. My kernel/world is compiled with clang. Is there any kind of test that I can do for you? There is still a annoying message, but it existed before your update: ath0: stuck beacon; resetting (bmiss count 4) - BARAD-DUR# uname -a FreeBSD BARAD-DUR 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r219303: Sat Mar 5 09:16:19 BRT 2011 root@BARAD-DUR:/usr/clang/obj/mnt/data/system/src/sys/GENERIC amd64 BARAD-DUR# dmesg| grep -i ath ath0: Atheros 5212 mem 0xfd8f-0xfd8f irq 16 at device 7.0 on pci1 ath0: AR2413 mac 7.9 RF2413 phy 4.5 ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) BARAD-DUR# ifconfig ath0 ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:19:e0:8a:0a:d6 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running Thanks, Adrian ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Marcelo Rossi This e-mail is provided AS IS with no warranties, and confers no rights. I have nothing against God, I just hate His fan club ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/155177: [route] [panic] Panic when inject routes in kernel
On Mar 4, 2011, at 9:10 AM, Eduardo Schoedler wrote: Hello, I've found another (easy) way to reproduce the problem with two scripts: routes-add.sh and routes-remove.sh. First run routes-add.sh for a while; then execute routes-remove.sh. Cancel with CTRL+C and execute routes-remove.sh again. snip Hi Eduardo, I've found another problem while trying something like you'd proposed, but it can be easily reproduced by just trying to remove a network route that is not in the table (probably what your script does when you press ctrl+c and restart it). The problem i've found produces the following backtrace: #0 doadump () at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:244 #1 0xc04d7de9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1056933504, dummy4=0xe69ee798 ) at /usr/src/sys/ddb/db_command.c:548 #2 0xc04d81e1 in db_command (last_cmdp=0xc0e303dc, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc04d833a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04da25d in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc0902672 in kdb_trap (type=3, code=0, tf=0xe69ee948) at /usr/src/sys/kern/subr_kdb.c:533 #6 0xc0c137bb in trap (frame=0xe69ee948) at /usr/src/sys/i386/i386/trap.c:717 #7 0xc0bfc7ec in calltrap () at /usr/src/sys/i386/i386/exception.s:168 #8 0xc09024fa in kdb_enter (why=0xc0ce86fa panic, msg=0xc0ce86fa panic) at cpufunc.h:71 #9 0xc08cea24 in panic (fmt=0xc0cfedcb radix node disappeared) at /usr/src/sys/kern/kern_shutdown.c:574 #10 0xc0996900 in rtrequest1_fib (req=2, info=0xe69eea50, ret_nrt=0xe69eea84, fibnum=Variable fibnum is not available. ) at /usr/src/sys/net/route.c:968 #11 0xc099abbd in route_output (m=0xc43a6b00, so=0xc48b) at /usr/src/sys/net/rtsock.c:630 #12 0xc09959da in raw_usend (so=0xc48b, flags=Variable flags is not available. ) at /usr/src/sys/net/raw_usrreq.c:228 #13 0xc0999275 in rts_send (so=0xc48b, flags=0, m=0xc43a6b00, nam=0x0, control=0x0, td=0xc49d18a0) at /usr/src/sys/net/rtsock.c:354 #14 0xc093ceed in sosend_generic (so=0xc48b, addr=0x0, uio=0xe69eec28, top=0xc43a6b00, control=0x0, flags=0, td=0xc49d18a0) at /usr/src/sys/kern/uipc_socket.c:1301 #15 0xc0938ddf in sosend (so=0xc48b, addr=0x0, uio=0xe69eec28, top=0x0, control=0x0, flags=0, td=0xc49d18a0) at /usr/src/sys/kern/uipc_socket.c:1345 #16 0xc0920ae3 in soo_write (fp=0xc4690d58, uio=0xe69eec28, active_cred=0xc47e8e00, flags=0, td=0xc49d18a0) at /usr/src/sys/kern/sys_socket.c:100 #17 0xc0919a65 in dofilewrite (td=0xc49d18a0, fd=3, fp=0xc4690d58, auio=0xe69eec28, offset=-1, flags=0) at file.h:238 #18 0xc091b208 in kern_writev (td=0xc49d18a0, fd=3, auio=0xe69eec28) at /usr/src/sys/kern/sys_generic.c:447 #19 0xc091b31f in write (td=0xc49d18a0, uap=0xe69eecec) at /usr/src/sys/kern/sys_generic.c:363 #20 0xc090fda3 in syscallenter (td=0xc49d18a0, sa=0xe69eece4) at /usr/src/sys/kern/subr_trap.c:344 #21 0xc0c13064 in syscall (frame=0xe69eed28) at /usr/src/sys/i386/i386/trap.c:1080 #22 0xc0bfc851 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266 #23 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Are you sure that your scripts produce the backtrace you'd posted ? I cannot reproduce that here... Well, about the problem i've found (radix node disappeared) when removing a nonexistent route (route delete x.y.w.z/24 - where x.y.w.z/24 is _not_ in the route table), it was related to the code that check for a gateway when there are multiple gateways for a route, which clearly was not the case. After some thought i've crafted the following patch which fix the radix node disappeared problem (for me obviously...), can you try your scripts with this patch ? Not sure yet if this is related to the first problem you'd reported. Thanks, Luiz radix_remove_gateway.diff Description: Binary data Backtrace: == # cat /var/crash/core.txt.1 snip Unread portion of the kernel message buffer: panic: rtfree 2 cpuid = 4 KDB: stack backtrace: #0 0x80416e43 at kdb_backtrace+0x5e #1 0x803e68a8 at panic+0x182 #2 0x804b2274 at rtalloc1_fib+0 #3 0x804b5b92 at route_output+0x304 #4 0x8044b776 at sosend_generic+0x366 #5 0x8042cd5c at soo_write+0x54 #6 0x80425bee at dofilewrite+0x7a #7 0x80425ec1 at kern_writev+0x52 #8 0x80425f3f at write+0x4e #9 0x80422408 at syscallenter+0x186 #10 0x8065b4f7 at syscall+0x40 #11 0x806449f2 at Xfast_syscall+0xe2 Uptime: 37m16s Physical memory: 4084 MB Dumping 497 MB:VOP_STRATEGY: bp is not locked but should be 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 #0 doadump () at pcpu.h:224 224 pcpu.h: No such file or directory.
Re: please (re) test if_ath in -HEAD
On Sat 05 March 2011 at 03:27:48AM -0800, Adrian Chadd wrote: Absolutely! Let me know if I've broken anything! Adrian On 5 March 2011 00:45, Urankar Mikael mikael.uran...@ujf-grenoble.frwrote: On Thu 03 March 2011 at 02:31:05PM -0800, Adrian Chadd wrote: Hi all, For those of you who are testing out my if_ath changes, I'd really appreciate it if you'd update to -HEAD and re-test. I've done a variety of changes to the radio setup and found/fixed a few bugs in the TX path. It's quite possible these have introduced regressions. I'd like to make sure that I haven't broken legacy (11abg) support in weird/wonderful ways. I'd also like to make sure that I haven't broken/changed the behaviour or performance of the NICs in any way. Please give things a good thrashing and let me know the results. I'm still working towards debugging and enabling basic 11n support, but I need to first make sure that I haven't broken legacy operation in any way. Are you interested by tests on an old atheros card (Atheros 5212, AR2413 mac 7.9 RF2413 phy 4.5) ? Everything seems to work fine, performances are as good as before. I'm only doing basic stuff with this card (mostly web surfing), I'm connected to an AP with WPA encryption. If you want me to test other encryption or setup an AP with this card or whatever, feel free to ask. And thanks for you work ! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
ifconfig lo1 down
Hi, I would like to know what is the differents between ip4 and ip6 for this command. First: #ifconfig lo1 lo1: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet xx.xx.xx.2 netmask 0x inet6 2a03:::::xx02 prefixlen 128 nd6 options=3PERFORMNUD,ACCEPT_RTADV $ ping xx.xx.xx.2 PING xx.xx.xx.2 (xx.xx.xx.2): 56 data bytes 64 bytes from xx.xx.xx.2: icmp_seq=0 ttl=64 time=0.012 ms 64 bytes from xx.xx.xx.2: icmp_seq=1 ttl=64 time=0.010 ms ^C and $ ping6 2a03:::::xx02 PING6(56=40+8+8 bytes) 2a03:::::xx02 -- 2a03:::::xx02 16 bytes from 2a03:::::xx02, icmp_seq=0 hlim=64 time=0.053 ms 16 bytes from 2a03:::::xx02, icmp_seq=1 hlim=64 time=0.032 ms ^C Now we run this command: # ifconfig lo1 down and trying to ping again: $ ping xx.xx.xx.2 PING xx.xx.xx.2 (xx.xx.xx.2): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host ^C --- xx.xx.xx.2 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss works as expected (and this is what I want) but this command, however: $ ping6 2a03:::::xx02 PING6(56=40+8+8 bytes) 2a03:::::xx02 -- 2a03:::::xx02 16 bytes from 2a03:::::xx02, icmp_seq=0 hlim=64 time=0.048 ms 16 bytes from 2a03:::::xx02, icmp_seq=1 hlim=64 time=0.033 ms 16 bytes from 2a03:::::xx02, icmp_seq=2 hlim=64 time=0.032 ms ^C --- 2a03:::::xx02 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.032/0.038/0.048/0.007 ms My question is why is it not the same behavior of ip6 as of ip4? -- //fredan ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ifconfig lo1 down
On 5 March 2011 21:43, fredrik danerklint fre...@fredan.se wrote: Hi, I would like to know what is the differents between ip4 and ip6 for this command. First: #ifconfig lo1 lo1: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet xx.xx.xx.2 netmask 0x inet6 2a03:::::xx02 prefixlen 128 nd6 options=3PERFORMNUD,ACCEPT_RTADV $ ping xx.xx.xx.2 PING xx.xx.xx.2 (xx.xx.xx.2): 56 data bytes 64 bytes from xx.xx.xx.2: icmp_seq=0 ttl=64 time=0.012 ms 64 bytes from xx.xx.xx.2: icmp_seq=1 ttl=64 time=0.010 ms ^C and $ ping6 2a03:::::xx02 PING6(56=40+8+8 bytes) 2a03:::::xx02 -- 2a03:::::xx02 16 bytes from 2a03:::::xx02, icmp_seq=0 hlim=64 time=0.053 ms 16 bytes from 2a03:::::xx02, icmp_seq=1 hlim=64 time=0.032 ms ^C Now we run this command: # ifconfig lo1 down and trying to ping again: $ ping xx.xx.xx.2 PING xx.xx.xx.2 (xx.xx.xx.2): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host ^C --- xx.xx.xx.2 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss works as expected (and this is what I want) but this command, however: $ ping6 2a03:::::xx02 PING6(56=40+8+8 bytes) 2a03:::::xx02 -- 2a03:::::xx02 16 bytes from 2a03:::::xx02, icmp_seq=0 hlim=64 time=0.048 ms 16 bytes from 2a03:::::xx02, icmp_seq=1 hlim=64 time=0.033 ms 16 bytes from 2a03:::::xx02, icmp_seq=2 hlim=64 time=0.032 ms ^C --- 2a03:::::xx02 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.032/0.038/0.048/0.007 ms My question is why is it not the same behavior of ip6 as of ip4? That's how forwarding works/differs for ipv4 and ipv6. You should be able to ping xx.xx.xx.2 again after adding static route. Something like route add xx.xx.xx.2 -iface -lo1. I can only say for the moment that from my observation ipv4 routes to itself exist as far as interface is up, and ipv6 routes don't depend on if iface is up. You can check this with netstat -r for both addresses with iface up and down. -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Proposed patch for Port Randomization modifications according to RFC6056
On 03/04/2011 16:21, Bjoern A. Zeeb wrote: That said I messed with the patch to avoid the two copies of the algorithms (so it will not be 4 soon). I know it compiles but I have yet to test it. I'd love to hear opinions. The #ifdef INET6/INETs are ugly but we'll see those a lot more and need to figure out differnt ways to our code was written the last 10 years. http://people.freebsd.org/~bz/20110303-01-rfc6056.diff The patch also includes a bugfix for the ipv6 case wrt to un-binding on error. I'm now using this version of the patch with alg 4 and it's working fine. Thanks! Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: please (re) test if_ath in -HEAD
What was the previous performance? And which chipsets? Adrian On 6 March 2011 00:30, Urankar Mikael mikael.uran...@ujf-grenoble.frwrote: On Sat 05 March 2011 at 03:27:48AM -0800, Adrian Chadd wrote: Absolutely! Let me know if I've broken anything! Adrian On 5 March 2011 00:45, Urankar Mikael mikael.uran...@ujf-grenoble.fr wrote: On Thu 03 March 2011 at 02:31:05PM -0800, Adrian Chadd wrote: Hi all, For those of you who are testing out my if_ath changes, I'd really appreciate it if you'd update to -HEAD and re-test. I've done a variety of changes to the radio setup and found/fixed a few bugs in the TX path. It's quite possible these have introduced regressions. I'd like to make sure that I haven't broken legacy (11abg) support in weird/wonderful ways. I'd also like to make sure that I haven't broken/changed the behaviour or performance of the NICs in any way. Please give things a good thrashing and let me know the results. I'm still working towards debugging and enabling basic 11n support, but I need to first make sure that I haven't broken legacy operation in any way. Are you interested by tests on an old atheros card (Atheros 5212, AR2413 mac 7.9 RF2413 phy 4.5) ? Everything seems to work fine, performances are as good as before. I'm only doing basic stuff with this card (mostly web surfing), I'm connected to an AP with WPA encryption. If you want me to test other encryption or setup an AP with this card or whatever, feel free to ask. And thanks for you work ! ___ freebsd-mob...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-mobile To unsubscribe, send any mail to freebsd-mobile-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/155142: [vr] vr0 without mac address
Old Synopsis: vr0 without mac address New Synopsis: [vr] vr0 without mac address Responsible-Changed-From-To: freebsd-i386-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 5 22:11:07 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=155142 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/155142: [vr] vr0 without mac address
Synopsis: [vr] vr0 without mac address State-Changed-From-To: open-feedback State-Changed-By: yongari State-Changed-When: Sat Mar 5 23:56:00 UTC 2011 State-Changed-Why: Would you show me full dmesg(8) output of your box? vr(4) was not touched for a long time so what is the last known FreeBSD release that used to get correct station address on your vr(4) controller? BTW, the FreeBSD's way to change the station address of controller is to create a file in /etc directory with name start_if.$INTERFACE_NAME. In other words, create a file with /etc/start_if.vr0 and put the following content into the file. # ifconfig vr0 ether 00:01:02:03:04:05 These entries are read by sh(1) and executed before configuring the interface. See rc.conf(5) for more information. Responsible-Changed-From-To: freebsd-net-yongari Responsible-Changed-By: yongari Responsible-Changed-When: Sat Mar 5 23:56:00 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=155142 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
