Re: [ HEADS UP ] Ports unstable for the next 10 days
On Tue, 13 Apr 2010 16:03:22 -0700 Ted Faber wrote: > On Sun, Mar 28, 2010 at 04:38:28PM +0300, Ion-Mihai Tetcu wrote: > > Hi, > > > > > > As announced before, a few big commits, that touch some thousands > > ports are being done: png, curl, x11, gnome, kde4. The target ETA > > is 6-7 April. > > I didn't see any mial, but figured I'd check. Are ports still > unstable? ATM no, as it's apparent from the message bellow. Update to that message: - Gnome and KDE are ready - Xorg is believed to be ready, an -exp run on pointy is beginning today. On Thu, 8 Apr 2010 13:23:08 -0700 Charlie Kester wrote: > On Sun 28 Mar 2010 at 06:38:28 PDT Ion-Mihai Tetcu wrote: > >Hi, > > > > > >As announced before, a few big commits, that touch some thousands > >ports are being done: png, curl, x11, gnome, kde4. The target ETA is > >6-7 April. > > > >The first one was done, update of graphics/png (including a shared > >lib version bump), with about 5000 ports affected. > > > >We do _NOT_ recommend updating ports until this commits are all done, > >and the problems are fixed, except if you want to help testing / > >fixing. > > > >Before reporting failures, please take a look at ports@ list, and > >http://qat.tecnik93.com/index.php?action=failed_buildports&sort=last_built > >to find out if the problem hasn't already been reported or even > >fixed. We also have two incremental builds on Pointy to catch the > >problems. > > > > > >Thank you, > > > >With hat:portmgr@ > > > Sorry if this seems like nagging, but since we're now past the > original ETA can we get a current status report? Is the portstree > considered stable again, and if not, what's the revised ETA? From: Ion-Mihai Tetcu To: Ion-Mihai Tetcu Cc: sta...@freebsd.org, questi...@freebsd.org, freebsd-po...@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days Date: Mon, 5 Apr 2010 21:31:33 +0300 Just a status update: PNG and cURL are in, and png fall-outs are believed to be fixed. Xorg update has gone through an -exp run on Pointy and our xorg team is working on fixing the approx. 60 ports with problems. still work to do I will begin -exp runs for Gnome and KDE updates tonight or tomorrow morning. >>> Gnome -exp done, there's a showstopper on amd64 that we weren't aware >>> of. about 40 fixesso far. An other -exp needed. KDE in progress. Packages status: - i386: - 6 after png and curl - 7 after png and curl - an 8 incremental build is in progress and should be shortly finished finished - 9 pacakges are from middle March >>> from 9 Apr. - amd64: - 6 packages are post png and curl - 7 build is in progress and will be finished tomorrow - 8 last build was done in the middle of the png update/fixes; we won't run an other before Xorg, KDE and Gnome go in (for lack of resources). >>> in progress, with ports from yesterday - 9 build in progress (with sources that are believed to fix the zlib problem). nope, still old packages. In other words, if you wish to update without waiting for Xorg, Gnome and KDE now it's a good moment. >>> So no clear ETA yet, a few days more. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: Strange Swapping Issues(?)
On Wed, Apr 14, 2010 at 06:44:58AM +0200, Gabor PALI wrote: > Hello there, > > I am running a FreeBSD/amd64 8-STABLE with GENERIC kernel as of > February 17 on my box (quad core, 2 GB RAM), and recently I spot some > interesting problems in my logs. My machine runs two instances of a > client in two separate chroot environments in parallel with 32-bit and > 64-bit userlands respectively, doing a nightly building and testing. > According to the logs it puts a nice load on my system, though it > still seems to be working fine. > > Except one thing: it produces strange error messages on swap space > without an apparent reason (at least to me): > > xxx# tail -f /var/log/messages > Apr 14 05:26:44 xxx kernel: swap_pager_getswapspace(4): failed > Apr 14 05:26:44 xxx kernel: swap_pager_getswapspace(16): failed > Apr 14 05:26:44 xxx kernel: > Apr 14 05:26:44 xxx kernel: swap_pager_getswapspace(3): failed > Apr 14 05:26:44 xxx kernel: swap_pager_getswapspace(16): failed > Apr 14 05:26:44 xxx kernel: swap_pager_getswapspace(3): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(12): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(2): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed > Apr 14 05:26:45 xxx kernel: pid 7388 (throwto003), uid 1001, was > killed: out of swap space > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(8): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(8): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(12): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(9): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(9): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(3): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(9): failed > Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(3): failed > ^C > xxx# swapinfo -h > Device 1K-blocks UsedAvail Capacity > /dev/ad0s1b 4194304 112M 3.9G 3% The swapinfo command you ran was not run at 05:26 in the morning. You should probably set up a small script, run via cronjob, that logs swapinfo -h output to a file somewhere (rotate it if you want via newsyslog.conf). You may have something running on the system that spirals out of control, such as a web board script being pounded to death, or something that's forking excessively. I'd also recommend having the script output "top -b -o res 100", which will give you the top 100 processes on the machine sorted by RSS (non-shared) memory usage. I don't know of a way to show "the amount of swap used by process N, or all processes", since it's transparently handled by the VM. So I'm making the assumption RSS will be large. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Strange Swapping Issues(?)
Hello there, I am running a FreeBSD/amd64 8-STABLE with GENERIC kernel as of February 17 on my box (quad core, 2 GB RAM), and recently I spot some interesting problems in my logs. My machine runs two instances of a client in two separate chroot environments in parallel with 32-bit and 64-bit userlands respectively, doing a nightly building and testing. According to the logs it puts a nice load on my system, though it still seems to be working fine. Except one thing: it produces strange error messages on swap space without an apparent reason (at least to me): xxx# tail -f /var/log/messages Apr 14 05:26:44 xxx kernel: swap_pager_getswapspace(4): failed Apr 14 05:26:44 xxx kernel: swap_pager_getswapspace(16): failed Apr 14 05:26:44 xxx kernel: Apr 14 05:26:44 xxx kernel: swap_pager_getswapspace(3): failed Apr 14 05:26:44 xxx kernel: swap_pager_getswapspace(16): failed Apr 14 05:26:44 xxx kernel: swap_pager_getswapspace(3): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(12): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(2): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed Apr 14 05:26:45 xxx kernel: pid 7388 (throwto003), uid 1001, was killed: out of swap space Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(8): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(8): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(12): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(9): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(9): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(3): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(16): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(9): failed Apr 14 05:26:45 xxx kernel: swap_pager_getswapspace(3): failed ^C xxx# swapinfo -h Device 1K-blocks UsedAvail Capacity /dev/ad0s1b 4194304 112M 3.9G 3% Do you have any ideas what might have happened? Do I need to update or configure something? Thank you very much for your replies in advance. Cheers, :g ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Freeze on my laptop.
On Wed, Apr 14, 2010 at 09:43:22AM +1000, Andrew Snow wrote: > Demelier David wrote: > > I'm so sad because FreeBSD is the one which can runs almost perfectly on > > my laptop. But it freezes. Sometime I just do anything and I want to > > click on a link in firefox, or open a terminal and then freeze. > > Sounds like a problem with the X graphics driver.. when it next > happens, can you press Alt+F1 or Ctrl+Alt+F1 to get back to a text console? > > You might like to try upgrading your version of X to a newer version. > > - Andrew I'll try with vesa, maybe you right but with last(1) command I get many `crash'. And I can't go back in console. The odd thing is that happens often when I use gtk based applications (pidgin, firefox). -- Demelier David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Freeze on my laptop.
Demelier David wrote: I'm so sad because FreeBSD is the one which can runs almost perfectly on my laptop. But it freezes. Sometime I just do anything and I want to click on a link in firefox, or open a terminal and then freeze. Sounds like a problem with the X graphics driver.. when it next happens, can you press Alt+F1 or Ctrl+Alt+F1 to get back to a text console? You might like to try upgrading your version of X to a newer version. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [ HEADS UP ] Ports unstable for the next 10 days
On Sun, Mar 28, 2010 at 04:38:28PM +0300, Ion-Mihai Tetcu wrote: > Hi, > > > As announced before, a few big commits, that touch some thousands ports > are being done: png, curl, x11, gnome, kde4. The target ETA is 6-7 > April. I didn't see any mial, but figured I'd check. Are ports still unstable? -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpWwPAicZasS.pgp Description: PGP signature
How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
Hi all, thanks for showing interest in this issue. I uploaded my test code so that you can test on your PC. Following is the instruction. 1. download my source codes. http://people.freebsd.org/~maho/dgemm/Makefile http://people.freebsd.org/~maho/dgemm/dgemm.cpp check md5. % md5 Makefile dgemm.cpp MD5 (Makefile) = b408ab1e1f5bf8b923cae5ec9f9f0f07 MD5 (dgemm.cpp) = 0d774a456a665429c67c2b07fd24c64c 2. install ports/math/gotoblas (manual download required) make install 3. compile dgemm.cpp just type make % make g++44 -pthread -static -O2 -o dgemm dgemm.cpp -L/usr/local/lib -lgoto2p g++44 -pthread -static -O2 -o dgemm_ref dgemm.cpp -L/usr/local/lib -lblas -lgfortran 4. run dgemm. % ./dgemm n: 3000 time : 134.648208 or 16.910525 Mflops : 31943.419695 n: 3100 time : 148.122279 or 18.615284 Mflops : 32017.357408 n: 3200 time : 162.45 or 20.430651 Mflops : 32087.318295 n: 3300 time : 178.497079 or 22.446093 Mflops : 32030.420499 n: 3400 time : 195.550715 or 24.586152 Mflops : 31981.873273 n: 3500 time : 213.403379 or 26.825058 Mflops : 31975.513363 n: 3600 ... above output is on Core i7 920 (2.66GHz; TurboBoost on) Thanks -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/ Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Freeze on my laptop.
Hi, I'm so sad because FreeBSD is the one which can runs almost perfectly on my laptop. But it freezes. Sometime I just do anything and I want to click on a link in firefox, or open a terminal and then freeze. There is no messages, no reboot nothing. Can't know where that come from. I'm running 8.0-STABLE on a hp probook 4510s. King regards, -- Demelier David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
on 13/04/2010 02:33 Maho NAKATA said the following: > From: Andriy Gapon >> Another question is what compilers (what versions of GCC) were used on both >> system to compile the program? > > Hi > > on Ubuntu $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured > with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' > --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs > --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared > --enable-multiarch --enable-linker-build-id --with-system-zlib > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix > --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 > --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc > --disable-werror --with-arch-32=i486 --with-tune=generic > --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu > --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.1 (Ubuntu > 4.4.1-4ubuntu9) > > on FreeBSD % gcc44 -v Using built-in specs. Target: x86_64-portbld-freebsd8.0 > Configured with: ./../gcc-4.4-20100330/configure --disable-nls > --libdir=/usr/local/lib/gcc44 --libexecdir=/usr/local/libexec/gcc44 > --program-suffix=44 --with-as=/usr/local/bin/as --with-gmp=/usr/local > --with-gxx-include-dir=/usr/local/lib/gcc44/include/c++/ > --with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local > --with-system-zlib --disable-libgcj --prefix=/usr/local > --mandir=/usr/local/man --infodir=/usr/local/info/gcc44 > --build=x86_64-portbld-freebsd8.0 Thread model: posix gcc version 4.4.4 > 20100330 (prerelease) (GCC) Is this what was used to compile the code in hot path (the code that performs all the actual calculations)? The answer is not obvious. GCC 4.4 is known to produce better code for modern CPUs, partially because it has knowledge of recently introduced instructions. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CPU problems after 8.0-STABLE update
on 10/04/2010 07:21 Akephalos said the following: > On Thu, 08 Apr 2010 18:03:08 +0300 Andriy Gapon wrote: > >> Really shooting in the dark here: are there any BIOS options about HPET and >> RTC on this system? Can you try playing with them? >> >> -- Andriy Gapon > > I'm sorry for this late reply. I can't see any option like that in bios, > unfortunately, there are few options that can be changed. In case it was > forgotten, on the firs install (8.0 release version) it was all fine, I think > diffing or tracing the changes from there might point to a solution? That's pretty obvious: RTC was not used for stat clock in that version; later version did try to use RTC and now Attilio has reverted the logic back to not use RTC unless explicitly requested. What is not obvious is why your RTC doesn't work as expected. I have no answer to that. One thing that makes me suspicious is that HPET also doesn't seem to work on your system. One very very wild guess is that IRQ8 might be actually driven by HPET, not RTC. And our programming of HPET or RTC or both messes things up. It would be interesting to see if disabling HPET (acpi_hpet) changes anything: debug.acpi.disabled="hpet" -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pf stalls connection when using route-to
On Tue, Apr 13, 2010 at 11:19 PM, Jeremy Chadwick wrote: > > What FreeBSD version? uname -a output please. > I have tried 7.2-R and 8.0-R. Both version stalls, too. 8.0-RELEASE: # uname -a FreeBSD bsd8 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #3: Wed Mar 3 17:15:52 CST 2010 r...@bsd8:/usr/obj/usr/src/sys/KERNEL amd64 We only added "carp" in kernel config for HA. # cat /etc/sysctl.conf # $FreeBSD: src/etc/sysctl.conf,v 1.8.34.1.2.1 2009/10/25 01:10:29 kensmith Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 debug.bootverbose=1 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 kern.maxprocperuid=65536 net.inet.tcp.delayed_ack=0 debug.bootverbose=1 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 kern.maxprocperuid=65536 net.inet.tcp.delayed_ack=0 net.inet.carp.preempt=1 net.inet.carp.arpbalance=1 kern.randompid=9 net.inet.flowtable.enable=0 # cat /boot/loader.conf # coretemp_load="YES" geom_mirror_load="YES" geom_stripe_load="YES" if_em_load="YES" kbdmux_load="YES" random_load="YES" ukdb_load="YES" zfs_load="YES" # kern.ipc.nmbclusters="0" kern.maxproc="65536" net.inet.tcp.reass.maxsegments="1600" 7.2-RELEASE: # uname -a FreeBSD bsd7 7.2-RELEASE-p7 FreeBSD 7.2-RELEASE-p7 #0: Fri Feb 26 22:28:05 UTC 2010 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # cat /etc/sysctl.conf debug.bootverbose=1 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=32768 kern.maxfiles=65536 kern.maxfilesperproc=32768 kern.maxprocperuid=65536 kern.randompid=9 net.inet.icmp.icmplim=65536 net.inet.ip.fastforwarding=1 net.inet.ip.portrange.first=4096 net.inet.tcp.delayed_ack=0 net.inet.tcp.fast_finwait2_recycle=1 net.inet.tcp.maxtcptw=65535 net.inet.tcp.msl=1500 net.inet.tcp.nolocaltimewait=1 vfs.lookup_shared=1 vfs.nfs.prime_access_cache=0 vm.pmap.shpgperproc=2000 # cat /boot/loader.conf # coretemp_load="YES" geom_mirror_load="YES" geom_stripe_load="YES" kbdmux_load="YES" random_load="YES" ukdb_load="YES" zfs_load="YES" # kern.ipc.nmbclusters="0" kern.maxproc="65536" vfs.zfs.prefetch_disable="1" vm.kmem_size="1G" vm.kmem_size_max="1G" net.inet.tcp.reass.maxsegments="1600" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pf stalls connection when using route-to
On Tue, Apr 13, 2010 at 08:17:57PM +0800, Lin Jui-Nan Eric wrote:
> We recently found that when the traffic passes pf with route-to, the
> connection stalls.
> Turning off TSO solves the problem. Our pf.conf is very simple:
>
> table const {10/8, 172.16/12, 192.168/16}
> pass out quick route-to (em0 10.1.1.1) from to ! no state
>
> And we have a tcpdump capture file. It shows that there's lots of
> duplicate packets and
> retransmissions while TSO is enabled. Our NIC is an Intel PRO/1000:
>
> em0: port 0x2000-0x201f
> mem 0xdf20-0xdf21 irq 18 at device 0.0 on pci4
> em0: Using MSI interrupt
> em0: [FILTER]
>
> Screenshot: http://cf.files.jnlin.org/with-tso.png
>
> Any suggestion? I just turn off the TSO, but I think it is only a workaround.
What FreeBSD version? uname -a output please.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
8-STABLE/amd64: r206088 breaks compilation
Hi, The error is: 8_stable-build/usr.bin/netstat/netgraph.c: In function 'netgraphprotopr': 8_stable-build/usr.bin/netstat/netgraph.c:174: error: 'struct ngsock' has no member named 'node_id' 8_stable-build/usr.bin/netstat/netgraph.c:176:error: 'struct ngsock' has no member named 'node_id' I think the problem is here: revision 206087 revision 206088 snprintf(path, sizeof(path), "[%lx]:", (u_long)info.node);snprintf(path, sizeof(path), "[%x]:", info.node_id); Can anyone confirm? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
pf stalls connection when using route-to
Hi listers,
We recently found that when the traffic passes pf with route-to, the
connection stalls.
Turning off TSO solves the problem. Our pf.conf is very simple:
table const {10/8, 172.16/12, 192.168/16}
pass out quick route-to (em0 10.1.1.1) from to ! no state
And we have a tcpdump capture file. It shows that there's lots of
duplicate packets and
retransmissions while TSO is enabled. Our NIC is an Intel PRO/1000:
em0: port 0x2000-0x201f
mem 0xdf20-0xdf21 irq 18 at device 0.0 on pci4
em0: Using MSI interrupt
em0: [FILTER]
Screenshot: http://cf.files.jnlin.org/with-tso.png
Any suggestion? I just turn off the TSO, but I think it is only a workaround.
Sincerely,
Jui-Nan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
