Re: Determining cause of transfer limit
On Sat, 21 Nov 2020, Sean C. Farley wrote: I have recently upped my Internet service and have now noticed a limit being reached, but I am not certain which limit and best option to resolve it. I am using a circa 2007 system as a multi-purpose router running FreeBSD 12-STABLE (r367740). The issue is that it maxes out around 400Mb/s when running a speed test through it between my workstation and various test sites (i.e., DSL Reports and Speedtest). There are two NIC's (both are Intel 82541PI) in use with one to the ISP and one to my workstation. At first, I saw one of them apparently hitting an interrupt rate of just over 8000, so I bumped their rate limits higher with little to no improvement. What makes me believe I can theoretically get faster speeds is that I can use the onboard NIC (Marvell 88E8056) to replace one of the NIC's and nearly double the speed. The difference is that it is on the PCI-E bus and has MSI support. irq16: em0:irq0+ irq17: em1:irq0 irq20: hpet0 irq258: mskc0 I have many network settings, but changing them did nothing. Here are the settings I am trying now that seem to squeak a little extra performance. The commented-out lines are ones I tried without seeing any change. I have also tested without these settings. /boot/loader.conf hw.em.rx_process_limit="-1" # dev.em.0.iflib.override_nrxds="2048" # dev.em.1.iflib.override_nrxds="2048" # dev.em.2.iflib.override_nrxds="2048" # dev.em.0.iflib.override_ntxds="2048" # net.link.ifqmaxlen="2048" hw.em.max_interrupt_rate="32000" # net.isr.maxthreads="-1" # net.isr.bindthreads="1" /etc/sysctl.conf kern.random.harvest.mask=351 dev.em.0.fc=0 dev.em.1.fc=0 dev.em.0.itr=122# Allow past 8000 interrupts/second. dev.em.1.itr=122 net.inet.ip.redirect=0 net.inet6.ip6.redirect=0 Increasing these from 66 to 250 did not help: hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.tx_int_delay: 66 I am utilizing pf, but I doubt it is the issue since using the same rules with the msk driver would have held the speed down to 400Mb/s. Am I hitting the limit of the PCI bus (memory or interrupt) or something else? I can buy a new PCI-E NIC for the internal network, but I rather fully utilize the Intel NIC's I have, if possible. Well, I surrendered with using those NIC's. If anyone runs across this thread in the future, I want to let you know that I fixed my issue by buying a used HP multi-port NIC using the Intel 82580 chipset. The only setting I made was to turn off flowcontrol. I may experiment with tweaks (such as bumping dev.igb.N.iflib.override_nrxds) in the future, but it looks like I am in a much better situation already. Sean -- s...@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: Determining cause of transfer limit
On Sat, 21 Nov 2020, Saad, Mark wrote: scf can I use polling on sfxge ? Also if I want to use polling on say ix or sfxge does this break things like pf, bird or nsd ? --- Mark Saad Lucera Financial Infrastructures, LLC ms...@lucera.com I wish I could help, but I have little knowledge about the device polling capability. Did you intend to ask Michael? However, I can say that according to polling(4) man page, neither ix(4) nor sfxge(4) are listed as supported by it. I saw no change regarding pf with polling in the kernel. Finally, polling is recommended (somewhere?) for slower hardware. If you are using a 10Gb adapter, you most likely have a faster system that does not need it. You should ask in a separate E-mail thread if you have issues with that driver or hardware. Sean -- s...@freebsd.org From: owner-freebsd-...@freebsd.org on behalf of Michael Sierchio Sent: Saturday, November 21, 2020 4:55 PM To: Sean C. Farley Cc: freebsd-net@freebsd.org Subject: Re: Determining cause of transfer limit Sorry for the top post. Have you tried device polling? From /usr/src/sys/amd64/conf/NOTES: options DEVICE_POLLING *snip* On Sat, Nov 21, 2020 at 10:24 AM Sean C. Farley wrote: I have recently upped my Internet service and have now noticed a limit being reached, but I am not certain which limit and best option to resolve it. *snip* ___ 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: Determining cause of transfer limit
On Sat, 21 Nov 2020, Michael Sierchio wrote: Sorry for the top post. Have you tried device polling? From /usr/src/sys/amd64/conf/NOTES: ... options DEVICE_POLLING *snip* I had not tried it and had actually forgotten about that capability. Anyway, I just tried it (kernel built with polling and enabled via ifconfig on the devices) and saw no observable change. I am not certain if the code paths can really make use of it with the switch to iflib. However, I was able to squeak a bit more from the NIC's by the equivalent of polling(4) by bumping the delay for interrupts with the key one being hw.em.rx_int_delay. It improved transfers going through the router, in both directions, by about 20Mb/s. The number of interrupts dropped a lot, so I doubt I am hitting an interrupt limit. /boot/loader.conf: hw.em.rx_int_delay="264" hw.em.rx_abs_int_delay="264" hw.em.tx_int_delay="264" hw.em.tx_abs_int_delay="264" One other thing to note, is that when I am testing going through the router, there are many drops and stalls/restarts when downloading but not uploading. Before test: dev.em.1.iflib.txq0.r_abdications: 0 dev.em.1.iflib.txq0.r_restarts: 0 dev.em.1.iflib.txq0.r_stalls: 0 dev.em.1.iflib.txq0.r_starts: 9239 dev.em.1.iflib.txq0.r_drops: 0 dev.em.1.iflib.txq0.r_enqueues: 9240 dev.em.1.iflib.txq0.txq_cleaned: 9640 dev.em.1.iflib.txq0.txq_processed: 9680 After test: dev.em.1.iflib.txq0.r_abdications: 14 dev.em.1.iflib.txq0.r_restarts: 7419 dev.em.1.iflib.txq0.r_stalls: 7419 dev.em.1.iflib.txq0.r_starts: 411677 dev.em.1.iflib.txq0.r_drops: 198 dev.em.1.iflib.txq0.r_enqueues: 878486 dev.em.1.iflib.txq0.txq_cleaned: 875005 dev.em.1.iflib.txq0.txq_processed: 875045 After 2nd test with Marvell as outgoing NIC starting from zero: dev.em.1.iflib.txq0.r_abdications: 1 dev.em.1.iflib.txq0.r_restarts: 7647 dev.em.1.iflib.txq0.r_stalls: 7647 dev.em.1.iflib.txq0.r_starts: 1092018 dev.em.1.iflib.txq0.r_drops: 811 dev.em.1.iflib.txq0.r_enqueues: 1570425 dev.em.1.iflib.txq0.txq_cleaned: 1567629 dev.em.1.iflib.txq0.txq_processed: 1567671 Unless someone knows anything else, I think I am going to have to buy a PCI-E NIC for the router to replace one of the Intel NIC's. I will either use it along with the Marvell or the other Intel NIC. When testing between my workstation and any one Intel NIC on the router using iperf3, I can achieve just over 900Mb/s. Sean -- s...@freebsd.org On Sat, Nov 21, 2020 at 10:24 AM Sean C. Farley wrote: I have recently upped my Internet service and have now noticed a limit being reached, but I am not certain which limit and best option to resolve it. I am using a circa 2007 system as a multi-purpose router running FreeBSD 12-STABLE (r367740). The issue is that it maxes out around 400Mb/s when running a speed test through it between my workstation and various test sites (i.e., DSL Reports and Speedtest). There are two NIC's (both are Intel 82541PI) in use with one to the ISP and one to my workstation. At first, I saw one of them apparently hitting an interrupt rate of just over 8000, so I bumped their rate limits higher with little to no improvement. What makes me believe I can theoretically get faster speeds is that I can use the onboard NIC (Marvell 88E8056) to replace one of the NIC's and nearly double the speed. The difference is that it is on the PCI-E bus and has MSI support. irq16: em0:irq0+ irq17: em1:irq0 irq20: hpet0 irq258: mskc0 I have many network settings, but changing them did nothing. Here are the settings I am trying now that seem to squeak a little extra performance. The commented-out lines are ones I tried without seeing any change. I have also tested without these settings. /boot/loader.conf hw.em.rx_process_limit="-1" # dev.em.0.iflib.override_nrxds="2048" # dev.em.1.iflib.override_nrxds="2048" # dev.em.2.iflib.override_nrxds="2048" # dev.em.0.iflib.override_ntxds="2048" # net.link.ifqmaxlen="2048" hw.em.max_interrupt_rate="32000" # net.isr.maxthreads="-1" # net.isr.bindthreads="1" /etc/sysctl.conf kern.random.harvest.mask=351 dev.em.0.fc=0 dev.em.1.fc=0 dev.em.0.itr=122# Allow past 8000 interrupts/second. dev.em.1.itr=122 net.inet.ip.redirect=0 net.inet6.ip6.redirect=0 Increasing these from 66 to 250 did not help: hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.tx_int_delay: 66 I am utilizing pf, but I doubt it is the issue since using the same rules with the msk driver would have held the speed down to 400Mb/s. Am I hitting the limit of the PCI bus (memory or interrupt) or something else? I can buy a new PCI-E NIC for the internal network, but I rather fully utilize the Intel NIC's I have, if possible. Sean ___ 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"
Determining cause of transfer limit
I have recently upped my Internet service and have now noticed a limit being reached, but I am not certain which limit and best option to resolve it. I am using a circa 2007 system as a multi-purpose router running FreeBSD 12-STABLE (r367740). The issue is that it maxes out around 400Mb/s when running a speed test through it between my workstation and various test sites (i.e., DSL Reports and Speedtest). There are two NIC's (both are Intel 82541PI) in use with one to the ISP and one to my workstation. At first, I saw one of them apparently hitting an interrupt rate of just over 8000, so I bumped their rate limits higher with little to no improvement. What makes me believe I can theoretically get faster speeds is that I can use the onboard NIC (Marvell 88E8056) to replace one of the NIC's and nearly double the speed. The difference is that it is on the PCI-E bus and has MSI support. irq16: em0:irq0+ irq17: em1:irq0 irq20: hpet0 irq258: mskc0 I have many network settings, but changing them did nothing. Here are the settings I am trying now that seem to squeak a little extra performance. The commented-out lines are ones I tried without seeing any change. I have also tested without these settings. /boot/loader.conf hw.em.rx_process_limit="-1" # dev.em.0.iflib.override_nrxds="2048" # dev.em.1.iflib.override_nrxds="2048" # dev.em.2.iflib.override_nrxds="2048" # dev.em.0.iflib.override_ntxds="2048" # net.link.ifqmaxlen="2048" hw.em.max_interrupt_rate="32000" # net.isr.maxthreads="-1" # net.isr.bindthreads="1" /etc/sysctl.conf kern.random.harvest.mask=351 dev.em.0.fc=0 dev.em.1.fc=0 dev.em.0.itr=122# Allow past 8000 interrupts/second. dev.em.1.itr=122 net.inet.ip.redirect=0 net.inet6.ip6.redirect=0 Increasing these from 66 to 250 did not help: hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.tx_int_delay: 66 I am utilizing pf, but I doubt it is the issue since using the same rules with the msk driver would have held the speed down to 400Mb/s. Am I hitting the limit of the PCI bus (memory or interrupt) or something else? I can buy a new PCI-E NIC for the internal network, but I rather fully utilize the Intel NIC's I have, if possible. Sean -- s...@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: NTP - default /etc/ntp.conf
On Thu, 9 Jul 2009, David Malone wrote: The NTP pool guys have set up our vendor domain. I'd like to commit the patch below to ntp.conf. It does the following: 1) Uses our vendor domain at the pool. 2) Points people at the pool website and encourages people to provide a server in the pool (as a courtesy to the pool guys). 3) Fixes a spelling. 4) Comments out the local clock and includes a link to documentation for use of the local clock on the ntp.org site. If there are no objections, I'll ask re@ for permission to commit this. Is 3.freebsd.pool.ntp.org intentionally commented? It does resolve. Reminder: if you do uncomment it, remember to change the "three servers" to four. Otherwise, it looks good to me. David. Index: ntp.conf === --- ntp.conf(revision 195484) +++ ntp.conf(working copy) @@ -13,19 +13,22 @@ # # The following three servers will give you a random set of three # NTP servers geographically close to you. -# See http://en.wikipedia.org/wiki/NTP_pool for details. +# See http://www.pool.ntp.org/ for details. Note, the pool encourages +# users with a static IP and good upstream NTP servers to add a server +# to the pool. See http://www.pool.ntp.org/join.html if you are interested. # # The option `iburst' is used for faster initial synchronisation. # The option `maxpoll 9' is used to prevent PLL/FLL flipping on FreeBSD. # -server 0.pool.ntp.org iburst maxpoll 9 -server 1.pool.ntp.org iburst maxpoll 9 -server 2.pool.ntp.org iburst maxpoll 9 +server 0.freebsd.pool.ntp.org iburst maxpoll 9 +server 1.freebsd.pool.ntp.org iburst maxpoll 9 +server 2.freebsd.pool.ntp.org iburst maxpoll 9 +#server 3.freebsd.pool.ntp.org iburst maxpoll 9 # # If you want to pick yourself which country's public NTP server # you want sync against, comment out the above servers, uncomment -# the next ones and replace CC with the country's abbrevation. +# the next ones and replace CC with the country's abbreviation. # Make sure that the hostnames resolve to a proper IP address! # # server 0.CC.pool.ntp.org iburst maxpoll 9 @@ -50,10 +53,12 @@ #restrict 127.127.1.0 # -# If we lose sync against all configured servers, the NTP clients -# syncing against this server will lose sync too. To overcome this, -# we will act as a stratum 10 server with our own internal clock -# so that everybody at least will have the same time as we have. +# If a server loses sync with all upstream servers, NTP clients +# no longer follow that server. The local clock can be configured +# to provide a time source when this happens, but it should usually +# be configured on just one server on a network. For more details see +# http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock +# The use of Orphan Mode may be preferable. # -server 127.127.1.0 -fudge 127.127.1.0 stratum 10 +#server 127.127.1.0 +#fudge 127.127.1.0 stratum 10 ___ 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" Sean -- s...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: NTP - default /etc/ntp.conf
On Fri, 5 Jun 2009, Edwin Groothuis wrote: After pondering at conf/58595, I came with this text. The ntpd is not enabled by default, so the fact that the servers are commented out should not be an issue. Any objections against adding it to the tree? I like it. I would also add restrict lines to it since ntp defaults to being open to all packets. These would ignore everything except the pools (restricted) and localhost (open): restrict default ignore restrict pool.ntp.org nomodify nopeer noquery notrap restrict pool.ntp.org nomodify nopeer noquery notrap restrict 127.0.0.1 restrict -6 ::1 Index: etc/ntp.conf === --- etc/ntp.conf(revision 0) +++ etc/ntp.conf(revision 0) @@ -0,0 +1,28 @@ +# +# $FreeBSD$ +# +# Default NTP servers for the FreeBSD operating system. +# +# Don't forget to enable ntpd in /etc/rc.conf with: +# ntpd_enable="YES" +# + +driftfile /var/db/ntpd.drift + +# +# Uncomment the following three lines to sync against three "local" +# public NTP servers. +# +# server pool.ntp.org +# server pool.ntp.org +# server pool.ntp.org + +# +# If you want to pick yourself which country's public NTP server +# you want sync against, comment out the above servers, uncomment +# the next ones and replace CC with the country's abbrevation. +# +# server CC.pool.ntp.org +# server CC.pool.ntp.org +# server CC.pool.ntp.org +# Index: etc/Makefile === --- etc/Makefile(revision 193485) +++ etc/Makefile(working copy) @@ -14,7 +14,7 @@ hosts hosts.allow hosts.equiv \ inetd.conf libalias.conf login.access login.conf mac.conf motd \ netconfig network.subr networks newsyslog.conf nsswitch.conf \ - phones profile protocols \ + ntpd.conf phones profile protocols \ ntpd.conf or ntp.conf? Sean -- s...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
On Tue, 17 Mar 2009, Sam Leffler wrote: Sean C. Farley wrote: *snip* Is the AP made by Aruba Networks? On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of wpa_supplicant for it to associate correctly. With v0.5.10, I could see DHCP requests from my laptop but no responses. This is the patch I am using currently: http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. His setup is static key wep; not wpa so I don't think wpa_supplicant is the issue. Oops. I missed that. :) Sean -- s...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: "Sean C. Farley" To: Matthias Apitz Cc: Bruce Simpson , freebsd-net@FreeBSD.org, Matthias Apitz , bug-follo...@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 11:55:32 -0500 (CDT) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --56599777-302749604-1237308518=:51892 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Tue, 17 Mar 2009, Matthias Apitz wrote: > El día Tuesday, March 17, 2009 a las 10:39:32AM +, Bruce Simpson > escribió: > >> Matthias Apitz wrote: >>> as requested the output of dmesg(1) and the ath0 related part of >>> 'pciconf -lv'; pls note also that the Wifi works fine in general, >>> i.e. with the AP in my office (WPA) and in my home (WEP); >>> >> >> Is this an ASUS Eee PC? If so, which model is it? It looks like a >> 901. > > It is an Asus EeePC 900, not the 901. > >> I tested OK with the 701. Sam said that there may be models of ath(4) >> requiring further changes to be back-ported from -CURRENT, this could >> well be one of them. > > as I said the Wifi works in all places, but not with this special AP > (while a Nokia cellphone can associate and DHCP without problems); > > let me know if you need more info; Is the AP made by Aruba Networks? On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of wpa_supplicant for it to associate correctly. With v0.5.10, I could see DHCP requests from my laptop but no responses. This is the patch I am using currently: http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. Sean -- s...@freebsd.org --56599777-302749604-1237308518=:51892-- ___ 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/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
On Tue, 17 Mar 2009, Matthias Apitz wrote: El día Tuesday, March 17, 2009 a las 10:39:32AM +, Bruce Simpson escribió: Matthias Apitz wrote: as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. It is an Asus EeePC 900, not the 901. I tested OK with the 701. Sam said that there may be models of ath(4) requiring further changes to be back-ported from -CURRENT, this could well be one of them. as I said the Wifi works in all places, but not with this special AP (while a Nokia cellphone can associate and DHCP without problems); let me know if you need more info; Is the AP made by Aruba Networks? On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of wpa_supplicant for it to associate correctly. With v0.5.10, I could see DHCP requests from my laptop but no responses. This is the patch I am using currently: http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. Sean -- s...@freebsd.org___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: tap(4) SIOCSIFMTU patch
On Fri, 13 Mar 2009, Bruce Simpson wrote: Sean C. Farley wrote: Yes, this fixes my issue with bridging a tap device to an interface with an MTU higher than 1500. I will probably commit this patch this weekend. I can't think of any reason why not, other than you might want to ensure that tap's MTU is bounded within reasonable limits, 'cause yoi don't want to exhaust the jumbo cluster pool if say mtu is more than 9000. I was letting ifhwioctl() perform the MTU limit check. It insures: IF_MINMTU <= ifr->ifr_mtu <= IF_MAXMTU I admitted to being new. See! :) Exhausting the jumbo cluster pool refers to kern.ipc.nmbjumbo[p|9|16], yes? em(4) has an upper limit of 16114 for MTU. I could limit the MTU to TAPMRU (16384) which is the limit for a write to the driver anyway. I think ifconfig already performs such a check but you might want to double check. I noticed that ifconfig can report JUMBO_MTU, but few drivers actually flag it. Should I set this for tap? Sean -- s...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: tap(4) SIOCSIFMTU patch
On Fri, 13 Mar 2009, Rui Paulo wrote: On 13 Mar 2009, at 01:54, Sean C. Farley wrote: Here is a patch[1] that will allow the MTU to be set higher than 1500 on a tap(4) interface. I ran into the need to do this when I had em0 set to 9000 and tried to bridge em0 with tap0 (MTU 1500) for QEMU. A bridge interface will not allow interfaces with different MTU's to be added to it. Since I have touched little inside the kernel, I thought it best if others take a look at it first. Sean 1. http://people.freebsd.org/~scf/if_tap-SIOCSIFMTU.patch This looks ok. I'm assuming bridge now works for you. Thank you for reviewing it. Yes, this fixes my issue with bridging a tap device to an interface with an MTU higher than 1500. I will probably commit this patch this weekend. Sean -- s...@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"
tap(4) SIOCSIFMTU patch
Here is a patch[1] that will allow the MTU to be set higher than 1500 on a tap(4) interface. I ran into the need to do this when I had em0 set to 9000 and tried to bridge em0 with tap0 (MTU 1500) for QEMU. A bridge interface will not allow interfaces with different MTU's to be added to it. Since I have touched little inside the kernel, I thought it best if others take a look at it first. Sean 1. http://people.freebsd.org/~scf/if_tap-SIOCSIFMTU.patch -- s...@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"
Problems with first device on bridge
On a 7-STABLE (built August 7th), I have noticed messages appearing in /var/log/messages: Aug 7 15:07:17 thor kernel: rtfree: 0xc7143a2c has 2 refs Aug 7 15:07:19 thor last message repeated 2 times Aug 7 15:09:28 thor last message repeated 3 times Aug 7 15:11:54 thor last message repeated 9 times This happens if I set up a bridge to have em0 and tap0 such as from: ifconfig bridge0 create ifconfig bridge0 addm em0 ifconfig bridge0 addm tap0 When I start QEMU on tap0, I would immediately lose IPv6 on em0 and eventually IPv4 would go away. I would get a lot more of messages about rtfree with QEMU started. From experimentation (and some luck), I found that if I reversed the devices on a newly created bridge then the rtfree messages would go away, but I would have problems with tap0. The workaround: create two tap devices tap0 and tap1 and add to bridge0 in the order of tap1, tap0 and em0. On another system, I noticed that a bridge between real NIC's (em1 and sk0) also reports an rtfree message during boot. Any ideas? Sean -- [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /etc/exports and IPv6 networks
On Thu, 20 Mar 2008, Doug Barton wrote: Sean C. Farley wrote: On Thu, 20 Mar 2008, Doug Barton wrote: Folks, I spent a fair amount of time today reading through the man pages and source code and could not find any way of specifying an IPv6 network in /etc/exports as you can with v4 and -network/-netmask. Am I missing something? If not, is this an update that is on someone's list somewhere? Something like this has worked for me: /usr -maproot=root -network :::::: -mask ::0 I confess that's one combination I didn't think to try, and it did work, thanks! Care to add that to the man page? You are welcome. I forgot how I found how to do, but it did take a good deal of searching before I found it. Yes, I will write an addition to the man page in a couple of days. That way I will not lose it. :) One thing I have run into was that an install of a kernel over NFS using IPv6 can stall the mount. I have not had time to look into it, so I do not know what exactly triggers it (number of bytes or files?). It has always been while copying a kernel module. Wacky. Is this still true after the recent (before the 7.0 branch) work to make v6 stuff "work the same way as" v4 stuff? As of March 14th, RELENG_7 still exhibited it for me. Sean -- [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /etc/exports and IPv6 networks
On Thu, 20 Mar 2008, Doug Barton wrote: Folks, I spent a fair amount of time today reading through the man pages and source code and could not find any way of specifying an IPv6 network in /etc/exports as you can with v4 and -network/-netmask. Am I missing something? If not, is this an update that is on someone's list somewhere? Something like this has worked for me: /usr -maproot=root -network :::::: -mask ::0 One thing I have run into was that an install of a kernel over NFS using IPv6 can stall the mount. I have not had time to look into it, so I do not know what exactly triggers it (number of bytes or files?). It has always been while copying a kernel module. Sean -- [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Frequent pauses with Linux-based router
On Tue, 18 Mar 2008, David DeSimone wrote: Sean C. Farley <[EMAIL PROTECTED]> wrote: An ICMP test showed that there were occasional pauses and packet loss. The fix: use 100Mb instead of 10Mb. :) For some reason I do not recall, I had forced the interface connected to the DSL router to 10Mb. When I noticed XP did not have the same problem and that it had a 100Mb connection to the router, I found and removed the "media 10baseT/UTP mediaopt full-duplex" from /etc/rc.conf for the interface. That appears to have fixed it. The fix here is not that you moved to 100 Mb, it's that you stopped forcing duplex, and allow auto-negotiation to take place. With the forced duplex in effect, your NIC does not auto-negotiate with the other end (the router), and it falls back to half duplex, which leads to large numbers of collision errors. Ah! I tried it again at 10Mb without setting it to full-duplex, and it worked. Out of curiosity, is it normal that 100Mb will default to full-duplex yet 10Mb will not, or is it dependent on the hardware? The pause always seemed to be for packets from the router to the computer. Yep, whenever the router would try to send, if your end happened to be sending a frame, the router's NIC would stop to avoid the collision, leading to packet loss. This is a classic duplex-mismatch scenario. My wife was getting tired of hearing the thump of my head on the wall. Maybe one more to make sure I remember this next time. :) Thank you for the explanation. Sean -- [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Frequent pauses with Linux-based router
On Mon, 17 Mar 2008, Bruce M. Simpson wrote: Sean C. Farley wrote: I have noticed that with a Linux-based Netgear DG834G (DSL modem) frequent pauses (example[1]) between external systems and 7-STABLE (March 14th). At first, I thought it was ipfilter or ipnat, but I took those out of the picture by activating telnet on the router and connecting directly to it. Even running "ls /usr/sbin" on the router would pause occasionally. I did not (or did not recall) have these problems with 6-STABLE (post 6.2). I switched out the NIC (FA-311 (sis) to a FA-310 (dc)), cable and tried different ports on the modem by which to connect. I also tried disabling all RFC sysctl's and SACK. Nothing helped. Finally, I brought out an old DSL modem (SpeedStream 5660). This fixed the issue. I think this maybe a specific issue between Linux (2.4.17_mvl21-malta-mips_fp_le) and FreeBSD 7. Is there anything else I may test to see what is happening? OT: Hang on, are you saying you're running a MIPS MALTA targeted Linux kernel on a Netgear DG834G? That would be interesting as a test platform for FreeBSD/mips, considering the platform support for Malta is already there. I had a go at doing the Broadcom Sentry5 SoC last year but hadn't finished anything. Here is a bit of information about it from /proc: # cat cpuinfo processor : 0 cpu model : MIPS 4KEc V4.8 BogoMIPS: 211.35 wait instruction: no microsecond timers : yes extra interrupt vector : yes hardware watchpoint : yes VCED exceptions : not available VCEI exceptions : not available # cat meminfo total:used:free: shared: buffers: cached: Mem: 14712832 9666560 50462720 1130496 3694592 Swap:000 If I was not using it for my main DSL router, I would consider putting FreeBSD on it. After the frustration I had with it, I did seriously wonder about FreeBSD on it. It would be especially tempting if it would still function as a DSL router along with the web interface. :) It has wireless, but I have that disabled. If you are interested in more specs, I can cat /proc for you. Long shot, but are 802.3 pause frames appearing anywhere, ie can you test with a crossover cable? Have you done a BER test with UDP or something like that to try to rule out non-TCP protocols? Well, with help on IRC from Robert Watson and others, I was able to "fix" it. An ICMP test showed that there were occasional pauses and packet loss. The fix: use 100Mb instead of 10Mb. :) For some reason I do not recall, I had forced the interface connected to the DSL router to 10Mb. When I noticed XP did not have the same problem and that it had a 100Mb connection to the router, I found and removed the "media 10baseT/UTP mediaopt full-duplex" from /etc/rc.conf for the interface. That appears to have fixed it. I have never heard of pause frames. Interesting. Also, I do not recall seeing anything unusual with tcpdump (using "host dsl" expression I think). The pause always seemed to be for packets from the router to the computer. Sean -- [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Frequent pauses with Linux-based router
I have noticed that with a Linux-based Netgear DG834G (DSL modem) frequent pauses (example[1]) between external systems and 7-STABLE (March 14th). At first, I thought it was ipfilter or ipnat, but I took those out of the picture by activating telnet on the router and connecting directly to it. Even running "ls /usr/sbin" on the router would pause occasionally. I did not (or did not recall) have these problems with 6-STABLE (post 6.2). I switched out the NIC (FA-311 (sis) to a FA-310 (dc)), cable and tried different ports on the modem by which to connect. I also tried disabling all RFC sysctl's and SACK. Nothing helped. Finally, I brought out an old DSL modem (SpeedStream 5660). This fixed the issue. I think this maybe a specific issue between Linux (2.4.17_mvl21-malta-mips_fp_le) and FreeBSD 7. Is there anything else I may test to see what is happening? Sean 1. http://www.farley.org/freebsd/tmp/DSL/dsl-dmp.txt (telnet session between gateway and DSL modem) -- [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121274: [panic] Panic in ether_input() with different NIC's.
The following reply was made to PR kern/121274; it has been noted by GNATS. From: "Sean C. Farley" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: kern/121274: [panic] Panic in ether_input() with different NIC's. Date: Tue, 4 Mar 2008 13:15:49 -0600 (CST) Two additional items of interest, but I do not know for certain if this is related to the panic I am seeing: 1. I have recently found that running "ipnat -s" will cause a panic regardless of how long the system has been running. 2. Here is the LOR along with a backtrace from running "ipnat -s". More information can be found here: http://www.farley.org/freebsd/tmp/panic/dmesg.boot IP Filter: v4.1.28 initialized. Default = pass all, Logging = enabled Kernel page fault with the following non-sleepable locks held: shared rw ipf filter load/unload mutex r = 0 (0xc52088a0) locked @ /usr/FreeBSD/RELENG_7/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil_freebsd.c:350 KDB: enter: witness_warn Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x28202000 fault code = supervisor write, page not present instruction pointer= 0x20:0xc0777556 stack pointer = 0x28:0xdf59cde4 frame pointer = 0x28:0xdf59dbb4 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process= 62 (ipnat) lock order reversal: (sleepable after non-sleepable) 1st 0xc52088a0 ipf filter load/unload mutex (ipf filter load/unload mutex) @ /usr/FreeBSD/RELENG_7/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil_freebsd.c:350 2nd 0xc4f0b12c user map (user map) @ /usr/FreeBSD/RELENG_7/src/sys/vm/vm_map.c:3111 KDB: stack backtrace: db_trace_self_wrapper(c07ba661,df59cb00,c059895e,c07bcc04,c4f0b12c,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07bcc04,c4f0b12c,c07d5a0c,c07d5a0c,c07d5990,...) at kdb_backtrace+0x29 witness_checkorder(c4f0b12c,9,c07d5990,c27,c0461b23,...) at witness_checkorder+0x6de _sx_xlock(c4f0b12c,0,c07d5990,c27,df59cb68,...) at _sx_xlock+0x7d _vm_map_lock_read(c4f0b0e8,c07d5990,c27,0,0,...) at _vm_map_lock_read+0x50 vm_map_lookup(df59cc60,28202000,2,df59cc64,df59cc54,...) at vm_map_lookup+0x38 vm_fault(c4f0b0e8,28202000,2,8,28202000,...) at vm_fault+0x83 trap_pfault(5,0,c07df7db,0,c,...) at trap_pfault+0xf9 trap(df59cda4) at trap+0x3f2 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0777556, esp = 0xdf59cde4, ebp = 0xdf59dbb4 --- generic_copyout(c51a1480,c034725d,1,0,c5020880,...) at generic_copyout+0x36 iplioctl(c5191a00,c034725d,c51a1480,1,c5020880,...) at iplioctl+0xca devfs_ioctl_f(c51b0120,c034725d,c51a1480,c524f000,c5020880,...) at devfs_ioctl_f+0xc9 kern_ioctl(c5020880,3,c034725d,c51a1480,100,...) at kern_ioctl+0x243 ioctl(c5020880,df59dcfc,c,c07b487b,c07f8bb0,...) at ioctl+0x134 syscall(df59dd38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28166363, esp = 0xbfbfeccc, ebp = 0xbfbfed38 --- KDB: enter: witness_checkorder Kernel page fault with the following non-sleepable locks held: shared rw ipf filter load/unload mutex r = 0 (0xc52088a0) locked @ /usr/FreeBSD/RELENG_7/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil_freebsd.c:350 KDB: enter: witness_warn Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x28203000 fault code = supervisor write, page not present instruction pointer= 0x20:0xc0777556 stack pointer = 0x28:0xdf59cde4 frame pointer = 0x28:0xdf59dbb4 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process= 62 (ipnat) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121274: [panic] Panic in ether_input() with different NIC's.
On Sun, 2 Mar 2008, [EMAIL PROTECTED] wrote: Could you run memtest86 or some other memory testing tool on the box? While this could well be a software bug, it would be nice to give it a whirl and make sure you're not running into, say, a 1-bit memory error that might easily explain the panic across various drivers. Thanks! It passed memtest86+ v2.01 scrutiny. Sean -- [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dhclient multiple aliases limitation
I currently have a setup on a laptop where I have two aliases that I always want present. I would like to setup two aliases in /etc/dhclient.conf to handle having the Ethernet cable plugged in after boot, but dhclient has a limit of handling only one alias. /etc/rc.conf ifconfig_xl0="DHCP" ifconfig_xl0_alias0="inet 192.168.1.46 netmask 255.255.255.255" ifconfig_xl0_alias1="inet 192.168.6.46 netmask 255.255.255.0" The first address uses an alias-type netmask while the second is a private network I have for QEMU. I found that during PREINIT /sbin/dhclient-script is deleting the 192.168.1.46 address when it runs this: ifconfig $interface inet 0.0.0.0 netmask 0.0.0.0 broadcast 255.255.255.255 up A possible solution that works for me is to add an "alias" to this line. It appears to work, but I do not know if this would cause problems elsewhere or for other scenarios. Does anyone see any problems with this change? Sean P.S. Please Cc me since I am not on this list. -- [EMAIL PROTECTED]--- /sbin/dhclient-script 2006-05-12 22:24:00.0 -0500 +++ /etc/dhclient-script2007-08-28 15:25:30.0 -0500 @@ -223,7 +223,7 @@ PREINIT) delete_old_alias - ifconfig $interface inet 0.0.0.0 netmask 0.0.0.0 broadcast 255.255.255.255 up + ifconfig $interface inet 0.0.0.0 netmask 0.0.0.0 broadcast 255.255.255.255 alias up ;; ARPCHECK|ARPSEND) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
