Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: > > Mark Peek wrote: >> Thanks for the cc:. I forwarded the original report on to an internal >> VMware desktop product contact. > > Thank you. > >> What version of Workstation or Fusion is this occurring on? I saw >> Workstation 14 mentioned but curious if it occurs on Workstation 15 >> (latest). > > Running the latest available for download: 15.0.2 build-10952284. This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t affecting me on 10.x. I didn’t install 11.0.0, so I don’t know if it affects that version... Thanks so much! -Enji ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ctm(1) deprecation in the FreeBSD base system?
> The port Makefile that I have prepared is attached below for reference. > Regards, STefan Thanks Stefan, I took current /usr/ports/misc/ctm/ & converted Stephen's & my diffs to be automatic ports patches: http://berklix.com/~jhs/src/bsd/fixes/freebsd/ports/gen/misc/ctm/files/ http://berklix.com/~jhs/src/bsd/fixes/freebsd/ports/gen/misc/ctm/README.JHS Stephens diffs are essential, without them CTM broke long ago, (5 digit numeric names maybe ?) I haven't checked all execution as my ctm_rmail scripts run automaticaly on an older release, not my current box, but this is running OK so far: ctm -q /pub/FreeBSD/development/CTM/svn-cur/svn-cur.07000xEmpty.xz ; ctm -q /pub/FreeBSD/development/CTM/svn-cur/svn-cur.07[0-9][0-9][0-9].xz Stephen may be best person to test delta builds, as hes the delta originator. Soonish I'll set up a [freebsd-]ctm-src-12 on http://mailman.berklix.org/mailman/listinfo if Stephens' & my requests to postmaster @ & mailman @ freebsd.org continues to get no response. Cheers, Julian -- Julian Stacey, Computer Consultant Sys.Eng. BSD Linux Unix, Munich Aachen Kent First referendum stole 700,000 votes from Brits in EU; 3,700,000 globaly. Lies criminal funded; jobs pound & markets down. 1.9M new voters 1.3M dead. Email MP: "A new referendum will buy UK & EU more time (Art 50.3), to avoid a hard crash, & consider all options." http://berklix.org/brexit/#mp ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} port
cross
builds in another message sequence. But it turns out that one thing I ran into
has hung-up every time, the same way, for amd64->armv7 cross builds:
multimedia/gstreamer1-qt@qt5 . So I extract the material here into a separate
report
with some updated notes.
A little context: I had built from ports head -r484783 before under FreeBSD head
-r340287 (as I remember the version). Back then it did not have this problem
that it
now has under FreeBSD head -r341836 . One ports-specific change was to force
perl5.28
as the default instead of perl5.26 originally. In fact this is what drives what
is
being rebuilt for my experiment that caught this. But I doubt the perl version
is
important to the problem. The context has a Ryzen Threadripper 1950X and has
been
tested both for FreeBSD under Hyper-V and for the same media native-booted. Both
hang-up at the same point as seen via ps or top. The native tools for
cross-build
speedup were in use. Cross-builds targeting aarch64 did not get this problem but
targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for the
first
armv7 try.
The hang-up:
In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up and
timed
out. Looking during the wait in later tries shows something much like (from one
of the
examples):
root 337190.0 0.0 12920 3528 0 I11:40 0:00.03 | |
`-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg
(gstreamer1-qt5-1.2.0_14) (sh)
root 415510.0 0.0 12920 3520 0 I11:43 0:00.00 | |
`-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg
(gstreamer1-qt5-1.2.0_14) (sh)
root 415520.0 0.0 10340 1744 0 IJ 11:43 0:00.01 | |
`-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5
build
root 415660.0 0.0 10236 1796 0 IJ 11:43 0:00.00 | |
`-- /bin/sh -e -c (cd
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! /usr/bin/env
QT_SELE
root 415670.0 0.0 89976 12896 0 IJ 11:43 0:00.07 | |
`-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
root 415850.0 0.0 102848 25056 0 IJ 11:43 0:00.10 | |
|-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E
cmake_autogen /wrkdirs/usr/ports/multimedia/g
root 415860.0 0.0 102852 25072 0 IJ 11:43 0:00.11 | |
`-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E
cmake_autogen /wrkdirs/usr/ports/multimedia/g
or as top showed it:
41552 root 1 52010M 1744K0 wait15 0:00 0.00%
/usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
41566 root 1 52010M 1796K0 wait 1 0:00 0.00%
/bin/sh -e -c (cd /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build;
if ! /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
41567 root 2 52088M13M0 select 4 0:00 0.00%
/usr/local/bin/qemu-arm-static ninja -j28 -v all
41585 root 2 520 100M24M0 kqread 8 0:00 0.00%
/usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
41586 root 2 520 100M24M0 kqread 22 0:00 0.00%
/usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
So: waiting in kqread trying to run cmake.
Unlike some intermittent hang-ups, attaching-then-detaching via gdb does not
resume the hung-up processes. Kills of the processes waiting on kqread stop
the build.
Given the prior ports have been built already, building just
multimedia/gstreamer1-qt@qt5 still gets the hang-up at the same point.
Building anything that requires multimedia/gstreamer1-qt@qt5 seems to be
solidly blocked in my environment.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Mark Peek wrote: > Thanks for the cc:. I forwarded the original report on to an internal > VMware desktop product contact. Thank you. > What version of Workstation or Fusion is this occurring on? I saw > Workstation 14 mentioned but curious if it occurs on Workstation 15 > (latest). Running the latest available for download: 15.0.2 build-10952284. > On Fri, Dec 21, 2018 at 4:19 PM Warner Losh wrote: > >> I've been hit by this as well. At least two others on IRC have had the >> same issue. >> >> Warner >> >> On Fri, Dec 21, 2018 at 5:10 PM Enji Cooper wrote: >> >>> On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote: Hi, There's apparently a bug in VMware Workstation NAT implementation, made visible by the change to default values of IPQoS in OpenSSH 7.8p1, making all ssh connections from the guest behind the NAT to fail with obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22: Broken pipe". I wonder if we could integrate the attached patch (or some smarter version of it) for the time being as the bug affects several major WS releases, and it's not immediately clear where the problem is. The change itself: >>> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 The bug reports (some of them): https://bugzilla.redhat.com/show_bug.cgi?id=1624437 https://communities.vmware.com/message/2803219#2803219 The patch itself is attached. >>> >>> Cool… yeah… I’ve been running into this issue for a while with >>> VMware Fusion 11.0.1. >>> I CCed mp@ for visibility. >>> Thanks! >>> -Enji >>> >> > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Thanks for the cc:. I forwarded the original report on to an internal VMware desktop product contact. What version of Workstation or Fusion is this occurring on? I saw Workstation 14 mentioned but curious if it occurs on Workstation 15 (latest). Mark On Fri, Dec 21, 2018 at 4:19 PM Warner Losh wrote: > I've been hit by this as well. At least two others on IRC have had the > same issue. > > Warner > > On Fri, Dec 21, 2018 at 5:10 PM Enji Cooper wrote: > >> >> > On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote: >> > >> > Hi, >> > >> > There's apparently a bug in VMware Workstation NAT implementation, made >> > visible by the change to default values of IPQoS in OpenSSH 7.8p1, >> > making all ssh connections from the guest behind the NAT to fail with >> > obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22: >> > Broken pipe". >> > >> > I wonder if we could integrate the attached patch (or some smarter >> > version of it) for the time being as the bug affects several major WS >> > releases, and it's not immediately clear where the problem is. >> > >> > The change itself: >> > >> > >> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 >> > >> > The bug reports (some of them): >> > >> > https://bugzilla.redhat.com/show_bug.cgi?id=1624437 >> > https://communities.vmware.com/message/2803219#2803219 >> > >> > The patch itself is attached. >> > >> >> Cool… yeah… I’ve been running into this issue for a while with >> VMware Fusion 11.0.1. >> I CCed mp@ for visibility. >> Thanks! >> -Enji >> > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
I've been hit by this as well. At least two others on IRC have had the same issue. Warner On Fri, Dec 21, 2018 at 5:10 PM Enji Cooper wrote: > > > On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote: > > > > Hi, > > > > There's apparently a bug in VMware Workstation NAT implementation, made > > visible by the change to default values of IPQoS in OpenSSH 7.8p1, > > making all ssh connections from the guest behind the NAT to fail with > > obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22: > > Broken pipe". > > > > I wonder if we could integrate the attached patch (or some smarter > > version of it) for the time being as the bug affects several major WS > > releases, and it's not immediately clear where the problem is. > > > > The change itself: > > > > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 > > > > The bug reports (some of them): > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1624437 > > https://communities.vmware.com/message/2803219#2803219 > > > > The patch itself is attached. > > > > Cool… yeah… I’ve been running into this issue for a while with > VMware Fusion 11.0.1. > I CCed mp@ for visibility. > Thanks! > -Enji > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
> On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote: > > Hi, > > There's apparently a bug in VMware Workstation NAT implementation, made > visible by the change to default values of IPQoS in OpenSSH 7.8p1, > making all ssh connections from the guest behind the NAT to fail with > obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22: > Broken pipe". > > I wonder if we could integrate the attached patch (or some smarter > version of it) for the time being as the bug affects several major WS > releases, and it's not immediately clear where the problem is. > > The change itself: > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 > > The bug reports (some of them): > > https://bugzilla.redhat.com/show_bug.cgi?id=1624437 > https://communities.vmware.com/message/2803219#2803219 > > The patch itself is attached. > Cool… yeah… I’ve been running into this issue for a while with VMware Fusion 11.0.1. I CCed mp@ for visibility. Thanks! -Enji signature.asc Description: Message signed with OpenPGP
workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Hi,
There's apparently a bug in VMware Workstation NAT implementation, made
visible by the change to default values of IPQoS in OpenSSH 7.8p1,
making all ssh connections from the guest behind the NAT to fail with
obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22:
Broken pipe".
I wonder if we could integrate the attached patch (or some smarter
version of it) for the time being as the bug affects several major WS
releases, and it's not immediately clear where the problem is.
The change itself:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284
The bug reports (some of them):
https://bugzilla.redhat.com/show_bug.cgi?id=1624437
https://communities.vmware.com/message/2803219#2803219
The patch itself is attached.
diff --git a/crypto/openssh/readconf.c b/crypto/openssh/readconf.c
index f97a6ac72a95..9ed6902a0f46 100644
--- a/crypto/openssh/readconf.c
+++ b/crypto/openssh/readconf.c
@@ -16,6 +16,9 @@
__RCSID("$FreeBSD$");
#include
+#ifdef VMWARE_GUEST_WORKAROUND
+#include
+#endif
#include
#include
#include
@@ -1954,6 +1957,15 @@ fill_default_options(Options * options)
{
char *all_cipher, *all_mac, *all_kex, *all_key;
int r;
+#ifdef VMWARE_GUEST_WORKAROUND
+ char scval[7]; /* "vmware\0" */
+ size_t scsiz = sizeof(scval);
+ int vmwguest = 0;
+
+ if (sysctlbyname("kern.vm_guest", scval, , NULL, 0) == 0 &&
+ strcmp(scval, "vmware") == 0)
+ vmwguest = 1;
+#endif
if (options->forward_agent == -1)
options->forward_agent = 0;
@@ -2088,8 +2100,18 @@ fill_default_options(Options * options)
if (options->visual_host_key == -1)
options->visual_host_key = 0;
if (options->ip_qos_interactive == -1)
+#ifdef VMWARE_GUEST_WORKAROUND
+ if (vmwguest)
+ options->ip_qos_interactive = IPTOS_LOWDELAY;
+ else
+#endif
options->ip_qos_interactive = IPTOS_DSCP_AF21;
if (options->ip_qos_bulk == -1)
+#ifdef VMWARE_GUEST_WORKAROUND
+ if (vmwguest)
+ options->ip_qos_bulk = IPTOS_THROUGHPUT;
+ else
+#endif
options->ip_qos_bulk = IPTOS_DSCP_CS1;
if (options->request_tty == -1)
options->request_tty = REQUEST_TTY_AUTO;
diff --git a/secure/usr.bin/ssh/Makefile b/secure/usr.bin/ssh/Makefile
index 614cc7627fc5..023fa4a55be9 100644
--- a/secure/usr.bin/ssh/Makefile
+++ b/secure/usr.bin/ssh/Makefile
@@ -37,6 +37,9 @@ LIBADD+= crypto
CFLAGS+= -DXAUTH_PATH=\"${LOCALBASE}/bin/xauth\"
.endif
+# Workaround VMware Workstation NAT bug
+CFLAGS+=-DVMWARE_GUEST_WORKAROUND
+
.include
.PATH: ${SSHDIR}
signature.asc
Description: OpenPGP digital signature
Re: AESNI, /dev/crypto, and new OpenSSL
On Fri, Dec 21, 2018 at 01:10:07AM +0700, Alexey Dokuchaev wrote: > On Thu, Dec 20, 2018 at 09:33:41AM -0800, Freddie Cash wrote: > > On Thu, Dec 20, 2018 at 9:21 AM Alexey Dokuchaev wrote: > > > Had something got broken here, or I'm misunderstanding how this machinery > > > now works? > > > > Start reading here: > > > > https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090195.html > > > > That thread covers this issue. :) Along with the "fix" for it. > > Thanks for the pointer. I've checked both -current and -hackers MLs prior > to posting, but didn't expect this would show up on -stable first. :) In case people find this thread and want quick answers without having to deviate to -stable, here's a quick summary and my speed test results, with some quotes from delphij@, jhb@, et al.: 1) aesni(4) and crypto[dev](4) modules are not required now for OpenSSL, and userland acceleration in general, to work; 2) On capable systems, AES-NI would be used automatically. In fact, it's much faster to use the AES-NI instructions in userland than to use a system call that copies the data into a kernel buffer, uses the same AES-NI instructions, then copies the data back out again along with the overhead of a pair of user <--> kernel transitions. (Note from me: if you've observed very strange results when using -evp with aesni(4) + BSD cryptodev engine on OpenSSL 1.0.2, it was probably because of that user <--> kernel multicopying.) Some quick naive benchmarks on AMD A8-5550M APU (results were trimmed for brevity): baseline: openssl speed -elapsed aes-128-cbc: 16 bytes64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes 35922.35k 39346.28k 40492.29k 94625.81k 95194.36k95619.24k hardware extensions: openssl speed -elapsed -evp aes-128-cbc 16 bytes64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes 133823.08k 186960.39k 226363.05k 238189.15k 241782.56k 241646.38k AES-NI disabled: env OPENSSL_ia32cap="~0x200" openssl speed -elapsed -evp aes-128-cbc: 16 bytes64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes 54820.92k 64884.98k 69229.02k 70424.31k 70731.22k70714.02k It's interesting how -evp run w/o AES-NI got capped at ~67 GB/s, while the baseline had sustained at ~91 GB/s. AES-NI run had reached pretty solid ~230 GB/s. ./danfe ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
