[Bug 219672] vmxnet3: with LRO enabled under FreeBSD 11 as a router, outgoing speed of forwarded traffic becomes slower
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219672 Bug ID: 219672 Summary: vmxnet3: with LRO enabled under FreeBSD 11 as a router, outgoing speed of forwarded traffic becomes slower Product: Base System Version: 11.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: jwo...@vmware.com The following vmxnet3 driver performance issue was report to open-vm-tools in https://github.com/vmware/open-vm-tools/issues/166 Since vmxnet3 is the community based driver on FreeBSD, the issue is being cross-filed with FreeBSD. This bug number will be forwarded to the reporter who will be encouraged to provided needed information to this problem report. = Thank you for the excellent open-vm-tools package! With Large Receive Offload (LRO) enabled under FreeBSD 11 virtual machine as a router, outgoing speed of forwarded traffic becomes 500 times slower with VMXNET3 on HP Proliant G8/G9 (Broadcom BCM5719 enthernet controller chipset)!! We are using it with pfSense (under FreeBSD 11) virtual appliances (virtual machine) under VMWare ESXi hosts on HP Proliant G8/G9 servers, all virtual machines have 1-2 VMXNET3 adapters. We have tried pfSense version from 2.3.0-RELEASE to 2.4.0-BETA (built on Fri May 26 19:15:04 CDT 2017), Open-VM-Tools package 10.1.0,1, FreeBSD 11.0-RELEASE-p10. We have tried VMWare ESXi version from 6.0 to 6.5.0 with all Hewlett-Packard drivers (highest version of ESXi that we’ve used is HPE Customized Image ESXi 6.5.0 version 650.9.6.5.27 released on May 2017 and based on ESXi 6.5.0 Vmkernel Release Build 5146846). Regardless of the pfSense version or the VMWare version, on FreeBSD 11.0-RELEASE-p10, if I un-check an option in pfSense to “Disable hardware large receive offload” (to enable hardware large receive offload) – the virtual machines that are routed via pfSense (FreeBSD) have very low upload speed (about 1/500th of their normal speed) or drop connections. To get their speed back to normal, I have to check this option ON. Other hardware offload options do not have problems – i have them unchecked to enable hardware offload of checksums and TCP segmentation. The Broadcom BCM5719 chipset, that supports Large Receive Offload (LRO) is quite cheap and ubiquitous, released in 2013. VMWare has added support of hardware LRO to VMXNET3 also in 2013. In Windows, LRO is supported since Windows Server 2012 and Windows 8 (since 2012). FreeBSD supports it from version 8 (since 2009). There is Open-VM-Tools 10.1.5 version already available at https://github.com/vmware/open-vm-tools/ , maybe it fixes the issue with Large Receive Offload (LRO) under FreeBSD with VMXNET3? I saw some forum messages where people discourage using VMXNET3 adapter, in favour of E1000 adapter, quote from https://forum.pfsense.org/index.php?topic=98309.0 : „We saw much better performance from the E1000 than VMXnet2 and 3”. There is a VMWare blog on the benefits of LRO for Linux and Windows – see https://blogs.vmware.com/performance/2015/06/vmxnet3-lro.html According to this blog entry, LRO saves valuable CPU cycles, and is also very beneficial in VM-VM local traffic where VMs are located in the same host, communicating with each other through a virtual switch. I suspect that the problem is somewhere in the open-vm-tools-nox11 package - may it includes not fully compatible or not fully stable VMWare drivers for VMXNET3 -- because Windows machines from our servers connected to Internet either directly or via pfSense have LRO enabled and don’t have performance degradation. There is definitely an incompatibility issues in open-vm-tools on VMXNET3 under FreeBSD with Large Receive Offload (LRO)! Other hadware TCP offload are working properlly, because VMXNET3 under Windows makes LRO correctly! -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219606] aarch64: libarchive.so.6 not present, libarchive.so not equivalent @ 318898
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219606 --- Comment #9 from Mark Millard --- (In reply to Ed Maste from comment #8) > [Ed's description of shared library version handling] Yep, that is expected. I've tried to remember how or when I ran into a generic reference to a: /usr/lib/lib.so or: /lib/lib.so or some such being used to find a library when it was a symbolic link but I've not managed to remember anything. It was not recently --and not even necessarily under FreeBSD since I'm remembering so little. I just end up with a "careful of assumptions" reaction from some past problem that I ran into. All I can say that that I'm pretty sure I've run into the issue where something actually used a generic .so link directly and found and used directly what it pointed to instead of an original binding. (May be it was a fail-over for the original binding not being available to find any more?) This can be translated to: if things still seem to not be working as expected, see if you can check if the link is in direct use from a context where that would not work. A "yes" to that would mean another problem is involved someplace. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219606] aarch64: libarchive.so.6 not present, libarchive.so not equivalent @ 318898
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219606 --- Comment #8 from Ed Maste --- > Anything looking up just /usr/lib/libarchive.so > would see a link taking that context to > libarchive.so.7 despite an older libarchive.so.6 > being available for older code. Yes, but this is the way shared library versioning works. When you build something you link against e.g. /usr/lib/libarchive.so. The linker follows the symlink to libarchive.so.6, and then the key point is that it stores libarchive.so.6 as the dependency. So that binary will always use libarchive.so.6. When you update and libarchive.so is now a symlink to libarchive.so.7, and build some software, it follows the symlink and stores libarchive.so.7 as the dependency. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219606] aarch64: libarchive.so.6 not present, libarchive.so not equivalent @ 318898
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219606 --- Comment #7 from Mark Millard --- (In reply to Ed Maste from comment #6) Good to know. Thanks. One worry was that if something updated the old: /usr/lib/libarchive.so -> libarchive.so.6 to: /usr/lib/libarchive.so -> libarchive.so.7 (say because of the upgraded system) that the libarchive.so.6 might not always be found by older code: Anything looking up just /usr/lib/libarchive.so would see a link taking that context to libarchive.so.7 despite an older libarchive.so.6 being available for older code. >From what I've read if that happened in the wrong context it could be a disaster. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 211516] lldb: single stepping does not work on arm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211516 --- Comment #2 from Ed Maste --- Single stepping reported working in LLDB built from SVN, post 4.0.1 https://lists.freebsd.org/pipermail/freebsd-arm/2017-May/016260.html. This will presumably be fixed when 5.0.0 is merged. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219606] aarch64: libarchive.so.6 not present, libarchive.so not equivalent @ 318898
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219606 --- Comment #6 from Ed Maste --- > But when I look at the > Pine64+ 2GB I see a /usr/lib/libarchive.so.6 Correct, /usr/lib/libarchive.so.6 will exist on systems originally built from pre-ino64 sources. After ino64 libarchive is installed as /usr/lib/libarchive.so.7. The old one will continue to exist until "make delete-old-libs" is run. You should be able to use existing packages with the existing libraries. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219525] Multiple bugs in mpr ioctl handler
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219525 --- Comment #5 from CTurt --- That's correct, using the `min` macro will correct that issue. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219525] Multiple bugs in mpr ioctl handler
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219525 --- Comment #4 from Stephen McConnell --- And there's no reason to look at 'status' in the 'if' actually, so just: if (copyout((void *)sc->recorded_events, PTRIN(data->PtrEvents), min(size, sizeof(sc->recorded_events))) != 0) status = EFAULT; -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219525] Multiple bugs in mpr ioctl handler
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219525
--- Comment #3 from Stephen McConnell ---
OK. I see what you're saying. The check makes sure that data is not copied to
invalid space, but it does not check if the bytes are valid. That's true.
Maybe it's better like this:
if (status == 0) {
if (copyout((void *)sc->recorded_events, PTRIN(data->PtrEvents),
min(size, sizeof(sc->recorded_events))) != 0)
status = EFAULT;
}
Then, it just copies out as many valid bytes as it can, and no 'else' part.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219646] "ls: fts_read: no such file or directory" in zfs snapshot dir
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219646 Mark Linimon changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|a...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219655] TCP Connection Limit Error - sonewconn: Listen queue overflow
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219655 Mark Linimon changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|freebsd-...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219525] Multiple bugs in mpr ioctl handler
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219525
--- Comment #2 from CTurt ---
Thanks for taking a look.
To clarify the point you asked about:
`recorded_events` is a fixed size, it looks like this in `struct mpr_softc`:
mpr_event_entry_t recorded_events[MPR_EVENT_QUEUE_SIZE];
The kernel should copy out only `sizeof(sc->recored_events)` bytes at most from
here, or else it will copy out of bounds memory to userland.
Going back to the code:
size = data->Size;
if ((size >= sizeof(sc->recorded_events)) && (status == 0)) {
mpr_unlock(sc);
if (copyout((void *)sc->recorded_events,
PTRIN(data->PtrEvents), size) != 0)
status = EFAULT;
mpr_lock(sc);
}
Notice that it passes `size` to `copyout`, which can be greater than
`sizeof(sc->recorded_events)` (see the check).
Instead, the `copyout` call should be passed `sizeof(sc->recorded_events)` so
that it won't read more than the array contains.
So, you are correct when you say that it "is just checking if the user supplied
size is enough to hold sizeof(sc->recored_events)". But this check won't
prevent copying out of bounds memory to userland.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219646] "ls: fts_read: no such file or directory" in zfs snapshot dir
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219646 --- Comment #2 from g_amana...@yahoo.com --- Yes, r319096 resolves it. Any chance of getting this into 11.1-RELEASE since it is high impact and low risk? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219525] Multiple bugs in mpr ioctl handler
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219525
--- Comment #1 from Stephen McConnell ---
Thanks for the report. I know there are a few issues there, especially with the
driver not checking for bad user supplied values. I agree with most of your
comments, but I have a question.
In this section:
.
mpr_lock(sc);
size = data->Size;
if ((size >= sizeof(sc->recorded_events)) && (status == 0)) {
mpr_unlock(sc);
if (copyout((void *)sc->recorded_events,
PTRIN(data->PtrEvents), size) != 0)
status = EFAULT;
mpr_lock(sc);
} else {
/*
* data->Size value is not large enough to copy event data.
*/
status = EFAULT;
}
/*
* Change size value to match the number of bytes that were copied.
*/
if (status == 0)
data->Size = sizeof(sc->recorded_events);
mpr_unlock(sc);
.
You say:
"It checks if the user supplied size is greater than the the size of the
struct, and if so, copies using the size which it just determined was too
large. It should `copyout` using `sizeof(sc->recorded_events)`."
But this is just checking if the user supplied size is enough to hold
sizeof(sc->recored_events). It's not checking if it was too large, it's
checking if it's large enough. If that user supplied size is >= to the data
being copied, it should be OK. Do you agree?
I'm not sure I like that data->Size is being changed from the user supplied
value, but that's something different. Maybe that's OK, but not sure. It could
be that this is a normal technique used to return the number of bytes that are
valid in the user buffer, but I only see that being done in this one function.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 200553] uniq does not support -c with -u -d
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200553 --- Comment #2 from commit-h...@freebsd.org --- A commit references this bug: Author: emaste Date: Tue May 30 16:55:16 UTC 2017 New revision: 319226 URL: https://svnweb.freebsd.org/changeset/base/319226 Log: MFC r318316: uniq: allow -c to be used with -d or -u Bring in some bits from NetBSD and lift the restriction in uniq(1) that -c cannot be used with the -d and -u options. This restriction seems unnecessary and is supported at least by GNU, OpenBSD, and NetBSD. Lift the restriction and simplify the show() logic a little bit to maintain functionality when -c is provided with -d/-u. Also with this change, -d and -u are now actually a mutually exclusive, albeit valid, combination. Given that they both indicate opposite behavior, uniq(1) will no longer output anything if both -d and -u are supplied. This is in line with NetBSD as well as GNU. Adjust the man page and usage() to reflect that -c is its own standalone option. PR: 200553 Submitted by: Kyle Evans Changes: _U stable/11/ stable/11/usr.bin/uniq/uniq.1 stable/11/usr.bin/uniq/uniq.c -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219655] TCP Connection Limit Error - sonewconn: Listen queue overflow
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219655 --- Comment #2 from john@gmail.com --- I've checked multiple jails on my system, which include CouchPotato, Plex and Transmission and all have the same max of 128, yet when running sysctl kern.ipc.soacceptqueue it says that is 2048. I find it highly unlikely that 3 separate applications are applying limits to the jails. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219655] TCP Connection Limit Error - sonewconn: Listen queue overflow
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219655 Fabian Keil changed: What|Removed |Added CC||f...@fabiankeil.de --- Comment #1 from Fabian Keil --- At least on vanilla FreeBSD kern.ipc.soacceptqueue merely specifies an upper limit, it does not prevent the application from requesting a smaller one. Many applications use a hardcoded value like 128 without checking if a higher value would work. For details see the "listen" and "getsockopt" man pages. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644
--- Comment #15 from free...@ihead.ru ---
(In reply to Maxim Konovalov from comment #14)
nginx.conf is identical on both systems.
#user nobody;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pidlogs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log logs/access.log main;
sendfileon;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
root html;
index index.html index.htm;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
#proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
#root html;
#fastcgi_pass 127.0.0.1:9000;
#fastcgi_index index.php;
#fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
#includefastcgi_params;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
#deny all;
#}
location /ihead.txt {
proxy_pass http://127.0.0.1:80;
}
}
}
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644 --- Comment #14 from Maxim Konovalov --- Can you also share your nginx.conf from both systems please? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219655] TCP Connection Limit Error - sonewconn: Listen queue overflow
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219655 Bug ID: 219655 Summary: TCP Connection Limit Error - sonewconn: Listen queue overflow Product: Base System Version: 11.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: john@gmail.com I'm currently running FreeNas 11 RC1. I've edited the tunables for this item kern.ipc.soacceptqueue to allow for 2048 connections, but it doesn't propagate to the jails on my system. Below is the error I received saying the listen queue is full. May 19 18:43:24 maverick kernel: sonewconn: pcb 0xf8035bef6740: Listen queue overflow: 193 already in queue awaiting acceptance (138 occurrences) May 19 19:02:16 maverick kernel: sonewconn: pcb 0xf8035bef6740: Listen queue overflow: 193 already in queue awaiting acceptance (200 occurrences) May 19 19:03:17 maverick kernel: sonewconn: pcb 0xf8035bef6740: Listen queue overflow: 193 already in queue awaiting acceptance (209 occurrences) May 19 19:04:17 maverick kernel: sonewconn: pcb 0xf8035bef6740: Listen queue overflow: 193 already in queue awaiting acceptance (199 occurrences) May 19 19:05:17 maverick kernel: sonewconn: pcb 0xf8035bef6740: Listen queue overflow: 193 already in queue awaiting acceptance (202 occurrences) Here are the Netstat outputs from my main FreeNas system: tcp4 0/0/2048 127.0.0.1.8542 tcp4 0/0/2048 127.0.0.1.8600 tcp4 0/0/2048 127.0.0.1.8500 tcp4 0/0/2048 127.0.0.1.8400 And the output from Netstat for my jail: tcp4 0/0/128 192.168.0.20.12348 tcp6 0/0/128 *.51413 tcp4 0/0/128 *.51413 tcp4 0/0/128 *.9091 If I run sysctl kern.ipc.soacceptqueue in the jail it shows the following: # sysctl kern.ipc.soacceptqueue kern.ipc.soacceptqueue: 2048 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644 --- Comment #13 from free...@ihead.ru --- (In reply to Maxim Konovalov from comment #12) [root@freebsd10 ~]# sysctl net.inet.tcp net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 536 net.inet.tcp.keepidle: 720 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1220 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 12950 net.inet.tcp.per_cpu_timers: 0 net.inet.tcp.v6pmtud_blackhole_mss: 1220 net.inet.tcp.pmtud_blackhole_mss: 1200 net.inet.tcp.pmtud_blackhole_failed: 0 net.inet.tcp.pmtud_blackhole_activated_min_mss: 0 net.inet.tcp.pmtud_blackhole_activated: 0 net.inet.tcp.pmtud_blackhole_detection: 0 net.inet.tcp.rexmit_drop_options: 0 net.inet.tcp.keepcnt: 8 net.inet.tcp.finwait2_timeout: 6 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 3 net.inet.tcp.persmax: 6 net.inet.tcp.persmin: 5000 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15375 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.soreceive_stream: 0 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 4 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 16384 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.reass.overflows: 9 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 7900 net.inet.tcp.sendbuf_max: 2097152 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.recvbuf_max: 2097152 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.ecn.maxretries: 1 net.inet.tcp.ecn.enable: 0 net.inet.tcp.abc_l_var: 2 net.inet.tcp.rfc3465: 1 net.inet.tcp.experimental.initcwnd10: 1 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.do_pipe: 0 net.inet.tcp.drop_synfin: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 0 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.cc.available: newreno net.inet.tcp.cc.algorithm: newreno [root@freebsd11 ~]# sysctl net.inet.tcp net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 536 net.inet.tcp.keepidle: 720 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1220 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 12900 net.inet.tcp.per_cpu_timers: 0 net.inet.tcp.v6pmtud_blackhole_mss: 1220 net.inet.tcp.pmtud_blackhole_mss: 1200 net.inet.tcp.pmtud_blackhole_failed: 0 net.inet.tcp.pmtud_blackhole_activated_min_mss: 0 net.inet.tcp.pmtud_blackhole_activated: 0 net.inet.tcp.pmtud_blackhole_detection: 0 net.inet.tcp.rexmit_drop_options: 0 net.inet.tcp.keepcnt: 8 net.inet.tcp.finwait2_timeout: 6 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 3 net.inet.tcp.persmax: 6 net.inet.tcp.persmin: 5000 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15364 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.functions_available: Stack D PCB count default * 4 net.inet.tcp.functions_default: default net.inet.tcp.soreceive_stream: 0 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 4 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 16384 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 7900 net.inet.tcp.sendbuf_max: 2097152 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.recvbuf_max: 2097152 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.insecure_syn: 0 net.inet.tcp.ecn.maxretries: 1 net.inet.tcp.ecn.enable: 2 net.inet.tcp.abc_l_var: 2 net.inet.tcp.rfc3
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644 --- Comment #12 from Maxim Konovalov --- Can you share please "sysctl net.inet.tcp" on your FreeBSD 10 and FreeBSD 11? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644 --- Comment #11 from free...@ihead.ru --- (In reply to Maxim Konovalov from comment #9) [root@freebsd10 ~]# uname -a FreeBSD freebsd10.build.ihead.ru 10.3-RELEASE-p18 FreeBSD 10.3-RELEASE-p18 #0: Tue Apr 11 10:31:00 UTC 2017 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [root@freebsd10 ~]# sysctl net.inet.tcp.delayed_ack net.inet.tcp.delayed_ack: 1 [root@freebsd10 ~]# sysctl sysctl net.inet.tcp.delacktime net.inet.tcp.delacktime: 100 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644 --- Comment #10 from free...@ihead.ru --- (In reply to Maxim Konovalov from comment #9) Defaults are: sysctl net.inet.tcp.delayed_ack net.inet.tcp.delayed_ack: 1 sysctl net.inet.tcp.delacktime net.inet.tcp.delacktime: 100 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644 --- Comment #9 from Maxim Konovalov --- What are delayed_ack settings on your FreeBSD 10 system? Are they non default? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644 --- Comment #8 from free...@ihead.ru --- sysctl net.inet.tcp.delayed_ack net.inet.tcp.delayed_ack: 1 sysctl net.inet.tcp.delacktime net.inet.tcp.delacktime: 100 1) sysctl net.inet.tcp.delayed_ack=0 net.inet.tcp.delayed_ack: 1 -> 0 Problem is not reproduced. 2) sysctl net.inet.tcp.delayed_ack=1 net.inet.tcp.delayed_ack: 0 -> 1 sysctl net.inet.tcp.delacktime=200 net.inet.tcp.delacktime: 100 -> 200 Problem is reproduced with +0.2 seconds delay. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644 --- Comment #7 from free...@ihead.ru --- Created attachment 183064 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183064&action=edit tcpdump on FresBSD11 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644 --- Comment #6 from free...@ihead.ru --- Created attachment 183063 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183063&action=edit tcpdump on FresBSD10 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644 --- Comment #5 from free...@ihead.ru --- Created attachment 183062 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183062&action=edit apache ktrace on FreeBSD10 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644 --- Comment #4 from free...@ihead.ru --- Created attachment 183061 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183061&action=edit nginx ktrace on FreeBSD10 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644 Maxim Konovalov changed: What|Removed |Added CC||ma...@freebsd.org --- Comment #3 from Maxim Konovalov --- Hello, As was suggested in nginx trac ticket gathering tcpdump on FreeBSD 11 and 10 would be useful as well. Also, comparing problematic traces with FreeBSD 10 is also a good idea. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399 --- Comment #9 from Andriy Gapon --- Nils, I am not aware of any "mini test" that would be as good as a poudriere build or a highly parallel buildworld. I am not sure that the nvidia is really a culprit here, the stack frames beyond the trap frame look rather messed up. Maybe it's not that surprising given that the original trap type is 0xc, #SS, Stack-Segment Fault. Perhaps there was a stack overflow. If in kgdb you do 'list *0x831e410b', does it also point to _nv000224rm ? The inability of kgdb to deal with the memory dump suggests a possibility of critical page table structures being corrupt or a significant binary mismatch between the userland (libkvm, etc) and the kernel. FWIW, I found a bug report with somewhat similar backtrace, but it does not have any enlightening details: bug #193622. Perhaps a mismatch between the module and the kernel... -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219644] FreeBSD 11 + nginx + apache delay +0.1 second on files greater than 32768 bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219644 free...@ihead.ru changed: What|Removed |Added Severity|Affects Only Me |Affects Many People -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399 --- Comment #8 from Nils Beyer --- okay, got a screen capture of the crash. It seems related to the Nvidia driver. So I removed the Nvida card and inserted an AMD Radeon card instead. The non-mini crash dump is usable neither with "kgbd" nor "kgdb7121" - both complain about "cannot read KPML4phys". At the moment I'm running a poudriere bulk build again... -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399 --- Comment #7 from Nils Beyer --- Created attachment 183054 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183054&action=edit screenshot of crash with backtrace -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
