Re: networking in 14.1 release notes
On 5/20/2024 11:54 AM, Mike Karels wrote: That sounds like an outright bug. Looks like it was true in 14.0 as well. Is there a bug report? I couldn't find one. I didnt open one. Wasnt sure if it the change was a deliberate one or on the wrong side of POLA. To me it feels unnecessary to have only one order of params but I might be missing the rational behind it. Shall I open a PR ? Yes, please. I looked into it yesterday; it looks accidental. I'll follow up. Thanks Mike! PR opened https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279181 ---Mike
Re: networking in 14.1 release notes
On 5/19/2024 8:59 PM, Mike Karels wrote: On 19 May 2024, at 18:29, mike tancsa wrote: On 5/18/2024 10:49 AM, Mike Karels wrote: I have no networking changes at all in the 14.1 release notes. Is there anything that should be mentioned? Feel free to reply to me individually. Not sure if appropriate or not, but when going to 13.x to 14.x, not all vlan configs work now in rc.conf Both ifconfig_vlan2="192.168.1.51/24 vlandev igb1 vlan 2" ifconfig_vlan2="192.168.1.51/24 vlan 2 vlandev igb1" used to work on RELENG_13 now only ifconfig_vlan2="192.168.1.51/24 vlan 2 vlandev igb1" is allowed. Maybe a heads up in UPDATING ? That sounds like an outright bug. Looks like it was true in 14.0 as well. Is there a bug report? I couldn't find one. I didnt open one. Wasnt sure if it the change was a deliberate one or on the wrong side of POLA. To me it feels unnecessary to have only one order of params but I might be missing the rational behind it. Shall I open a PR ? --Mike btw, UPDATING is meant for upgrades from source. Mike
Re: networking in 14.1 release notes
On 5/18/2024 10:49 AM, Mike Karels wrote: I have no networking changes at all in the 14.1 release notes. Is there anything that should be mentioned? Feel free to reply to me individually. Not sure if appropriate or not, but when going to 13.x to 14.x, not all vlan configs work now in rc.conf Both ifconfig_vlan2="192.168.1.51/24 vlandev igb1 vlan 2" ifconfig_vlan2="192.168.1.51/24 vlan 2 vlandev igb1" used to work on RELENG_13 now only ifconfig_vlan2="192.168.1.51/24 vlan 2 vlandev igb1" is allowed. Maybe a heads up in UPDATING ? ---Mike
Re: Source IPv4 address selection vs BGP IX connection
On 4/23/2024 10:12 PM, Gregory Shapiro wrote: Short version: Using FreeBSD as a BGP router has network issues caused by suboptimal default IPv4 source address selection when connected to Internet Exchanges (which are required to use IPs that aren't routable on the Internet). I was hoping to find more elegant workarounds or encourage FreeBSD to add source IPv4 selection akin to the existing IPv6 source address selection (no_prefer_iface and prefer_source). I assume that there is a group of BGP enthusiasts using FreeBSD lurking on freebsd-net. What have you done to solve this problem? For DNS in such situations I start unbound locally and bind it to an internal interface or an IP on lo0 and then tell unbound to just use that IP only (outgoing-interface IIRC) that is advertised out as a work around. Its not a proper solution, but will get your resolver working at least. I run into this problem in layered networks where the next hop is often RFC 1918 addrs. I bind applications to internal NICs that have addresses that have routing to/from. ---Mike
Re: Regression with pf or IPv6 on FreeBSD 14 with IPsec gif(4) tunnel
On 9/15/2023 1:38 AM, Xin Li wrote: On 2023-09-14 3:28 AM, Kristof Provost wrote: On 14 Sep 2023, at 4:54, Xin Li wrote: Hi! And as a shoot to the dark, I tried again with IPsec (racoon) disabled, and the issue is gone. My IPsec configuration is fairly common: I'm still comparing the code and reading the history of changes between stable/13 and stable/14 to see if there are something obvious, but more insights from others would be appreciated :) [/me takes a in the dark] maybe something like net.inet.ipsec.filtertunnel=1 is needed now ? ---Mike
Re: Very slow scp performance comparing to Linux
On 8/28/2023 3:32 AM, Wei Hu wrote: Hi, When I was testing a new NIC, I found the single stream scp performance was almost 8 time slower than Linux on the RX side. Initially I thought it might be something with the NIC. But when I switched to sending the file on localhost, the numbers stay the same. Just curious, how does iperf3 perform in comparison ? ---Mike
Re: Netstat -i 5-character interface name length?
On 6/29/2022 10:56 AM, Chris Ross wrote: Hello folks. I just noticed something that I’m sure has been true forever, but I checked and it’s still true on my 12.3-STABLE system. One of the first local mods I do is alias netstat to netstat -W for this reason. e.g. alias netstat netstat -W in /etc/csh.cshrc ---Mike
Re: remote use-after-free in icmp6
Hi, Is this an issue in HEAD only ? Or is it something that needs to be MFC'd ? ---Mike On 10/28/2020 4:27 PM, Alexander V. Chernikov wrote: > 28.10.2020, 20:25, "Alexander V. Chernikov" : >> 28.10.2020, 18:34, "Maxime Villard" : >>> In icmp6_notify_error(), 'finaldst' points to data within an mbuf, but when >>> iterating over the next IPv6 options the kernel can free that mbuf, meaning >>> the dereferences of 'finaldst' hit a freed buffer. > [sorry for reposting, plaintext this time] >> Fixed in r367114, thanks for reporting! >>> Note that this is triggerable without specific conditions, over just ICMPv6. >>> >>> Maxime >>> ___ >>> freebsd-net@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: unexplained latency, interrupt spikes and loss of throughput on FreeBSD router/firewall system
On 1/15/2020 9:55 AM, John Jasen wrote: > Executive summary: > > Periodically, load will spike on network interrupts on one of our > firewalls. Latency will quickly climb to the point that things are > unresponsive, sessions will timeout, and bandwidth will plummet. A couple of wild stabs... Are the routers generating any odd amount of ICMP response traffic at the time ? e.g. port|host unreachable etc ? (maybe track netstat -s -p icmp). Are there any bursts of icmp redirects happening ? I know that can slog a router sometimes-- Try instrumenting the appropriate oids (sysctl -a | grep -i redirect) to see if thats the case. A lot of small packets ? If possible maybe a network tap in front of the boxes to capture / profile the traffic before/after to see if there is something like a big scan happening or DOS with many small packets etc. If thats not possible, do you have enough spare CPU to do some netflow analysis on the box ? Or maybe take some periodic snapshots of the interface stats and compare normal to bad periods via sysctl -A dev.cxl | grep "_frames_" Good luck! ---Mike ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Is if_ipsec/ipsec - AESNI accelerated ?
On 8/9/2018 4:11 PM, David P. Discher wrote:
> [ pts/0 sjc2 util201:~ ]
> [ dpd ] > sudo setkey -D
> Password:
> 10.245.0.201 10.245.0.202
> esp mode=tunnel spi=60080461(0x0394c14d) reqid=12(0x000c)
> E: rijndael-cbc 79e053a5 221c6d48 31e4c98a 3ae8c8ed
BTW, if you use a static psk, does not the above line essentially give
someone with access to the ESP traffic a way to decode your traffic ?
---Mike
> A: hmac-sha2-256 9f1a4188 7849ad94 41cfd974 a5e0570a cc7c54a5 c16f5ebc
> 6bb39fbb 212abce0
> seq=0x0011 replay=4 flags=0x state=mature
> created: Aug 9 19:21:15 2018 current: Aug 9 19:38:13 2018
> diff: 1018(s) hard: 86400(s) soft: 69120(s)
> last: Aug 9 19:21:16 2018 hard: 0(s) soft: 0(s)
> current: 2652(bytes)hard: 0(bytes) soft: 0(bytes)
> allocated: 17 hard: 0 soft: 0
> sadb_seq=1 pid=2441 refcnt=1
> 10.245.0.202 10.245.0.201
> esp mode=tunnel spi=170852236(0x0a2eff8c) reqid=12(0x000c)
> E: rijndael-cbc 221239cf e0ddedc5 88f1f711 5e744723
> A: hmac-sha2-256 bf214e0e 73b27e42 1090a067 eaed9e2a d36d3ae7 529a40a1
> bf5ea2c9 0e3f5f27
> seq=0x replay=4 flags=0x state=mature
> created: Aug 9 19:21:15 2018 current: Aug 9 19:38:13 2018
> diff: 1018(s) hard: 86400(s) soft: 69120(s)
> last: hard: 0(s) soft: 0(s)
> current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
> allocated: 0hard: 0 soft: 0
> sadb_seq=0 pid=2441 refcnt=1
>
>
>
> [ pts/0 sjc2 util201:~ ]
> [ dpd ] > sudo setkey -D -P
> 172.30.1.12/30[any] 172.30.1.12/30[any] any
> in ipsec
> esp/tunnel/10.245.0.202-10.245.0.201/unique:12
> spid=22 seq=11 pid=2443 scope=global
> refcnt=1
> 172.30.1.4/30[any] 172.30.1.4/30[any] any
> in ipsec
> esp/tunnel/10.245.0.203-10.245.0.201/unique:4
> spid=24 seq=10 pid=2443 scope=global
> refcnt=1
> 0.0.0.0/0[any] 0.0.0.0/0[any] any
> in ipsec
> esp/tunnel/10.245.0.202-10.245.0.201/unique:12
> spid=5 seq=9 pid=2443 scope=ifnet ifname=ipsec12
> refcnt=1
> ::/0[any] ::/0[any] any
> in ipsec
> esp/tunnel/10.245.0.202-10.245.0.201/unique:12
> spid=7 seq=8 pid=2443 scope=ifnet ifname=ipsec12
> refcnt=1
> 0.0.0.0/0[any] 0.0.0.0/0[any] any
> in ipsec
> esp/tunnel/10.245.0.203-10.245.0.201/unique:4
> spid=13 seq=7 pid=2443 scope=ifnet ifname=ipsec4
> refcnt=1
> ::/0[any] ::/0[any] any
> in ipsec
> esp/tunnel/10.245.0.203-10.245.0.201/unique:4
> spid=15 seq=6 pid=2443 scope=ifnet ifname=ipsec4
> refcnt=1
> 172.30.1.12/30[any] 172.30.1.12/30[any] any
> out ipsec
> esp/tunnel/10.245.0.201-10.245.0.202/unique:12
> spid=21 seq=5 pid=2443 scope=global
> refcnt=1
> 172.30.1.4/30[any] 172.30.1.4/30[any] any
> out ipsec
> esp/tunnel/10.245.0.201-10.245.0.203/unique:4
> spid=23 seq=4 pid=2443 scope=global
> refcnt=1
> 0.0.0.0/0[any] 0.0.0.0/0[any] any
> out ipsec
> esp/tunnel/10.245.0.201-10.245.0.202/unique:12
> spid=6 seq=3 pid=2443 scope=ifnet ifname=ipsec12
> refcnt=1
> ::/0[any] ::/0[any] any
> out ipsec
> esp/tunnel/10.245.0.201-10.245.0.202/unique:12
> spid=8 seq=2 pid=2443 scope=ifnet ifname=ipsec12
> refcnt=1
> 0.0.0.0/0[any] 0.0.0.0/0[any] any
> out ipsec
> esp/tunnel/10.245.0.201-10.245.0.203/unique:4
> spid=14 seq=1 pid=2443 scope=ifnet ifname=ipsec4
> refcnt=1
> ::/0[any] ::/0[any] any
> out ipsec
> esp/tunnel/10.245.0.201-10.245.0.203/unique:4
> spid=16 seq=0 pid=2443 scope=ifnet ifname=ipsec4
> refcnt=1
>
>
> --
> David P. Discher
> https://davidpdischer.com/
> 408.368.3725 • d...@dpdtech.com
>
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
>
--
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: memory leaks in 11.0?
On 7/11/2017 9:56 AM, Kajetan Staszkiewicz wrote: > Hello, > > I finally upgraded one of many of my routers to 11.0. Hi, 11.0 as in 11.0R or 11-STABLE ? I have a number of RELENG_11 boxes running (r316678 to r319309) as routers (with frr, not bird) that are quite stable and no memory leaks (that I can see anyways). ---Mike -- ------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: state of packet forwarding in FreeBSD?
On 6/14/2017 10:48 AM, John Jasen wrote: > Our goal was to test whether or not FreeBSD currently is viable, as the > operating system platform for high speed routers and firewalls, in the > 40 to 100 GbE range. > > In our investigations, we tested 10.3, 11.0/-STABLE, -CURRENT, and a USB > stick from BSDRP using the FreeBSD routing improvements project > enhancements (https://wiki.freebsd.org/ProjectsRoutingProposal). Hi John, I am interested in your findings / test setups. I have a couple of boxes in the field running r317611 (around April 30) and r316678 (April 4) and found that r316678 does a higher PPS with zero drops and r317611 does less work, but will get random overruns on dev.cxl.0.stats.rx_ovflow0 and dev.cxl.0.stats.rx_trunc0. Same hardware, same cxl cards, both running frr as the routing daemon. Whats odd is that the errors are not anywhere peak load. Sometimes in the middle of the night when traffic is much lower. The missed packets dont seem to correlate to load-- that I can see anyways based on utilization graphs. When you were doing your tests, did you measure peak as what the box could forward without dropping packets or dropping some ? ---Mike -- ------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: pf bug with tun interfaces ?
On 3/16/2017 2:15 AM, Ermal Luçi wrote: > > > On Wed, Mar 15, 2017 at 7:33 PM, Kristof Provost <kris...@sigsegv.be > <mailto:kris...@sigsegv.be>> wrote: > > On 15 Mar 2017, at 22:10, Mike Tancsa wrote: > > On 3/15/2017 4:28 AM, Kristof Provost wrote: > > I don’t see any obvious reason why that would happen. > > Can you reduce this to a minimal test setup and include > rc.conf, pf.conf, … > with a bug report in bugzilla? > > > is it possible that its how OpenVPN sets up the tun interface ? > Otherwise nat via pf on ppp connections would not work either. > > I’m not aware of anything, but I’m not very familiar with OpenVPN. > > > The only time this will not work is when tun interface does not have an > ip assigned. > So your rule will not work with (tun) syntax. > > Otherwise it does not depend on anything else other than general ifnet > What FreeBSD Version is this? RELENG_10. I will have to dig out an old image, but I am pretty sure I was able to do this on a RELENG_8 box. The interface has an IP eg tun91: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> metric 0 mtu 1500 options=8 inet 10.61.0.1 --> 10.61.0.2 netmask 0x Opened by PID 5778 Not sure why it chooses such a netmask, but it does that. I tried manually setting the natting IP, but no difference. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: pf bug with tun interfaces ?
On 3/15/2017 4:28 AM, Kristof Provost wrote: > I don’t see any obvious reason why that would happen. > > Can you reduce this to a minimal test setup and include rc.conf, pf.conf, … > with a bug report in bugzilla? is it possible that its how OpenVPN sets up the tun interface ? Otherwise nat via pf on ppp connections would not work either. I will try and setup a most simple test vm ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: pf bug with tun interfaces ?
Just to add a bit more information, the problem appears solely with the outbound nat via the tun interface. It doesnt matter the rdr is on a regular nic or not, it still does not work when the nat statement is for traffic on a tun interface. So it appears its not possible to nat connections initiated TO openvpn clients for some reason ? eg nat pass log on tun200 from 10.241.0.0/23 to 10.211.1.28 -> (tun200) will not work. An IP address with a source address of 10.241.0.6 for example, will not get natted as it travels to 10.211.1.28 on tun200 to the client on OpenVPN ---Mike On 3/13/2017 9:52 AM, Mike Tancsa wrote: > > I am not sure if I have run into a bug or a limitation. Basically a rdr > on one interface and then a nat on the outbound. It works fine when the > interfaces are two physical network cards like an em and igb. But if > both are tun interfaces, the nat doesnt work > > > 2 servers and one router (all 3 freebsd) > > S1 and S2 and R1 > > s1 = 192.168.1.1 > s2 = 10.0.0.1 > > R1 has > 192.168.1.2 (igb0) and 10.0.0.2 (em0) > > if I connect from > > > rdr pass log on igb0 proto tcp from 192.168.1.1 to 192.168.1.2 port 24 > -> 10.0.0.1 port 22 > nat pass log on em0 from 192.168.1.1 to any -> (em0) > > so from s1, if I do an > ssh -b 192.168.1.1 -p 24 192.168.1.2 > > I land on the server 10.0.0.1 and the network connection/login is from > 10.0.0.2. > > However, if the interfaces are tun0 and tun1 this does not work. The rdr > works, but the nat never kicks in > > In the tun case, its two separate OpenVPN instances. A client (A) > behind tun100 connects to the server's IP on tun100 on port X. The RDR > rule does a redirect to port Y on a client's IP (B) on tun200. The RDR > works, but the packet is not natted. Its the source address of client A > that appears at client B and not the natted IP of tun200. > > The tun version looks like > > rdr pass log on tun100 proto tcp from 10.241.0.0/23 to self port 5023 -> > 10.211.1.28 port 6901 > nat pass log on tun200 from 10.241.0.0/23 to 10.211.1.28 -> (tun200) > > In the above 2 lines, the target client, 10.211.1.28 sees a network > connection attempt from 10.241.1.6 and not the IP of tun200 as I would > expect. > > ---Mike > > -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
pf bug with tun interfaces ?
I am not sure if I have run into a bug or a limitation. Basically a rdr on one interface and then a nat on the outbound. It works fine when the interfaces are two physical network cards like an em and igb. But if both are tun interfaces, the nat doesnt work 2 servers and one router (all 3 freebsd) S1 and S2 and R1 s1 = 192.168.1.1 s2 = 10.0.0.1 R1 has 192.168.1.2 (igb0) and 10.0.0.2 (em0) if I connect from rdr pass log on igb0 proto tcp from 192.168.1.1 to 192.168.1.2 port 24 -> 10.0.0.1 port 22 nat pass log on em0 from 192.168.1.1 to any -> (em0) so from s1, if I do an ssh -b 192.168.1.1 -p 24 192.168.1.2 I land on the server 10.0.0.1 and the network connection/login is from 10.0.0.2. However, if the interfaces are tun0 and tun1 this does not work. The rdr works, but the nat never kicks in In the tun case, its two separate OpenVPN instances. A client (A) behind tun100 connects to the server's IP on tun100 on port X. The RDR rule does a redirect to port Y on a client's IP (B) on tun200. The RDR works, but the packet is not natted. Its the source address of client A that appears at client B and not the natted IP of tun200. The tun version looks like rdr pass log on tun100 proto tcp from 10.241.0.0/23 to self port 5023 -> 10.211.1.28 port 6901 nat pass log on tun200 from 10.241.0.0/23 to 10.211.1.28 -> (tun200) In the above 2 lines, the target client, 10.211.1.28 sees a network connection attempt from 10.241.1.6 and not the IP of tun200 as I would expect. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Chelsio netmap support ? (RELENG_11)
On 3/7/2017 9:08 PM, Navdeep Parhar wrote: > On Tue, Mar 7, 2017 at 5:46 PM, Mike Tancsa <m...@sentex.net> wrote: > >> >> # dmesg | grep netm >> netmap: loaded module >> vcxl0: netmap queues/slots: TX 2/1023, RX 2/1024 >> vcxl0: 1 txq, 1 rxq (NIC); 1 txq, 1 rxq (TOE); 2 txq, 2 rxq (netmap) >> vcxl1: netmap queues/slots: TX 2/1023, RX 2/1024 >> vcxl1: 1 txq, 1 rxq (NIC); 1 txq, 1 rxq (TOE); 2 txq, 2 rxq (netmap) >> igb0: netmap queues/slots: TX 4/1024, RX 4/1024 >> igb1: netmap queues/slots: TX 4/1024, RX 4/1024 >> >> It maxes out at about 800Kpps with and without netmap. Is there a way > > Are you actually using a netmap based application that acts as a > packet router or is this just the vcxl interface running as a normal > ifnet? the later, vcxl running normal ifnet. I thought there would be a benefit to utilizing netmap ? Sorry, this is not clear to me. > >> to increase the queues for the Chelsio nic, like the onboard igb ? > > If you're not running a netmap based router get rid of the num_vis=2 > and simply try with the cxl0/cxl1 interfaces. They should each have 4 > rxq/4 txq on your system. In case you want to increase the number of > queues, use this: The tests with the regular cxl also show the box topping out at 0.8Mpps for forwarding. > > The "NIC" queues are the normal tx/rx queues, the "netmap" queues are > active when the interface is in netmap mode. > > Does netsend generate a single flow or multiple flows? If it's a > single flow it will use a single queue only. I think its as a single flow. However, I was using a separate box to generate a second flow as well. It still topped out at about 800Kpps before dropping packets. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Chelsio netmap support ? (RELENG_11)
On 3/7/2017 5:07 PM, Navdeep Parhar wrote:
> On Tue, Mar 7, 2017 at 1:53 PM, Mike Tancsa <m...@sentex.net> wrote:
> ...
>>
>> Using netsend, I cant seem to blast through a single flow of packets
>> greater than 800Kpps without packet loss. Can you point me to any
>> performance tweaks for forwarding / routing ?
>>
>> I have 3 boxes, with one in the middle
>>
>> (netsend box) <> (router with chelsio nics) <---> (netreceive box)
>
> How is the router configured -- is this something netmap based?
> Please provide more details of the configuration. What kind of
> CPU/chipset is it?
Hi,
Xeon E3-1225 v5 @ 3.30GHz
Supermicro X11SSL-F Intel Skylake-S/Skylake-H/Greenlow
PCI-e 3.0 slots
t5iov0@pci0:2:0:0: class=0x02 card=0x1425 chip=0x50071425
rev=0x00 hdr=0x00
vendor = 'Chelsio Communications Inc'
device = 'T520-SO Unified Wire Ethernet Controller'
class = network
subclass = ethernet
bar [10] = type Memory, range 64, base 0xdd80, size 524288,
enabled
bar [18] = type Memory, range 64, base 0xdd78, size 524288,
enabled
bar [20] = type Memory, range 64, base 0xdd88c000, size 8192, enabled
cap 01[40] = powerspec 3 supports D0 D3 current D0
cap 05[50] = MSI supports 8 messages, 64 bit, vector masks
cap 10[70] = PCI-Express 2 endpoint max data 256(2048) FLR NS
link x8(x8) speed 8.0(8.0)
cap 11[b0] = MSI-X supports 34 messages
Table in map 0x20[0x0], PBA in map 0x20[0x1000]
cap 03[d0] = VPD
ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
ecap 0002[140] = VC 1 max VC1
ecap 0003[170] = Serial 1
ecap 000e[190] = ARI 1
ecap 0019[1a0] = PCIe Sec 1 lane errors 0
ecap 0010[1c0] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI
disabled
0 VFs configured out of 16 supported
First VF RID Offset 0x0008, VF RID Stride 0x0004
VF Device ID 0x5807
Page Sizes: 4096 (enabled), 8192, 65536, 262144,
1048576, 4194304
Two 10G interfaces on a switch vcxl0 (192.168.1.1) vcxl1 (10.151.10.1)
192.168.1.2 does the netsend to 10.151.10.3 so it goes through the
router in question. Router in question is RELENG11
dev.cxl.0.pause_settings=0
dev.cxl.1.pause_settings=0
loader.conf
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
zfs_load="YES"
#t4fw_cfg_load="YES"
t5fw_cfg_load="YES"
#t6fw_cfg_load="YES"
if_cxgbe_load="YES"
hw.cxgbe.num_vis=2
comconsole_speed="115200" # Set the current serial console speed
console="comconsole,vidconsole" # A comma separated list of
console(s)
comconsole_port="0x2F8"
> Do you see any PAUSE frames out of the T5? "sysctl dev.cxl dev.vcxl |
> grep _pause" Is any CPU core pegged at 100% during the test?
dev.cxl.1.stats.rx_pause: 0
dev.cxl.1.stats.tx_pause: 0
dev.cxl.1.pause_settings: 0
dev.cxl.0.stats.rx_pause: 0
dev.cxl.0.stats.tx_pause: 0
dev.cxl.0.pause_settings: 0
while forwarding, top shows the system 25% in interrupt
# dmesg | grep netm
netmap: loaded module
vcxl0: netmap queues/slots: TX 2/1023, RX 2/1024
vcxl0: 1 txq, 1 rxq (NIC); 1 txq, 1 rxq (TOE); 2 txq, 2 rxq (netmap)
vcxl1: netmap queues/slots: TX 2/1023, RX 2/1024
vcxl1: 1 txq, 1 rxq (NIC); 1 txq, 1 rxq (TOE); 2 txq, 2 rxq (netmap)
igb0: netmap queues/slots: TX 4/1024, RX 4/1024
igb1: netmap queues/slots: TX 4/1024, RX 4/1024
It maxes out at about 800Kpps with and without netmap. Is there a way
to increase the queues for the Chelsio nic, like the onboard igb ?
top -nCHSIzs1
last pid: 2517; load averages: 1.15, 0.45, 0.27 up 0+04:26:13
20:44:09
393 processes: 8 running, 346 sleeping, 39 waiting
Mem: 10M Active, 37M Inact, 360M Wired, 15G Free
ARC: 67M Total, 691K MFU, 64M MRU, 16K Anon, 430K Header, 1758K Other
Swap: 32G Total, 32G Free
PID USERNAME PRI NICE SIZERES STATE C TIME CPU COMMAND
11 root -92- 0K 672K CPU00 5:45 80.08%
intr{irq272: t5nex0:0b0}
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Chelsio netmap support ? (RELENG_11)
l.0.nnmtxq: 2
dev.vcxl.0.nnmrxq: 2
dev.vcxl.0.first_ofld_txq: 4
dev.vcxl.0.first_ofld_rxq: 2
dev.vcxl.0.nofldtxq: 1
dev.vcxl.0.nofldrxq: 1
dev.vcxl.0.rss_size: 64
dev.vcxl.0.first_txq: 4
dev.vcxl.0.first_rxq: 4
dev.vcxl.0.ntxq: 1
dev.vcxl.0.nrxq: 1
dev.vcxl.0.viid: 1226
dev.vcxl.0.%parent: cxl0
dev.vcxl.0.%pnpinfo:
dev.vcxl.0.%location:
dev.vcxl.0.%driver: vcxl
dev.vcxl.0.%desc: port 0 vi 1
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Chelsio netmap support ? (RELENG_11)
I have a Chelsio T520 NIC that I have been trying to get netmap working with. I see reference to the ncxl# vs cxl# interface on the lists, but I never see ncxl come up. The man pages dont say anything about having to specifically enable anything that I can see. I am using RELENG11 as of today (r314848). ---Mike t5nex0@pci0:2:0:4: class=0x02 card=0x1425 chip=0x54071425 rev=0x00 hdr=0x00 vendor = 'Chelsio Communications Inc' device = 'T520-SO Unified Wire Ethernet Controller' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xdd30, size 524288, enabled bar [18] = type Memory, range 64, base 0xdc00, size 16777216, enabled bar [20] = type Memory, range 64, base 0xdd884000, size 8192, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 32 messages, 64 bit, vector masks cap 10[70] = PCI-Express 2 endpoint max data 256(2048) FLR RO NS link x8(x8) speed 8.0(8.0) cap 11[b0] = MSI-X supports 256 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x1000] cap 03[d0] = VPD ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected ecap 0003[170] = Serial 1 ecap 000e[190] = ARI 1 ecap 0019[1a0] = PCIe Sec 1 lane errors 0 ecap 0010[1c0] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI disabled 0 VFs configured out of 0 supported First VF RID Offset 0x0008, VF RID Stride 0x0004 VF Device ID 0x5807 Page Sizes: 4096 (enabled), 8192, 65536, 262144, 1048576, 4194304 ecap 0017[200] = TPH Requester 1 netmap seems to activate on the onboard igb NICs. # dmesg | grep -i netma netmap: loaded module igb0: netmap queues/slots: TX 4/1024, RX 4/1024 igb1: netmap queues/slots: TX 4/1024, RX 4/1024 # ifconfig cxl1 cxl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=ec07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> ether 00:07:43:39:9d:b8 inet 10.151.10.1 netmask 0xff00 broadcast 10.151.10.255 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet 10Gbase-Twinax status: active plugged: SFP/SFP+/SFP28 Unknown (Copper pigtail) vendor: CISCO-TYCO PN: 1-2053783-2 SN: TED1605BGWC DATE: 2016-02-01 ---Mike -- ------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: How to configure another loopback device?
On 12/23/2016 9:10 AM, John Dison via freebsd-net wrote: > Sorry, just noticed damn yahoo mailer eat all line breaks. Resending in > plain text (I hope): > > I want to configure lo1 loopback device and assign aliases to it via rc.conf > system (at boot). > I also want loopback addresses to remain on lo0. > > What I have: > ifconfig_lo1_alias0="inet IP4/32" > ifconfig_lo1_alias1="inet6 IP6/128" > cloned_interfaces="lo1" > create_args_lo1="inet6 auto_linklocal" > if your first IPs are say 192.168.1.1-2/32 and 2001:550:2:8::1e-f Try without an alias0 for the first set of IPs ifconfig_lo1="inet 192.168.1.1/32" ifconfig_lo1_ipv6="inet6 2001:550:2:8::1e prefixlen 126" ifconfig_lo1_alias0="inet 192.168.1.2/32" ifconfig_lo1_ipv6_alias0="inet6 2001:550:2:8::1f prefixlen 126" ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: 10/STABLE BGP daemon with TCP MD5 signature ?
On 7/4/2016 12:36 PM, Patrick Lamaiziere wrote: > As openbgpd(*) looks broken for the BGP password, is there any BGP > daemon that works with tcp md5 signature (using setkey and ipsec of > course) ? Quagga should work. ---Mike -- ------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: NFS on 10G interface terribly slow
On 6/29/2015 8:20 AM, Rick Macklem wrote: If the Solaris server is using ZFS, setting sync=disabled might help w.r.t. On my FreeBSD zfs server, this is a must for decent and consistent write throughput. Using FreeBSD as an iSCSI target and a Linux initiator, I can saturate a 1G nic no problem with sync disabled. Its barely usable with the default sync standard as its so bursty ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Intel em (82574L and 82573L) problems: stopping on high network and cpu load (Watchdog timeout)
On 4/15/2015 1:42 AM, Andre Albsmeier wrote: On Tue, 14-Apr-2015 at 10:01:16 -0400, Mike Tancsa wrote: On 4/14/2015 1:54 AM, Andre Albsmeier wrote: Is this an em specific issue or should one avoid TSO generally at the moment? That is, should I disable it on machines with msk (and maybe other) interfaces as well? em specific I think. This thread has some info on what might be going on https://lists.freebsd.org/pipermail/freebsd-stable/2014-September/080081.html Very interesting, thanks. Until now (and without TSO), the problem did not re-occur but I didn't hit the NFS heavily yet. Hi, Just to be clear, the network hang has returned ? Or its still problem free ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Intel em (82574L and 82573L) problems: stopping on high network and cpu load (Watchdog timeout)
On 4/14/2015 1:54 AM, Andre Albsmeier wrote: Is this an em specific issue or should one avoid TSO generally at the moment? That is, should I disable it on machines with msk (and maybe other) interfaces as well? em specific I think. This thread has some info on what might be going on https://lists.freebsd.org/pipermail/freebsd-stable/2014-September/080081.html ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Intel em (82574L and 82573L) problems: stopping on high network and cpu load (Watchdog timeout)
On 4/13/2015 6:16 AM, Andre Albsmeier wrote: I don't want to say that I can easily reproduce it but chances are quite good when I transfer a lot of stuff over the network _AND_ the CPU is heavily loaded. The CPU is a try disabling tso ifconfig em0 -tso and see if it makes a difference. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: SSH hung with an OpenSSH_6.6.1p1 -- OpenSSH_5.8p2_hpn13v11
On 3/26/2015 2:44 AM, Wu ShuKun wrote: OpenSSH_5.4p1 FreeBSD-20100308, OpenSSL 0.9.8q 2 Dec 2010 failed with Latest SSH: % ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1l-freebsd 15 Jan 2015 Hi, The latest is 1.0.1m, no? }# ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1m-freebsd 19 Mar 2015 What version of FreeBSD are you using ? Ssh and Openssl from the ports ? or in the base ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Issue with forwarding when creates new interface [was USB Tethering and forwarding]
On 1/3/2015 9:19 AM, Paul Thornton wrote:
Hi,
I can also replicate this behaviour on 10.1-RELEASE by simply creating
an additional vlan interface. It affects IPv4 and IPv6 forwarding.
Strange, I dont see that on RELENG_10
0{marble}# ifconfig em2 up
0{marble}# ifconfig em2.3 create 1.1.1.2/24
0{marble}# sysctl -a | grep forwarding
net.inet.ip.forwarding: 1
net.inet.ip.fastforwarding: 0
net.inet6.ip6.forwarding: 0
0{marble}# ifconfig vlan4 create 2.2.2.2 vlan 4 vlandev em2
0{marble}# sysctl -a | grep forwarding
net.inet.ip.forwarding: 1
net.inet.ip.fastforwarding: 0
net.inet6.ip6.forwarding: 0
0{marble}#
do you set forwarding via just /etc/sysctl.conf or in /etc/rc.conf via
ipv6_gateway_enable and gateway_enable. I seem to recall some discussion
about there being a difference. Perhaps devd is calling something that
then fiddles with the setting ignoring whats in sysctl.conf ?
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.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: igb requests for mbufs denied
On 8/28/2014 4:31 AM, Eggert, Lars wrote: Hi, no matter what value I bump kern.ipc.nmbclusters and kern.ipc.nmbufs to, I still get requests for mbufs denied with igb interfaces, and the occasional connection stall, even when dialing down hw.igb.num_queues=1: The box in question has six igb interfaces, 2x 'I210 Gigabit Network Connection' and 4x '82580 Gigabit Network Connection' and is running: FreeBSD laurel.muccbc.hq.netapp.com 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Tue Jul 8 06:37:44 UTC 2014 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Anyone have any ideas what else to try? A stab in the dark, but I ran into a bug where setting queues to 1 did not have the same positive impact as disabling msix in loader.conf hw.igb.enable_msix=0 ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: igb requests for mbufs denied
On 8/28/2014 7:45 AM, Eggert, Lars wrote: Hi, also just noticed that there is a version 2.4.2 driver on Intel's site for these cards (https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=15815) whereas FreeBSD (incl. -CURRENT) is at 2.4.0. No changelog, unfortunately. There is a newer version in RELENG_10 and the change log just says newer IDs were added to support newer cards. There are some other minor changes which seems to have broken one of my 82574L cards however. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Intel Support for FreeBSD
On 8/12/2014 9:16 PM, Barney Cordoba via freebsd-net wrote: I notice that there hasn't been an update in the Intel Download Center since July. Is there no official support for 10? Hi, The latest code is committed directly into the tree by Intel eg http://lists.freebsd.org/pipermail/svn-src-head/2014-July/060947.html and http://lists.freebsd.org/pipermail/svn-src-head/2014-June/059904.html They have been MFC'd to RELENG_10 a few weeks ago ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: FreeBSD 10.0-R connected to Cisco switch (in 'trunk' mode with native VLAN) - doesn't work?
On 7/29/2014 9:02 AM, Karl Pielorz wrote: Switch side - the port is configured with: switchport trunk encapsulation dot1q switchport trunk native vlan 2000 switchport trunk allowed vlan 2000,2200-2300 switchport mode trunk Would it not be better to have switchport trunk allowed vlan 2200-2300 otherwise its not clear to me what would be tagged and what would not be tagged as vlan 2000, no ? Do you really need to send a mix of tagged and untagged frames on the port ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: mpd5/Netgraph issues after upgrading to 7.4
On 3/14/2014 1:00 PM, Przemyslaw Frasunek wrote: FYI -- after upgrade to 9-STABLE no further crashes occurred, even with IPv6 enabled. What sort of uptime have you seen with ipv6 enabled ? Now it's 19 days and still no crash occurred. Hi, Has all been stable still with ipv6 enabled ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: mpd5/Netgraph issues after upgrading to 7.4
On 3/14/2014 1:00 PM, Przemyslaw Frasunek wrote: FYI -- after upgrade to 9-STABLE no further crashes occurred, even with IPv6 enabled. What sort of uptime have you seen with ipv6 enabled ? Now it's 19 days and still no crash occurred. I would sometimes get a month on a box with ~ 500 users ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: mpd5/Netgraph issues after upgrading to 7.4
On 3/9/2014 7:33 AM, Przemyslaw Frasunek wrote: I've seen that Mike reported similar issues in October (http://lists.freebsd.org/pipermail/freebsd-stable/2013-October/075552.html). Did you managed to resolve it? I worked around the crash by removing ipv6 from the kernel. The box has been functioning without a crash since then. Hi, FYI -- after upgrade to 9-STABLE no further crashes occurred, even with IPv6 enabled. What sort of uptime have you seen with ipv6 enabled ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Free book draft: IPv6 for IPv4 Experts
On 9/23/2013 7:50 AM, Yar Tikhiy wrote: The project page is: https://sites.google.com/site/yartikhiy/home/ipv6book An e-reader friendly PDF as well as a conventional A4 size PDF is available. Hoping you will enjoy the reading as much as I have enjoyed the writing. Wow! I just had a look at the TOC and it looks like a great addition to the spare resources that are out there. I will certainly have a look through it in the coming days. Thanks for sharing with the community! ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: TSO help or hindrance ? (was Re: TSO and FreeBSD vs Linux)
On 9/10/2013 6:42 PM, Barney Cordoba wrote: NFS has been broken since Day 1, so lets not come to conclusions about anything as it relates to NFS. iSCSI is NFS ? ---Mike BC *From:* Mike Tancsa m...@sentex.net *To:* Rick Macklem rmack...@uoguelph.ca *Cc:* FreeBSD Net n...@freebsd.org; David Wolfskill da...@catwhisker.org *Sent:* Wednesday, September 4, 2013 11:26 AM *Subject:* TSO help or hindrance ? (was Re: TSO and FreeBSD vs Linux) On 9/4/2013 8:50 AM, Rick Macklem wrote: David Wolfskill wrote: I noticed that when I tried to write files to NFS, I could write small files OK, but larger ones seemed to ... hang. * ifconfig -v em0 showed flags TSO4 VLAN_HWTSO turned on. * sysctl net.inet.tcp.tso showed 1 -- enabled. As soon as I issued sudo net.inet.tcp.tso=0 ... the copy worked without a hitch or a whine. And I was able to copy all 117709618 bytes, not just 2097152 (2^21). Is the above expected? It came rather as a surprise to me. Not surprising to me, I'm afraid. When there are serious NFS problems like this, it is often caused by a network fabric issue and broken TSO is at the top of the list w.r.t. cause. I was just experimenting a bit with iSCSI via FreeNAS and was a little disappointed at the speeds I was getting. So, I tried disabling tso on both boxes and it did seem to speed things up a bit. Data and testing methods attached in a txt file. I did 3 cases. Just boot up FreeNAS and the initiator without tweaks. That had the worst performance. disable tso on the nic as well as via sysctl on both boxes. That had the best performance. re-enable tso on both boxes. That had better performance than the first case, but still not as good as totally disabling it. I am guessing something is not quite being re-enabled properly ? But its different than the other two cases ?!? tgt is FreeNAS-9.1.1-RELEASE-x64 (a752d35) and initiator is r254328 9.2 AMD64 The FreeNAS box has 16G of RAM, so the file is being served out of cache as gstat shows no activity when sending out the file ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net mailto:m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailto: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 mailto:freebsd-net-unsubscr...@freebsd.org -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: TSO help or hindrance ? (was Re: TSO and FreeBSD vs Linux)
On 9/10/2013 7:04 PM, Rick Macklem wrote: Mike Tancsa wrote: On 9/10/2013 6:42 PM, Barney Cordoba wrote: NFS has been broken since Day 1, so lets not come to conclusions about anything as it relates to NFS. iSCSI is NFS ? It would be really nice if you could try trasz`s new iSCSI stack and see how well it works. (I, for one, am hoping it makes it into 10.0, but it may be too late.) I was only doing limited testing of iSCSI both as target and initiator. I was a little disappointed at the slow speeds I was getting. Noticing the thread about TSO, I thought it would be interesting to test and sure enough it did make a difference. IIRC, the new iSCSI stack is currently tested more for correctness than performance? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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
TSO help or hindrance ? (was Re: TSO and FreeBSD vs Linux)
On 9/4/2013 8:50 AM, Rick Macklem wrote:
David Wolfskill wrote:
I noticed that when I tried to write files to NFS, I could write
small
files OK, but larger ones seemed to ... hang.
* ifconfig -v em0 showed flags TSO4 VLAN_HWTSO turned on.
* sysctl net.inet.tcp.tso showed 1 -- enabled.
As soon as I issued sudo net.inet.tcp.tso=0 ... the copy worked
without
a hitch or a whine. And I was able to copy all 117709618 bytes, not
just
2097152 (2^21).
Is the above expected? It came rather as a surprise to me.
Not surprising to me, I'm afraid. When there are serious NFS problems
like this, it is often caused by a network fabric issue and broken
TSO is at the top of the list w.r.t. cause.
I was just experimenting a bit with iSCSI via FreeNAS and was a little
disappointed at the speeds I was getting. So, I tried disabling tso on
both boxes and it did seem to speed things up a bit. Data and testing
methods attached in a txt file.
I did 3 cases.
Just boot up FreeNAS and the initiator without tweaks. That had the
worst performance.
disable tso on the nic as well as via sysctl on both boxes. That had the
best performance.
re-enable tso on both boxes. That had better performance than the first
case, but still not as good as totally disabling it. I am guessing
something is not quite being re-enabled properly ? But its different
than the other two cases ?!?
tgt is FreeNAS-9.1.1-RELEASE-x64 (a752d35) and initiator is r254328 9.2
AMD64
The FreeNAS box has 16G of RAM, so the file is being served out of cache
as gstat shows no activity when sending out the file
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
3 data files.
notso = tso disabled on tgt and initiator
tso-boot = initiator is rebooted and tests are run
tso = tso disabled and then re-enabled. For whatever reason its not as bad as
post boot, but still worse than no tso
0{mdttestbox}# ministat notso tso-boot
x notso
+ tso-boot
+--+
|+
|
| +++
x|
|+
x x xx|
| |AM|
|___M__A_||
+--+
N Min MaxMedian AvgStddev
x 9 69086843 71749085 69475320 69810666 887628.9
+ 9 55846191 56473897 56357956 56302165 208843.3
Difference at 95.0% confidence
-1.35085e+07 +/- 644386
-19.3502% +/- 0.923048%
(Student's t, pooled s = 644787)
0{mdttestbox}#
# ministat tso notso
x tso
+ notso
+--+
| x +
|
|x x x + x + ++ ++ +
+|
|
|MA___||___M___A_|
|
+--+
N Min MaxMedian AvgStddev
x 9 68632067 69126677 68779201 68808473 142050.01
+ 9 69086843 71749085 69475320 69810666 887628.9
Difference at 95.0% confidence
1.00219e+06 +/- 635239
1.4565% +/- 0.923199%
(Student's t, pooled s = 635635)
0{mdttestbox}# cat tso
68779201
68734143
68915705
68752827
68782212
69126677
68828520
68724901
68632067
0{mdttestbox}# cat notso
71749085
69256608
69097532
69086843
70587459
69179672
69475320
69754511
70108963
0{mdttestbox}# cat tso-boot
55846191
56314173
56284204
56095729
56466769
56446535
56357956
56434027
56473897
0{mdttestbox}#
0{mdttestbox}# cat t.sh
#!/bin/sh
command=dd if=/mnt/test of=/dev/null bs=4096k
for i in `jot 9 1`;do
mount /dev/da0a /mnt
eval $command 21 | grep bytes | awk -F[\( ] '{print $8}'
umount /mnt
done
0{mdttestbox}#
initiator is r254328 9.2 AMD64
The two boxes are linked via private gigE switch
em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 9000
options=4209bRXCSUM,TXCSUM,VLAN_MTU
Re: ppp(8) and inbound IP connections
On 5/7/2013 3:24 PM, Matthias Apitz wrote: That is my understanding as well, but why they claim that they do support incoming connections? As Joe Holden said before, to support incoming connections, you probably need to use a different APN, or pay for that service. The carriers here in Canada do that. It would not be manageable otherwise by the carrier. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: pf performance?
On 4/26/2013 12:22 PM, Olivier Cochard-Labbé wrote: On Fri, Apr 26, 2013 at 3:42 PM, Gleb Smirnoff gleb...@freebsd.org wrote: In FreeBSD 10 pf is no longer under single lock. On your hardware, I'd expect a measurable performance gain if you migrate to 10. Compairing 9.1 and current (249908) on my new test-server (HP ProLiant DL320 G5, dual-core Xeon 3050, dual Intel NIC). Like usual: one unidirectional flow of small packets, values in packet-per-seconds: x 9.1 + current N Min MaxMedian AvgStddev x 5379991381508381229 380892.6 667.69926 + 5332833335502334726 334223.2 1142.8266 Difference at 95.0% confidence -46669.4 +/- 1364.98 -12.2526% +/- 0.358363% (Student's t, pooled s = 935.915) Is that because pf is slower on a single flow, or packet forwarding in general is slower on HEAD ? How different is 9.1 and HEAD in just forwarding performance? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: forwarding/ipfw/pf evolution (in pps) on -current
On 4/24/2013 6:45 AM, Olivier Cochard-Labbé wrote: # Why all these benchs ? # I've found performance regression regarding packet forwarding/ipfw/pf speed on -current comparing to 9.1 on my old server. BTW, how much of a drop in performance as compared to 9.1 ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: 9.1-RC3 IGB dropping connections.
On 11/27/2012 5:27 PM, Zaphod Beeblebrox wrote: I've got an Intel server motherboard with 4x igb (and 1x em) on it. The motherboard in question is the S3420GPRX and the IGB's show up as: igb0: Intel(R) PRO/1000 Network Connection version - 2.3.4 port 0x3020-0x303f mem 0xb1b2-0xb1b3,0xb1bc4000-0xb1bc7fff irq 19 at device 0.0 on pci3 igb0: Using MSIX interrupts with 9 vectors igb0: Ethernet address: 00:1e:67:3a:d5:40 igb0: Bound queue 0 to cpu 0 ... now... I have this machine (right now) on the local lan with my windows 7 workstation and putty sees the ssh connection as dropped often. I say often --- in that it can happen in a minute or two... it often seems to happen when there is active output going to the window (like a download counter running), but I also say often in that... it seems slightly random... but it _is_ incessant... as in very often. Are you using pf ? Also, did you confirm it is the igb nic and not something more general ? e.g. if you put in a different nic, does the problem go away ? If you are using pf, lets see the rules. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: getting counters for a plenty of vlan ifaces
On 9/16/2012 10:41 AM, Ivan Alexandrovich wrote: Hi We are running freebsd9.0 on a router with more than 1000 of subscriber's vlan interfaces. Outgoing packet rate is approximately 40 kpps. There's a need to collect bytes and packets counters for all those vlan interfaces every minute (or even twice a minute) and store them Hi, We approach it a little differently and collect all the data via netflow, or in this case argus. I sample the parent interface and save all the flow data which argus is smart enough to parse out at the vlan level. You can then run all sorts of fine grained reports this way. We use it on a system with about 900 ng interfaces. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: mpd5/Netgraph issues after upgrading to 7.4
On 6/15/2012 5:57 PM, Przemyslaw Frasunek wrote: I suspect this isn't related to netgraph, but to IPv6 since prelist_remove() is found in netinet6/nd6_rtr.c. Several times I looked into ND code and found lots of race prone code there. May be some was recently fixed by bz@, but definitely not merged to stable/8. Thanks a lot guys. For now, I disabled IPv6 on this BRAS. Let's see if it's going to help. Hi, Any changes in stability ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: mpd5/Netgraph issues after upgrading to 7.4
On 6/18/2012 6:51 PM, Adrian Chadd wrote: Hi, Is it possible to get you to setup a test BRAS running 9-STABLE, so you can provide feedback about how stable ipv4/ipv6 PPPoE is for you? I have another LNS to deploy soon and I can enable IPv6 and use RELENG9. I have in the past been able to trigger the panic after a few days of use with IPv6 enabled. Should have it up and running in a week or so. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: mpd5/Netgraph issues after upgrading to 7.4
On 6/15/2012 4:31 PM, Gleb Smirnoff wrote: On Fri, Jun 15, 2012 at 01:33:05PM +0200, Przemyslaw Frasunek wrote: P unfortunately, one of my mpd5 PPPoE access servers started panicing every few P hours. P P I'm running recent 8.3-STABLE (as of 23th May) with WITNESS, INVARIANTS and I suspect this isn't related to netgraph, but to IPv6 since prelist_remove() is found in netinet6/nd6_rtr.c. Several times I looked into ND code and found lots of race prone code there. May be some was recently fixed by bz@, but definitely not merged to stable/8. There were a bunch of commits / fixes by BZ on the 5th of June. Perhaps try updating to RELENG_8 as of today. If you are not using IPv6, perhaps disable for a day to see if that makes a difference stability wise ? It did for me back in Nov when running with v6 on an LNS was not stable. http://lists.freebsd.org/pipermail/svn-src-stable-8/2012-June/007555.html ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: IGB freezes after about 2 weeks of uptime
Hi, Try the driver from HEAD. It has a number of fixes in it to both the igb and em drivers that is not yet in RELENG_9 nor 8 http://lists.freebsd.org/pipermail/svn-src-head/2012-March/035888.html ---Mike On 4/3/2012 10:19 AM, Darren Baginski wrote: Still getting same errors on FreeBSD srv-4-2.lab.local 9.0-STABLE FreeBSD 9.0-STABLE #3: Mon Apr 2 19:07:20 UTC 2012 r...@srv-4-2.lab.local:/usr/obj/usr/src/sys/GENERIC amd64 It's only me or it's known problem ? 22.02.2012, 23:46, Jack Vogel jfvo...@gmail.com: Mike is correct, 8.3 was looming, it is important to a lot of my customers so it has taken priority, 9 stable will be coming... Jack On Wed, Feb 22, 2012 at 10:55 AM, Mike Tancsa m...@sentex.net mailto:m...@sentex.net wrote: I dont think the driver changes from HEAD were ever MFC'd to 9.x. Only to 8.x ---Mike On 2/22/2012 1:23 PM, Darren Baginski wrote: Same problem on FreeBSD srv-4-2.lab.local 9.0-STABLE FreeBSD 9.0-STABLE #2: Wed Feb 22 18:10:53 UTC 2012 r...@srv-4-2.lab.local mailto:r...@srv-4-2.lab.local:/usr/obj/usr/src/sys/GENERIC amd64 16.02.2012, 02:27, Jack Vogel jfvo...@gmail.com mailto:jfvo...@gmail.com: And assuming its from the release, please upgrade it to HEAD and try again. Jack On Wed, Feb 15, 2012 at 2:14 PM, Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org wrote: are you running the driver from that release, or the -HEAD driver? adrian ___ freebsd-net@freebsd.org mailto: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 mailto:freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailto: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 mailto:freebsd-net-unsubscr...@freebsd.org -- --- Mike Tancsa, tel +1 519 651 3400 tel:%2B1%20519%20651%203400 Sentex Communications, m...@sentex.net mailto:m...@sentex.net Providing Internet services since 1994 www.sentex.net http://www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Intel 82574L interface wedging - em7.3.2/8.2-STABLE
On 3/20/2012 2:57 PM, John Baldwin wrote: TX when link becomes active. I've also updated it to fix resume for em and igb to DTRT when buf_ring is used, and to not include old-style start routines at all when using multiq. It is at http://www.freebsd.org/~jhb/patches/e1000_txeof2.patch Thank for the patch sirs, so far it does look like it did the trick. I'll know for certain here in a few days if I'm still in the clear. I'm guessing after it goes through some more testing it'll be too late to slip it into 8.3? Yes, this is too late for 8.3, but thanks for testing! Hi, Is there a RELENG_8 version of this patch ? I have a server that used to shows this issue quite a bit, but has not since 7.3.2. I would be happy to stress it on the box. The patch above does not apply cleanly due to the netmap diffs, but I can manually merge if thats the only difference. em1: Intel(R) PRO/1000 Network Connection 7.3.2 port 0x2000-0x201f mem 0xb410-0xb411,0xb412-0xb4123fff irq 16 at device 0.0 on pci11 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:ed:68:a4 em1@pci0:11:0:0:class=0x02 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xb410, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x2000, size 32, enabled bar [1c] = type Memory, range 32, base 0xb412, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ed68a4 -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Intel 82574L interface wedging - em7.3.2/8.2-STABLE
On 3/16/2012 11:52 AM, Adrian Chadd wrote: Can someone please just send me some recent em/igb hardware? I'll sit down and find ways to break things and help Jack fix them. I've been knee deep in this crap with ath(4) so I'm well versed now in the art of making your NIC and network stack not angry. The 82574L is not that common on NICs and tends to be on server motherboards. igb is easy enough to source. ---Mike Adrian ___ 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 -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: IGB freezes after about 2 weeks of uptime
I dont think the driver changes from HEAD were ever MFC'd to 9.x. Only to 8.x ---Mike On 2/22/2012 1:23 PM, Darren Baginski wrote: Same problem on FreeBSD srv-4-2.lab.local 9.0-STABLE FreeBSD 9.0-STABLE #2: Wed Feb 22 18:10:53 UTC 2012 r...@srv-4-2.lab.local:/usr/obj/usr/src/sys/GENERIC amd64 16.02.2012, 02:27, Jack Vogel jfvo...@gmail.com: And assuming its from the release, please upgrade it to HEAD and try again. Jack On Wed, Feb 15, 2012 at 2:14 PM, Adrian Chadd adr...@freebsd.org wrote: are you running the driver from that release, or the -HEAD driver? adrian ___ 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 ___ 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 -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em0 hangs on 8-STABLE again
On 1/29/2012 1:21 PM, Jack Vogel wrote: No, I told Mike I'd get it into 8.x, have just been busy, but will try and get it pushed up in the queue. Thanks Jack, I see its now MFC'd into RELENG_8! em1: Intel(R) PRO/1000 Network Connection 7.3.2 port 0x2000-0x201f mem 0xb410-0xb411,0xb412-0xb4123fff irq 16 at device 0.0 on pci11 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] Just curious, does RELENG_9 have this version as well ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em0 hangs on 8-STABLE again
On 1/29/2012 4:38 AM, Lev Serebryakov wrote: Hello, Freebsd-net. My home server lost connection on em0 this night again. It was persistent problem some times ago, but with version 7.2.3 it is first time, but with worse symptoms. 7.3.0 from HEAD is quite stable for me. Hopefully it will be MFC'd soon :) ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: stateful firewall implementation in FreeBSD
On 1/26/2012 12:24 PM, satish amara wrote: Hi, I have question regarding stateful firewall implementation of FreeBSD. IPF has stateful “keep state” option. Hi, Take a look at pf, not ipf. ipf is not really maintained or used much any more under FreeBSD. With respect to dealing with congestion, there are many params you can tune in pf. Take a look at the man pages for pf.conf for details as you can control how this situation is dealt with to some degree. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Firewall Profiling.
On 12/27/2011 6:36 AM, Alexander V. Chernikov wrote: Is IPFW efficient enough to firewall 2x10GE (in+out) interfaces without much latency increase, when running on modern hardware with Intel NICs? Majority of processing tasks would probably be setfib according to matches in tables. IPFW seems to add more or less constant overhead per rule. In our setup, ~20 rules increase load by 100% (one core). We are able to reach 10GE (1.1mpps) on some routers with most packets travelling 8-10 ipfw rules. However, even with ipfw add 1 allow ip from any to any 1.1 mpps routing utilizes E5645 by more that 80%. (with IGP routes in rtable only). YMMV, but 2x10G is too much at the moment even without ipfw. Dont some of the modern 10G adapters support filtering in the card itself ? eg cxgbe. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: igb performance/load udp issue
On 12/21/2011 1:46 AM, Jack Vogel wrote: I was fighting with UDP issues before the latest checkin, so you should look at THAT version, 2.3.1 in HEAD please. Hi Jack, Is there a stand alone version of 2.3.1 that we can try on RELENG_9 and RELENG_8 ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled
On 10/26/2011 7:33 AM, Jason Wolfe wrote: Hooman, I have run with dev.em.X.flow_control=0, which should have the same result as hw.em.fc_setting=0, and net.inet.tcp.tso is also 0. I'm not sure the remaining options would be able to produce the scenario I'm seeing, but I'm open to giving it a try with no options on the interfaces. I've also added ifconfig output to the collection. options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC ifconfig emX -rxcsum -txcsum -vlanhwtag -tso -wol options=88VLAN_MTU,VLAN_HWCSUM It's always TX, but these servers push ~12x what they receive, so I'm guessing it could happen to either buffer given the right traffic patterns. While looking through commits I also found a patch to add a couple sysctls for em, which I'm adding - http://freshbsd.org/commit/freebsd/r223676 Can you provide some more details as to how traffic flows on these servers ? Are they going through them, or are they generating the traffic ? I wonder given a smaller CPU, it would be easier to trigger the condition somehow. We recently got a Soekris 6501 which has onboard 4 such em nics, but has just a 1Ghz Atom. em0@pci0:5:0:0: class=0x02 card=0x8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82574L Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xa100, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x2000, size 32, enabled bar [1c] = type Memory, range 32, base 0xa102, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled em1@pci0:6:0:0: class=0x02 card=0x8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82574L Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xa200, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x3000, size 32, enabled bar [1c] = type Memory, range 32, base 0xa202, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled em2@pci0:10:0:0:class=0x02 card=0x8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82574L Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xa300, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x4000, size 32, enabled bar [1c] = type Memory, range 32, base 0xa302, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled em3@pci0:11:0:0:class=0x02 card=0x8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82574L Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xa400, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x5000, size 32, enabled bar [1c] = type Memory, range 32, base 0xa402, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled soekris6501# vmstat -i interrupt total rate irq4: uart0 4993 0 cpu0:timer 84947808 71 irq256: ahci0 59195 0 irq257: em0:rx 0 1946546 1 irq258: em0:tx 0 629707 0 irq259: em0:link 2 0 Total 87588251 73 soekris6501# -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: very strange arp problem after ip move - icmp works udp doesn't
On 10/21/2011 8:41 PM, Steven Hartland wrote: Seems like the flow table is pretty broken then with respect changing arp entries, at least in 8.2-RELEASE :( Its been removed from the default kernel back in April Author: bz Date: Sat Apr 9 12:04:35 2011 New Revision: 220486 URL: http://svn.freebsd.org/changeset/base/220486 Log: MFC r219775: For now remove options FLOWTABLE from the remaining GENERIC kernel configurations and make it opt-in for those who want it. LINT will still build it. While it may be a perfect win in some scenarios, it still troubles users (see PRs) in general cases. In addition we are still allocating resources even if disabled by sysctl and still leak arp/nd6 entries in case of interface destruction. Discussed with: qingli (2010-11-24, just never executed) Discussed with: juli (OCTEON1) PR: kern/148018, kern/155604, kern/144917, kern/146792 ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: strange ipv6 on 9.0-BETA3
On 10/11/2011 9:16 AM, dikshie wrote: Hi, My host has two interfaces em0 and em1. Both interfaces are connected to different switches. I have been deleted all ipv6 entries in /etc/rc.conf and rebooted the host. why the ifconfig shows ipv6 address on em1 like this: - how come em1 has ipv6 address? it is very strange. any idea, how to debug/fix this? Do you have any other routing daemons like quagga ? Perhaps at boot up time, try and put the switch port into monitor mode and see what is going back and forth, and from who ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled
cpu1: timer 1209264969 2000 cpu3: timer 1209266038 2000 cpu2: timer 1209265460 2000 Total 6086807515 10067 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xb410, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x2000, size 32, enabled bar [1c] = type Memory, range 32, base 0xb412, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ed68a4 ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: [PATCH] Don't have ICMP Echo Replies copy fragmentation flags from Echo Request
On 10/7/2011 11:54 AM, Ryan Stone wrote: Currently when FreeBSD responds to a ICMP Echo Request, it takes the original mbuf, rewrites a couple of fields (like the src/dst IP and the ICMP type), and then sends that mbuf back. As things are currently implemented, the Don't Fragment bit is kept in the ICMP replay. This can cause problems for large ICMP Echo Requests if the MTU on the return route is less than the MTU on the incoming route and the DF bit is set(Linux's ping command sets it by default). Not sure, but would this not be a good thing in some cases ? Having ping behave in this manner would help you discover such PMTU issues no ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled
On 10/7/2011 2:59 PM, Jason Wolfe wrote: Mike, I had a large pool of servers running 7.2.3 with MSI-X enabled during my testing, but it didn't resolve the issue. I just pulled back the sys/dev/e1000 directory from 8-STABLE and ran it on 8-RELEASE-p2 though, so if there were changes made outside of the actual driver code that helped I may have not seen the benefit. It's possible the lagg is adding some complication, but when one of the interfaces wedge the lagg continues to operate over the other link (though half of the traffic simply fails). It appears the interface just runs out of one of its buffers, and is helpless to resolve it without a bounce. I do recall coming across the ASPM threads, but my Supermicro boards didn't have the option and many people claimed it didn't resolve it, so I didn't follow through. I'll do a bit more digging there, thanks. Disabling MSI-X has without a doubt completely resolved my problem though. I would receive about 30 reports/failures a day from my servers when I was running with it, since disabling it I haven't received a single one in ~40 days. The servers are currently running with the 7.2.3 driver also, so if nothing jumps out from my original email I'm happy to re enable it on a handful of servers and collect some fresh reports. Hi Jason, This sounds like a real drag :( You certainly have WAY more servers to sample from than I do/did (a couple). The problem on my boxes were not very frequent to start with, so it would take a while. But the symptoms were very similar in that I would see queue overruns in the stats when things were wedged. I have other em nics (non 82574) that get the odd overrun when they are busy, but they seem to recover from the situation just fine. The 82574 did not. When you disable MSI-X, you mean via hw.pci.enable_msix=0 across the board, or you disable multi-queue for the NIC, so it uses just one interrupt, rather than separate ones for xmit and recv ? Also, what is the purpose of hw.pci.do_power_nodriver=3 vs 0 (3 means put absolutely everything in D3 state.) net.link.ifqmaxlen 1024 vs 50 (does anything else need to be adjusted of this value is increased?) hw.em.rxd=2048 hw.em.txd=2048 Have you tried leaving these two at the default on 7.2.3 ? if_em.h implies 1024 for each. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled
On 10/7/2011 3:55 PM, Arnaud Lacombe wrote: When you disable MSI-X, you mean via hw.pci.enable_msix=0 across the board, or you disable multi-queue for the NIC, so it uses just one interrupt, rather than separate ones for xmit and recv ? em(4)'s multiqueue is misleading. By default, with MSI-X enabled, before AFAIK, April 2010 it used 2 (RX+TX) queue + 1, ie. 5 MSI-X vectors[0]. After April 2010, it uses 1 * (RX+TX) queue + 1, ie. 3 MSI-X vectors. There is no logic for the driver to use 1 vector with MSI-X enabled. Hi, Very poor choice of wording on my part. I meant to say separate interrupts for the xmit and recv, as opposed to multiqueue which is quite different. On the server I used to see the issue with, it has 2 onboard NICs em0: Intel(R) PRO/1000 Network Connection 7.2.3 port 0x4040-0x405f mem 0xb450-0xb451,0xb4525000-0xb4525fff irq 16 at device 25.0 on pci0 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:ed:68:a5 em1: Intel(R) PRO/1000 Network Connection 7.2.3 port 0x2000-0x201f mem 0xb410-0xb411,0xb412-0xb4123fff irq 16 at device 0.0 on pci11 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:ed:68:a4 irq257: em0506496667813 irq258: em1:rx 0 296438098476 irq259: em1:tx 0 252033695404 Actually, I see it in Jason's email now that I re-read it. hw.em.enable_msix=0 However, with 7.1.9 this setting did not help me. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled
On 10/7/2011 4:26 PM, Arnaud Lacombe wrote: em0: Intel(R) PRO/1000 Network Connection 7.2.3 port 0x4040-0x405f mem 0xb450-0xb451,0xb4525000-0xb4525fff irq 16 at device 25.0 on pci0 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:ed:68:a5 em1: Intel(R) PRO/1000 Network Connection 7.2.3 port 0x2000-0x201f mem 0xb410-0xb411,0xb412-0xb4123fff irq 16 at device 0.0 on pci11 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:ed:68:a4 I'd assume that `em0' is not a 82574, whereas `em1' is. Correct. It was em1 that used to wedge for me. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: system locks up with vr driver on alix board
On 8/16/2011 9:39 PM, Ask Bjørn Hansen wrote: Honestly I'm not sure. I only know how to see the interrupt busy percentage from top …Is there a cheap way to get those numbers?If so then I'll log them every second or two and see if it catches anything. also, does sysctl -w dev.vr.0.stats=1 sysctl -w dev.vr.1.stats=1 sysctl -w dev.vr.2.stats=1 show any errors for the NICs ? vmstat -i ? -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: strange problem FreeBSD-8.1-Release
On 8/17/2011 7:46 AM, Sami Halabi wrote: Hi, I have a FBSD router base on version 8.1-RELEASE-p4. Today at 13:00 approx i had a sudden fall down of the traffic on the graphs on all ports. the strange thing is that no connection was lost, but the traffic like went down. on the logs i had these lines only: Aug 17 12:59:45 bgpServer kernel: em2: Watchdog timeout -- resetting Aug 17 12:59:45 bgpServer kernel: em2: link state changed to DOWN Aug 17 12:59:48 bgpServer kernel: em2: link state changed to UP anyone ever faced this problem? any ideas how i can track down what happened there? Until I saw the em errors, I was thinking you are just running into the 32bit counter limitations of snmp. e.g. an example graph at http://www.tancsa.com/overflow.png more info at http://www.cisco.com/en/US/tech/tk648/tk362/technologies_q_and_a_item09186a00800b69ac.shtml However, the em2 suggests a possible driver error. There have been a number of bug fixes to the em driver since 8.1-R. If possible, going to 8.2 or even RELENG_8 might help. also, what does sysctl -a dev.em show ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: system locks up with vr driver on alix board
Grasping at straws here, but when enabling BREAK_TO_DEBUGGER I noticed that the kernel had ZERO_COPY_SOCKETS and TCP_SIGNATURE enabled. I disabled those, just in case. I have a couple of boxes with TCP_SIGNATURE (and IPSEC) in the kernel and they work fine. ZERO_COPY... not so sure of. Do you have any other non standard options in your kernel ? ---Mike --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: system locks up with vr driver on alix board
On 8/17/2011 11:09 AM, Ask Bjørn Hansen wrote: I have a couple of boxes with TCP_SIGNATURE (and IPSEC) in the kernel and they work fine. ZERO_COPY... not so sure of. Do you have any other non standard options in your kernel ? I think the rest are pretty ordinary. It's generic, minus a bunch of drivers, plus DEVICE_POLLING, ALTQ*, CPU_ELAN, CPU_GEODE, CPU_SOEKRIS, HZ=1000. I wasn't using polling, but I tried it after the last reboot to see if it helps (grasping at straws, as I said!). I would take out the polling as well as the HZ setting. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: strange problem FreeBSD-8.1-Release
On 8/17/2011 2:00 PM, Sami Halabi wrote: too many missed packets? any ideas to improve it? RELENG_8 :) Lots of bug fixes and improvements. ---Mike Sami On Wed, Aug 17, 2011 at 8:41 PM, Mike Tancsa m...@sentex.net mailto:m...@sentex.net wrote: On 8/17/2011 12:07 PM, Sami Halabi wrote: Hi, it might be a driver problem... can i update the driver only without updating to 8.2? if so how and from where i can get the update? You are better off updating the box. There are a number of bug fixes you would benefit from. But that being said, if you really need to just try the new driver, csup is the easiest still. cp /usr/share/examples/cvusp/stable-supfile /tmp/ Edit the file, to change the prefix location so as not to override your base src mkdir /usr/RELENG8 In the sup file change the values to prefix=/usr/RELENG8 host=cvsup10.freebsd.org http://cvsup10.freebsd.org csup -g -L2 /tmp/stable-supfile This will get the entire tree, but you can try and then compile as a module to newer em driver in /usr/RELENG8/sys/modules/em here is my sysctl: # sysctl -a dev.em On this old driver, try sysctl -w dev.em.2.stats=1 that will spit out to the console the stats for that nic. dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.0.5 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x10bc subvendor=0x8086 subdevice=0x11bc class=0x02 dev.em.0.%parent: pci28 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.0.5 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=1 dev.em.1.%pnpinfo: vendor=0x8086 device=0x10bc subvendor=0x8086 subdevice=0x11bc class=0x02 dev.em.1.%parent: pci28 dev.em.1.debug: -1 dev.em.1.stats: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 7.0.5 dev.em.2.%driver: em dev.em.2.%location: slot=0 function=0 dev.em.2.%pnpinfo: vendor=0x8086 device=0x10bc subvendor=0x8086 subdevice=0x11bc class=0x02 dev.em.2.%parent: pci29 dev.em.2.debug: -1 dev.em.2.stats: -1 dev.em.2.rx_int_delay: 0 dev.em.2.tx_int_delay: 66 dev.em.2.rx_abs_int_delay: 66 dev.em.2.tx_abs_int_delay: 66 dev.em.2.rx_processing_limit: 100 dev.em.3.%desc: Intel(R) PRO/1000 Network Connection 7.0.5 dev.em.3.%driver: em dev.em.3.%location: slot=0 function=1 dev.em.3.%pnpinfo: vendor=0x8086 device=0x10bc subvendor=0x8086 subdevice=0x11bc class=0x02 dev.em.3.%parent: pci29 dev.em.3.debug: -1 dev.em.3.stats: -1 dev.em.3.rx_int_delay: 0 dev.em.3.tx_int_delay: 66 dev.em.3.rx_abs_int_delay: 66 dev.em.3.tx_abs_int_delay: 66 dev.em.3.rx_processing_limit: 100 Sami On Wed, Aug 17, 2011 at 4:48 PM, Mike Tancsa m...@sentex.net mailto:m...@sentex.net mailto:m...@sentex.net mailto:m...@sentex.net wrote: On 8/17/2011 7:46 AM, Sami Halabi wrote: Hi, I have a FBSD router base on version 8.1-RELEASE-p4. Today at 13:00 approx i had a sudden fall down of the traffic on the graphs on all ports. the strange thing is that no connection was lost, but the traffic like went down. on the logs i had these lines only: Aug 17 12:59:45 bgpServer kernel: em2: Watchdog timeout -- resetting Aug 17 12:59:45 bgpServer kernel: em2: link state changed to DOWN Aug 17 12:59:48 bgpServer kernel: em2: link state changed to UP anyone ever faced this problem? any ideas how i can track down what happened there? Until I saw the em errors, I was thinking you are just running into the 32bit counter limitations of snmp. e.g. an example graph at http://www.tancsa.com/overflow.png more info at http://www.cisco.com/en/US/tech/tk648/tk362/technologies_q_and_a_item09186a00800b69ac.shtml However, the em2 suggests a possible driver error. There have been a number of bug fixes to the em driver since 8.1-R. If possible, going to 8.2 or even RELENG_8 might help. also, what does sysctl -a dev.em show
Re: system locks up with vr driver on alix board
On 8/16/2011 1:41 PM, Ask Bjørn Hansen wrote: Hi everyone, Over the weekend I upgraded a couple of NanoBSD based systems (on PC Engines Alix boards) from 7.4 to 8.2. The box is a small firewall and have been running stable for several years. Since then the busy systems consistently lock up.I had a 'top -bS -s1' running and it stopped a couple hours before the system locked up after showing basically 100% interrupts for a few minutes. (Divided ~50/50 between the two vr interfaces that gets most of the traffic). Another terminal tailing /var/log/messages kept running for another hour or so. An hour or two after the log stopped showing; the system stopped routing packets, but frustratingly kept sending CARP messages out so the secondary firewall didn't pick up the IP addresses to take over. Any ideas? Not sure if CARP has something to do with it as I have quite a few RELENG_8 boxes out there running on Alix boxes (2 and 3 port as well as Soekris 5501s). But I think the 7.4 and 8.2 drivers for vr are essentially the same. That being said, there are some updates in RELENG_8 to the driver. Not sure if that makes any difference to your issue. http://svnweb.freebsd.org/base?view=revisionrevision=223681 MFC r223405: Remove link state change callback handler. There is no need to register both status change and link state change callbacks. Implement checking valid link in state change callback and poll active link state in vr_tick(). This allows immediate detection of lost link as well as protecting driver from frequent link flips during link renegotiation. taskq implementation was removed because driver now needs to poll link state in vr_tick(). While I'm here do not report current link state if interface is not running. - ask -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: igb enable_aim or flow_control causing tcp stalls?
On 7/18/2011 7:20 AM, Steven Hartland wrote: The layout for this test was:- Source (7.0-RELEASE-p2 on em0) - Cisco 6509 - supermicro blade - Target (8.2-RELEASE on igb0) Perhaps this might fix your issue ? http://svnweb.freebsd.org/base?view=revisionrevision=223675 It was MFC'd to RELENG_8 on June 29th ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em driver, 82574L chip, and possibly ASPM
On 7/12/2011 2:54 PM, Hooman Fazaeli wrote: tanx. out of curiosity, can some one pls. explain this? In if_em.c, function em_start_locked, there is: if (txr-tx_avail = EM_TX_CLEANUP_THRESHOLD) em_txeof(txr); inside while loop. While is if_igb.c, function igb_start_locked, a similar code it is out of while loop: if (txr-tx_avail = IGB_TX_CLEANUP_THRESHOLD) igb_txeof(txr); is this intentional or mistake? No idea, but Jack Vogel might know. ---Mike On 7/6/2011 2:58 PM, Mike Tancsa wrote: On 7/6/2011 4:29 AM, Hooman Fazaeli wrote: Can you pls. share the patch for freebsd 7? Its in the tree. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/ ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em driver, 82574L chip, and possibly ASPM
On 7/12/2011 3:03 PM, Hooman Fazaeli wrote: I have similar problems on a couple of 7.3 boxes with latest driver form -CURRENT. I just wanted to know if your 7 boxes work fine so I look for cause else where. Yes, all has been working quite well for me to date. em1@pci0:11:0:0:class=0x02 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ed68a4 em1: Intel(R) PRO/1000 Network Connection 7.2.3 port 0x2000-0x201f mem 0xb410-0xb411,0xb412-0xb4123fff irq 16 at device 0.0 on pci11 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em driver, 82574L chip, and possibly ASPM
On 7/6/2011 4:29 AM, Hooman Fazaeli wrote: Can you pls. share the patch for freebsd 7? Its in the tree. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/ ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: FreeBSD 8.2 and MPD5 stability issues - update
2131 root1 460 7036K 1544K select 1 4:27 5.18% syslogd 1914 root1 440 5248K 3176K select 2 0:17 0.00% devd 73229 root1 440 16384K 8464K wait1 0:02 0.00% bash 2434 root1 440 12144K 4156K select 2 0:01 0.00% sendmail 73222 media 1 440 28500K 4360K select 6 0:00 0.00% sshd 2445 root1 760 7964K 1624K nanslp 0 0:00 0.00% cron 1861 root1 440 8060K 1372K select 0 0:00 0.00% moused 73219 root1 440 28500K 4284K sbwait 4 0:00 0.00% sshd 2438 smmsp 1 440 12144K 3952K pause 1 0:00 0.00% sendmail 73225 root1 450 10300K 2756K pause 5 0:00 0.00% csh 73224 media 1 440 21680K 2024K wait0 0:00 0.00% su 2419 root1 440 16532K 3768K select 0 0:00 0.00% sshd 2538 root1 760 6904K 1284K ttyin 3 0:00 0.00% getty 2536 root1 760 6904K 1284K ttyin 1 0:00 0.00% getty 2539 root1 760 6904K 1284K ttyin 2 0:00 0.00% getty 63542 root1 440 9368K 2444K CPU00 0:00 0.00% top 2533 root1 760 6904K 1284K ttyin 0 0:00 0.00% getty 2537 root1 760 6904K 1284K ttyin 6 0:00 0.00% getty 73223 media 1 450 8336K 1900K wait4 0:00 0.00% sh 2535 root1 760 6904K 1284K ttyin 5 0:00 0.00% getty 2540 root1 760 6904K 1284K ttyin 7 0:00 0.00% getty 2534 root1 760 6904K 1284K ttyin 4 0:00 0.00% getty The incoming calls rate is around 30/sec. If I lower this to 10/sec I'm able to achieve 7000 sessions. -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: FreeBSD 8.2 and MPD5 stability issues
On 6/27/2011 4:50 PM, Adrian Minta wrote: Thanks to Vlad Galu I was able to acquire a full crashinfo and kernel dump after a system freeze. I put all the files at: http://pluto.stsisp.ro/fbsd/ I hope this will help somebody in finding the race condition. Dont know about the race, but one thing I would get rid of in your kernel config is the FLOWTABLE option as it has a few bugs still Also get rid of device gre device tap # Bridging device if_bridge device lagg if you are not using them Are you loading any klds ? Why the linux.ko and linprocfs.ko ? If you dont use it, get rid of it. I would also not run snmpd and disable devd as they will do a lot of work traversing all those interfaces. Also, how come your nics all show no carrier in the crash dump ? ---Mike ___ 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 -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: FreeBSD 8.2 and MPD5 stability issues
On 6/28/2011 3:38 PM, Adrian Minta wrote: Good news ! Last night I remove FLOWTABLE option and since then the server is stable. No crash what so ever an I was able to increase the number of tunnels. Thats great! If you are getting close to the CPU maxing out, consider getting rid of snmpd. Also, as a next step, try and run with ipv6 :) ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: FreeBSD 8.2 and MPD5 stability issues
On 6/25/2011 5:28 PM, Adrian Minta wrote: options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_PRIQ # options ALTQ_NOPCC device pf device pflog device pfsync pf and altq add quite a bit of networking overhead. If you are not using them, I would get rid of them. device hme You really have this nic ? options ZERO_COPY_SOCKETS Not sure how stable this option is. Enable crash dumps crashinfo_enable=YES # Automatically generate crash dump summary. dumpdev=AUTO dumpdir=/var/crash# Directory where crash dumps are to be stored This will create a .txt file in /var/crash that will have all the info about the issue ---Mike ___ 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 -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: FreeBSD 8.2 and MPD5 stability issues
On 6/23/2011 8:55 AM, Adrian Minta wrote: Hello, I am testing a RAS solution and I experience some crashes when the L2TP tunnels grow above 3500. The IPv6 is disabled on the box. With IPv6 enabled the limit is around 1700 (half). Does anyone has a sugesstion what I should try next ? There are many bug fixes to netgraph in RELENG_8. cvsup to stable as a start. How much RAM do you have ? i386 or AMD64 ? ---Mike total traffic: ~ 100mbps load averages: ~1.8 Kernel: FreeBSD 8.2-RELEASE MPD5:mpd-5.5 /boot/loader.conf net.graph.maxdata=65536 net.graph.maxalloc=65536 kern.ipc.maxpipekva=32000 /etc/sysctl.conf net.inet.ip.forwarding=1 kern.maxfiles=65535 net.inet.icmp.icmplim=0 net.inet.ip.fastforwarding=1 kern.ipc.nmbclusters=128 kern.ipc.maxsockbuf=12800 net.graph.maxdgram=1024 net.graph.recvspace=1024 -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: FreeBSD 8.2 and MPD5 stability issues
On 6/23/2011 11:56 AM, Adrian Minta wrote: Sorry if I miss something, but just started using freebsd, I use mostly linux. The server use AMD64 flavor and have 4G of RAM. RELENG_8 is not the prerelease for 8.0 ? I have 8.2-RELEASE isn't it newer ? Hi, RELENG_8 is the present state of what is in the tree and will eventually make 8.3-RELEASE. Its called STABLE, but that means no ABI changes to the branch. But you can generally think of it being stable as well in that the goal is to have less bugs then previous versions. Have a read through http://www.freebsd.org/doc/handbook/updating-upgrading.html Then the broad steps to upgrade your source, cp /usr/share/examples/cvsup/stable-supfile /tmp edit the file in tmp and make sure the line reads as follows for the release *default release=cvs tag=RELENG_8 csup -g -L2 -h cvsup10.freebsd.org /tmp/stable-supfile This will pull down all the source for the RELENG_8, the most uptodate source tree and put it in /usr/src from the cvsup mirror cvsup10.freebsd.org. Where you see references to cvsup (the client app) use instead csup which will do everything you need. then cd /usr/src;make -j2 buildworld b.out;make -j2 buildkernel b.out.k If all goes well, you will see in b.out at the end -- World build completed on Wed Jun 22 07:10:37 EDT 2011 -- and -- Kernel build for GENERIC completed on Wed Jun 22 07:18:49 EDT 2011 -- Then follow the steps to install the kernel and world http://www.freebsd.org/doc/handbook/makeworld.html ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: FreeBSD 8.2 and MPD5 stability issues
On 6/23/2011 1:37 PM, Adrian Minta wrote: *default release=cvs tag=RELENG_8 Then follow the steps to install the kernel and world http://www.freebsd.org/doc/handbook/makeworld.html Thank you ! My server is stable now with 3572 sessions. The issue now seems to be the rate of new connections/sec. When a new ng device is created some scripts are run (like /etc/pccard_ether ). The scripts drive the CPU to 100% and sometimes new connections fail to establish. I guess I have to find a bigger CPU now :) Thats great to hear! Is that with ivp6 enabled or disabled ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: FreeBSD 8.2 and MPD5 stability issues
On 6/23/2011 3:18 PM, Adrian Minta wrote: Oops i spoke too soon ... The system is stable without hyperthreading. With hyperthreading activated i't freezes again. I also run with devd_enable=NO in /etc/rc.conf and in /etc/syctl.conf kern.random.sys.harvest.ethernet=0 Does it actually freeze or panic and crash ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: FreeBSD 8.2 and MPD5 stability issues
On 6/23/2011 4:17 PM, rozhuk...@gmail.com wrote: Try: net.inet.ip.fastforwarding = 0 net.isr.bindthreads = 1 net.isr.direct = 0 net.isr.direct_force = 0 If net.isr.direct is disabled, does setting net.isr.bindthreads do anything ? Also, why disable the fastforwarding ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: FreeBSD 8.2 and MPD5 stability issues
On 6/23/2011 5:47 PM, rozhuk...@gmail.com wrote: net.inet.ip.fastforwarding - double check incoming packet, if: dst = this host / multicast / contain options - all packets processing by one cpu core This option is good for one cpu core routers. Thanks, I didnt know that. And the netisr option ? Have you found that to be buggy ? ---Mike -- Rozhuk Ivan -Original Message- From: Mike Tancsa [mailto:m...@sentex.net] Sent: Friday, June 24, 2011 5:40 AM To: rozhuk...@gmail.com Cc: 'Adrian Minta'; freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues On 6/23/2011 4:17 PM, rozhuk...@gmail.com wrote: Try: net.inet.ip.fastforwarding = 0 net.isr.bindthreads = 1 net.isr.direct = 0 net.isr.direct_force = 0 If net.isr.direct is disabled, does setting net.isr.bindthreads do anything ? Also, why disable the fastforwarding ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: kern/153497: [netgraph] netgraph panic due to race conditions
The following reply was made to PR kern/153497; it has been noted by GNATS. From: Mike Tancsa m...@sentex.net To: Eugene Grosbein egrosb...@rdtc.ru Cc: bug-follo...@freebsd.org Subject: Re: kern/153497: [netgraph] netgraph panic due to race conditions Date: Mon, 09 May 2011 16:34:49 -0400 On 5/9/2011 4:15 PM, Eugene Grosbein wrote: Hi! Could you check out latest RELENG_8? glebius@ mad several changes eliminating races that made my mpd servers pretty stable. Changes have been MFC'd. I am no longer seeing any netgraph panics, but the box is still crashing after about 15 days uptime now. As soon as I track down more information, I will open a new ticket. ---Mike Eugene Grosbein -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em0 performance subpar
On 4/28/2011 3:29 AM, Adam Stylinski wrote: Hello, I have an intel gigabit network adapter (the 1000 GT w/chipset 82541PI) which performs poorly in Freebsd compared to the same card in Linux. I've tried this card in two different freebsd boxes and for whatever reason I get poor transmit performance. I've done all of the tweaking specified in just about every guide out there (the usual TCP window scaling, larger nmbclusters, delayed acks, etc) and still I get only around 600mbps. I'm using jumbo frames, with an MTU of 9000. I'm testing this with iperf. While I realize that this may not be the most realistic test, linux hosts with the same card can achieve 995Mbit/s to another host running this. When the Freebsd box is the server, Linux hosts can transmit to it at around 800 something Mbit/s. I've increased the transmit descriptors as specified in the if_em man page, and while that gave me 20 or 30 more mbit/s, my transmit performance is still below normal. sysctl stats report that the card is trigger a lot of tx_desc_fail2: dev.em.0.tx_desc_fail2: 3431 Try the tests using the tools in /usr/src/tools/tools/netperf to generate / test udp traffic. Perhaps give the driver from HEAD a try. There are a few fixes to it. I back ported it to RELENG_8, but it should work on 8.2R as well. http://www.tancsa.com/em-723.tgz what does pciconf -lvc for your em NIC show ? also, vmstat -i ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em0 performance subpar
On 4/28/2011 10:15 AM, Adam Stylinski wrote: em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.3 port 0xe800-0xe83f mem 0xfe9e-0xfe9f,0xfe9c-0xfe9d irq 20 at device 5.0 on pci7 em0: [FILTER] I am not sure the newer driver will help performance wise. It might fix that bug you saw at least. Jack from intel might be able to shed some light on it. In the mean time, try generating traffic via netblast. Another tool I find helpful in narrowing down tcp performance differences is netperf ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em0 performance subpar
On 4/28/2011 11:35 AM, Adam Stylinski wrote: And the rate output of netblast (using as suggested the parameters above): 119091 This is about 454mbps. Still way slower than it ought to be. Yes, it should do way better than that. I just tried on a couple of 8.2R boxes, E5320 @ 1.86GHz (1866.74-MHz K8-class CPU). Different em nic. Sending side netblast 192.168.5.110 500 450 6 start: 1304007166.789433976 finish:1304007172.789605227 send calls:2829340 send errors: 1374103 approx send rate: 242539 approx error rate: 0 em0: Intel(R) PRO/1000 Network Connection 7.1.9 port 0x2000-0x201f mem 0xd8a0-0xd8a1 irq 18 at device 0.0 on pci4 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:30:48:33:53:cc The receiving side sees em0 Kbps in Kbps out 0.00 0.52 499822.2 0.00 931129.2 0.00 931126.8 0.00 931166.7 0.00 931064.4 0.00 931219.5 0.00 432451.5 0.00 0.47 0.00 -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: mpd5/Netgraph issues after upgrading to 7.4
);
if (tag == NULL) {
m_freem(m);
return;
}
- *(unsigned short *)(tag + 1) = sa-sa_family;
+ *(unsigned short *)(tag + 1) = saf;
m_tag_prepend(m, tag);
}
#ifdef VIMAGE
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.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: mpd5/Netgraph issues after upgrading to 7.4
On 4/11/2011 10:05 AM, Brandon Gooch wrote:
2011/4/11 Mike Tancsa m...@sentex.net:
On 4/11/2011 1:49 AM, Gleb Smirnoff wrote:
On Mon, Apr 11, 2011 at 12:34:56AM +0200, Przemyslaw Frasunek wrote:
P Use command vmstat -z|egrep 'ITEM|NetGraph' and check
FAILURES column.
P If you see non-zero values there, you need to increase netgraph
memory limits
P net.graph.maxdata and net.graph.maxalloc using /boot/loader.conf.
P
P Unfortunately, increasing net.graph.maxdata net.graph.maxalloc
didn't
P solved EPERM problems on netgraph control sockets. It is still
appearing
P every few hours, but failure counters are zero:
IMO, any kind of memory allocation code (malloc, uma, netgraph item
allocator) never return EPERM, they return ENOMEM or ENOBUFS.
So, there is a bug somewhere else.
I am also running with the following patch from mlaier that is not in
RELENG_8.
--- rtsock.c2010-10-30 07:54:55.0 -0400
+++ /tmp/rtsock.c 2011-04-11 09:44:52.0 -0400
@@ -27,7 +27,7 @@
* SUCH DAMAGE.
*
* @(#)rtsock.c8.7 (Berkeley) 10/12/95
- * $FreeBSD: src/sys/net/rtsock.c,v 1.181.2.10 2010/10/30 11:54:55
bz Exp $
+ * $FreeBSD: src/sys/net/rtsock.c,v 1.191 2011/02/10 01:24:09 mlaier
Exp $
*/
So it's in HEAD? If so, any ideas about a possible MFC?
I dont think all of it is. Here is the diff from HEAD. Adding Max
Laier to the cc list as he was the one kind enough to send me the patch.
--- rtsock.c2011-02-14 20:43:05.0 -0500
+++ /tmp/rtsock.c 2011-04-11 09:44:52.0 -0400
@@ -159,7 +159,7 @@
struct rt_metrics_lite *out);
static voidrt_getmetrics(const struct rt_metrics_lite *in,
struct rt_metrics *out);
-static voidrt_dispatch(struct mbuf *, const struct sockaddr *);
+static voidrt_dispatch(struct mbuf *, sa_family_t);
static struct netisr_handler rtsock_nh = {
.nh_name = rtsock,
@@ -513,6 +513,7 @@
int len, error = 0;
struct ifnet *ifp = NULL;
union sockaddr_union saun;
+ sa_family_t saf = AF_MAX;
#define senderr(e) { error = e; goto flush;}
if (m == NULL || ((m-m_len sizeof(long))
@@ -549,6 +550,7 @@
(info.rti_info[RTAX_GATEWAY] != NULL
info.rti_info[RTAX_GATEWAY]-sa_family = AF_MAX))
senderr(EINVAL);
+ saf = info.rti_info[RTAX_DST]-sa_family;
/*
* Verify that the caller has the appropriate privilege; RTM_GET
* is the only operation the non-superuser is allowed.
@@ -892,10 +894,10 @@
*/
unsigned short family = rp-rcb_proto.sp_family;
rp-rcb_proto.sp_family = 0;
- rt_dispatch(m, info.rti_info[RTAX_DST]);
+ rt_dispatch(m, saf);
rp-rcb_proto.sp_family = family;
} else
- rt_dispatch(m, info.rti_info[RTAX_DST]);
+ rt_dispatch(m, saf);
}
/* info.rti_info[RTAX_DST] (used above) can point inside of rtm */
if (rtm)
@@ -1142,7 +1144,7 @@
rtm-rtm_flags = RTF_DONE | flags;
rtm-rtm_errno = error;
rtm-rtm_addrs = rtinfo-rti_addrs;
- rt_dispatch(m, sa);
+ rt_dispatch(m, sa ? sa-sa_family : AF_MAX);
}
/*
@@ -1167,7 +1169,7 @@
ifm-ifm_flags = ifp-if_flags | ifp-if_drv_flags;
ifm-ifm_data = ifp-if_data;
ifm-ifm_addrs = 0;
- rt_dispatch(m, NULL);
+ rt_dispatch(m, AF_MAX);
}
/*
@@ -1237,7 +1239,7 @@
rtm-rtm_errno = error;
rtm-rtm_addrs = info.rti_addrs;
}
- rt_dispatch(m, sa);
+ rt_dispatch(m, sa ? sa-sa_family : AF_MAX);
}
}
@@ -1273,7 +1275,7 @@
__func__));
ifmam-ifmam_index = ifp-if_index;
ifmam-ifmam_addrs = info.rti_addrs;
- rt_dispatch(m, ifma-ifma_addr);
+ rt_dispatch(m, ifma-ifma_addr ? ifma-ifma_addr-sa_family :
AF_MAX);
}
static struct mbuf *
@@ -1333,7 +1335,7 @@
if (m-m_flags M_PKTHDR)
m-m_pkthdr.len += data_len;
mtod(m, struct if_announcemsghdr *)-ifan_msglen +=
data_len;
- rt_dispatch(m, NULL);
+ rt_dispatch(m, AF_MAX);
}
}
@@ -1349,11 +1351,11 @@
m = rt_makeifannouncemsg(ifp, RTM_IFANNOUNCE, what, info);
if (m != NULL)
- rt_dispatch(m, NULL);
+ rt_dispatch(m, AF_MAX);
}
static void
-rt_dispatch(struct mbuf *m, const struct sockaddr *sa)
+rt_dispatch(struct mbuf *m, sa_family_t saf)
{
struct m_tag *tag;
@@ -1362,14 +1364,14 @@
* use when injecting the mbuf into the routing socket buffer from
* the netisr.
*/
- if (sa != NULL) {
+ if (saf != AF_MAX) {
tag = m_tag_get(PACKET_TAG_RTSOCKFAM, sizeof(unsigned
short
Re: mpd- no ng_l2tp coming up
On 3/16/2011 9:32 PM, Da Rock wrote: I'm running into all sorts of issues setting up l2tp networking. I think I have the IPSEC part worked out, but testing parts at a time l2tp dies in a hole. Try without IPSEC first to make sure you have the l2tp portion correct. Also, make sure no firewall rules are getting in the way. I have this simple mpd5 config file to act as an l2tp server in my test environment startup: # configure mpd users set user admin xxx admin # configure the console set console self 127.0.0.1 5005 set console open # configure the web server set web self 192.168.255.254 5006 set web open log +IPV6CP log +IPV6CP2 default: load l2tpserver l2tpserver: # Define dynamic IP address pool. set ippool add pool1 xx.159.245.1 xx.159.245.5 set ippool add pool1 10.241.241.20 10.241.241.99 set ippool add rfc1918 172.11.22.140 172.11.22.180 # Create clonable bundle template named B create bundle template B set iface idle 1800 set iface enable tcpmssfix set ipcp disable vjcomp set bundle enable ipv6cp set ipcp deny vjcomp set ipcp ranges xx.43.128.6/32 ippool pool1 set ipcp dns yy.211.164.51 zz.212.134.12 #set ipcp nbns 127.0.0.1 # Set bundle template to use create link template L l2tp set l2tp hostname sentex set l2tp disable dataseq set link action bundle B # Enable peer authentication set link disable eap set link enable pap set link disable acfcomp set link disable protocomp set link disable check-magic set link deny acfcomp set link keep-alive 10 60 set link deny protocomp #load radius set link mtu 1492 set link mru 1492 set link enable incoming set link disable peer-as-calling For the client, mpd5 works with the following config l2tp_client: # # PPPoE client: only outgoing calls, auto reconnect, # ipcp-negotiated address, one-sided authentication, # default route points on ISP's end # create bundle static B1 set iface route default set ipcp ranges 0.0.0.0/0 0.0.0.0/0 create link static L1 l2tp set link action bundle B1 set auth authname testaccount-in-mpd-secret-file set auth password thepass set link max-redial 0 set link mtu 1460 set link keep-alive 20 75 set l2tp peer 64.7.128.195 open I also had an unscheduled reboot (power failure) and that showed up a warning: attempt to domain_add(netgraph) after domainfinalize() which I could never quite figure was fatal or not. Thats ok. Its not an issue and is more informational than anything It appears the control connection is setup and then fails for some inexplicable reason. The client (android) logs show the same, but it is definitely the server that kills the connection. Anything I've missed? Make sure there are no firewall rules getting in the way. And if possible, use a client that you know works. The above server works with Windows clients with IPSEC disabled. Start there, or with a FreeBSD client. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em0 with latest driver hangs again and again (without Watchdogtimeout message!)
On 3/11/2011 12:23 PM, Jack Vogel wrote: So, now the driver does not hang but cpu is too high... Anyone else find this to be the case that is testing this driver? Just eyeballing the load avg graphs on the 2 boxes where I am testing, I dont see any glaring differences. But I have not set out to do any specific measurements / tests in that regard. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: i386 kernel hangs, seemingly on em0 attachment.
On 3/2/2011 9:38 AM, Kostik Belousov wrote: Hi, I have an issue with Core-i5 system and onboard em adapter on the Intel DH55HC Desktop Board. em0: Intel(R) PRO/1000 Network Connection 7.1.9 port 0xf040-0xf05f mem 0xfe50-0xfe51,0xfe528000-0xfe528fff irq 20 at device 25.0 on pci0 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 em0: using IRQ 256 for MSI em0: Using an MSI interrupt The machine with i386 kernel hangs with the last lines of the kernel output listed above. amd64 version boots flawless. Interesting detail is that even reset starts to act when the machine hangs, pressing the button causes a reset only after 10-20 seconds. Removing if_em from the list of loaded modules allows kernel to finish loading and gives me the / selection dialog, which is unuseful since machine is pxebooted. em0 is the onboard adapter, also there is em1 in the pci slot. em0@pci0:0:25:0: class=0x02 card=0x00378086 chip=0x10f08086 rev=0x06 hdr=0x00 em1@pci0:1:2:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 System is today HEAD. if_em is loaded as module. pxeboot. Any help ? This rings a bell. I saw a similar issue with the same desktop board. If I compiled em into the kernel, it would netboot just fine. But as a module, it would not for some reason. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em0 with latest driver hangs again and again (without Watchdog timeout message!)
I have been running with 7.2.2 and so far so good. However, its hard to say in my case as the box I would only periodically see the issue. Jan, have you had a chance to try 7.2.2 ? You seemed to hit the issue the most frequently. There are also some alternate patches in http://www.freebsd.org/cgi/query-pr.cgi?pr=150516 But I think Jack said 7.2.2 takes a similar strategy ? ---Mike On 2/24/2011 3:03 AM, Özkan KIRIK wrote: Thank you. I'll test and share my experiences with you. On Wed, Feb 23, 2011 at 7:47 PM, Jack Vogel jfvo...@gmail.com wrote: Here is the 7.2.2 tarball. IMPORTANT: if you use this DO NOT try and put it into your kernel source tree, it will break that. What you must do is config the em driver OUT of your kernel, then untar this, build it standalone, and then load it. This is just a temporary thing, once I have data to decide on this change vs the earlier one it will get integrated. Jack 2011/2/23 Özkan KIRIK ozkan.ki...@gmail.com Hi, How can we get 7.2.2. version of if_em driver ? I wanna test it. I can help you for testing changes to em drivers. Regards, Ozkan KIRIK On Wed, Feb 23, 2011 at 1:36 PM, Lev Serebryakov l...@serebryakov.spb.ru wrote: Hello, Mike. You wrote 23 февраля 2011 г., 14:16:28: Driver from em driver, 82574L chip, and possibly ASPM thread doesn't help, really: it seems, that it decrease frequincy of hangs, Looking at your sysctl output, you are not using the test drivers posted in that thread. Yes, as it doesn't help, I've reverted to stock one. If you want to try 7.1.9-test, you can download it at http://www.tancsa.com/if_em-8.c for releng_8. I've tried it. It has worked without hangs for 7-8 days, and after that hangs 2 times in 3 days with 7.1.9-test :( -- // Black Lion AKA Lev Serebryakov l...@serebryakov.spb.ru ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em0 with latest driver hangs again and again (without Watchdog timeout message!)
On 2/23/2011 4:16 AM, Lev Serebryakov wrote: Driver from em driver, 82574L chip, and possibly ASPM thread doesn't help, really: it seems, that it decrease frequincy of hangs, Looking at your sysctl output, you are not using the test drivers posted in that thread. sysctl dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 dev.em.0.%driver: em It should show dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.9-test If you want to try 7.1.9-test, you can download it at http://www.tancsa.com/if_em-8.c for releng_8. However, there is a newer one Jack has, 7.2.2 which seems to work for me as well so far and has additional fixes that the 7.1.9-test cvsup to RELENG_8, then copy if_em-8.c to /usr/src/sys/dev/e1000/if_em.c ---Mike ___ 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 hangs without any messages like Watchdog timeout, only down/up reset it.
On 2/6/2011 4:40 PM, Lev Serebryakov wrote: Hello, Freebsd-stable. It hangs under load without any output. When it works with POLLING, it prints Watchdog timeout and reset automatically several times a day, but without POLLING it simply hangs with same frequency. It is 8.2-PRERELEASE (from RELENG_8), cvsupped AFTER 22 Jan (last commit to e1000 drivers family). Locally system works, but mbufs are overfilled. ifconfig em0 down ifconfig em0 up solves problem. In non polling mode, do you have any special network or driver settings in /boot/loader.conf or /etc/sysctl.conf ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em0 hangs without any messages like Watchdog timeout, only down/up reset it.
/boot/loader.conf: hw.em.rxd=4096 hw.em.txd=4096 net.link.ifqmaxlen=16384 /etc/sysctl.conf: dev.em.0.rx_int_delay=200 dev.em.0.tx_int_delay=200 dev.em.0.rx_abs_int_delay=4000 dev.em.0.tx_abs_int_delay=4000 dev.em.0.rx_processing_limit=4096 I'm trying to run with patch from em driver, 82574L chip, and possibly ASPM thread now under heavy network load. Hi Lev, What if you try with just the defaults ? Not sure the patch posted by jack and sean will help as its meant for a specific type of em nic, but the RELENG_8 version I am testing with is here http://www.tancsa.com/if_em-8.c. There is a patch to jack's patch by Sean as well thats incorporated in that version ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: MSS rewrite / MSS clamping?
On 2/5/2011 11:07 PM, Jason Fesler wrote: I'm in search of MSS clamping for FreeBSD servers; in particular, for IPv6. I'm finding pretty much nothing (except iptables..) on the net. Hi, I am curious as to where you would be running into MTU issues on IPv6 where you would need to manually compensate ? Broken tunnel providers ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: em driver, 82574L chip, and possibly ASPM
So far so good. I would often get a hang on the level zero dumps to my
backup server Sunday AM, and it made it through! So a good sign, but
not a definitive sign.
I have a PCIe em card that has this chipset as well and was showing the
same sort of problem in a customer's RELENG_7 box. I will see if I can
get the customer to try the card in their box with the patch for
RELENG_7 as it would show this issue at least once a day until I pulled
the card for an older version
---Mike
On 2/4/2011 1:12 PM, Jack Vogel wrote:
Was curious too, but being more patient than you :)
Jack
On Fri, Feb 4, 2011 at 10:09 AM, Sean Bruno sean...@yahoo-inc.com wrote:
Any more data on this problem or do we have to wait a while?
Sean
On Wed, 2011-02-02 at 10:28 -0800, Mike Tancsa wrote:
On 2/2/2011 12:37 PM, Jack Vogel wrote:
So has everyone that wanted to get something testing been able to do
so?
I have been testing in the back and will deploy to my production box
this afternoon. As I am not able to reproduce it easily, it will be a
bit before I can say the issue is gone. Jan however, was able to
trigger it with greater ease ?
---Mike
Jack
On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa m...@sentex.net wrote:
On 2/1/2011 5:03 PM, Sean Bruno wrote:
On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote:
To those who are going to test, here is the if_em.c, based on head,
with my
changes, I have to leave for the afternoon, and have not had a
chance
to build
this, but it should work. I will check back in the later evening.
Any blatant problems Sean, feel free to fix them :)
Jack
I suspect that line 1490 should be:
if (more_rx || (ifp-if_drv_flags IFF_DRV_OACTIVE)) {
I have hacked up a RELENG_8 version which I think is correct including
the above change
http://www.tancsa.com/if_em-8.c
--- if_em.c.orig2011-02-01 21:47:14.0 -0500
+++ if_em.c 2011-02-01 21:47:19.0 -0500
@@ -30,7 +30,7 @@
POSSIBILITY OF SUCH DAMAGE.
**/
-/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53
jfv Exp $*/
+/*$FreeBSD$*/
#ifdef HAVE_KERNEL_OPTION_HEADERS
#include opt_device_polling.h
@@ -93,7 +93,7 @@
/*
* Driver version:
*/
-char em_driver_version[] = 7.1.9;
+char em_driver_version[] = 7.1.9-test;
/*
* PCI Device ID Table
@@ -927,11 +927,10 @@
if (!adapter-link_active)
return;
-/* Call cleanup if number of TX descriptors low */
- if (txr-tx_avail = EM_TX_CLEANUP_THRESHOLD)
- em_txeof(txr);
-
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
+ /* First cleanup if TX descriptors low */
+ if (txr-tx_avail = EM_TX_CLEANUP_THRESHOLD)
+ em_txeof(txr);
if (txr-tx_avail EM_MAX_SCATTER) {
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
break;
@@ -1411,8 +1410,7 @@
if (!drbr_empty(ifp, txr-br))
em_mq_start_locked(ifp, txr, NULL);
#else
- if (!IFQ_DRV_IS_EMPTY(ifp-if_snd))
- em_start_locked(ifp, txr);
+ em_start_locked(ifp, txr);
#endif
EM_TX_UNLOCK(txr);
@@ -1475,11 +1473,10 @@
struct ifnet*ifp = adapter-ifp;
struct tx_ring *txr = adapter-tx_rings;
struct rx_ring *rxr = adapter-rx_rings;
- boolmore;
-
if (ifp-if_drv_flags IFF_DRV_RUNNING) {
- more = em_rxeof(rxr, adapter-rx_process_limit, NULL);
+ boolmore_rx;
+ more_rx = em_rxeof(rxr, adapter-rx_process_limit,
NULL);
EM_TX_LOCK(txr);
em_txeof(txr);
@@ -1487,12 +1484,10 @@
if (!drbr_empty(ifp, txr-br))
em_mq_start_locked(ifp, txr, NULL);
#else
- if (!IFQ_DRV_IS_EMPTY(ifp-if_snd))
- em_start_locked(ifp, txr);
+ em_start_locked(ifp, txr);
#endif
- em_txeof(txr);
EM_TX_UNLOCK(txr);
- if (more) {
+ if (more_rx || (ifp-if_drv_flags IFF_DRV_OACTIVE))
{
taskqueue_enqueue(adapter-tq,
adapter-que_task);
return;
}
@@ -1604,7 +1599,6 @@
if (!IFQ_DRV_IS_EMPTY(ifp-if_snd))
em_start_locked(ifp, txr);
#endif
- em_txeof(txr);
E1000_WRITE_REG(adapter-hw, E1000_IMS, txr-ims);
EM_TX_UNLOCK(txr);
}
@@ -3730,17 +3724,17 @@
txr-queue_status = EM_QUEUE_HUNG;
/*
- * If we have enough room, clear IFF_DRV_OACTIVE
Re: panic: bufwrite: buffer is not busy???
On 2/5/2011 8:48 AM, Eugene Grosbein wrote: First: again, no dump (not even started to dump, and no Uptime: written to console): if you try and enable dumps manually from the shell, dumpon -v /dev/ad0s1b (or whatever your swap partition is), what does dumpon return with ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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
