Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
> On Dec 22, 2018, at 1:03 PM, Cy Schubert wrote: … > Regarding the Red Hat bugzilla bug, looks like they're doing the right > thing by reaching out to VMware. This should be our position as well. > Add it to ssh_config or sshd_config if one must but have VMware fix > their bugs. Putting workarounds in our O/S to work around a bug in some > other vendor's virtualization is something I don't support. If we must > add the #ifdefs to our ssh, then add an UPDATING entry to say that to > enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable it > in src.conf. This is the reason why I CCed mp@ :).. Mark works for VMware (I worked with him a bit when I was at Isilon). … > We, FreeBSD, should try to open a ticket or reach out to VMware to add > a +1 to the issue that RH has already opened. This is the right thing > to do. In this case we should consider ourselves an O/S vendor too, > which BTW we are. Yes, but unless there’s a champion internal to the project driving this, it’s up to individual users to drive the bug report/fix. If, however, there were regular regression tests run with VMware (and this can be done with pyvmomi/paramiko, etc), then we the project could provide this guarantee to VMware and vice versa if VMware invested the time in making this so--which I thought they did with 10.x… but if they don’t have an easy way to verify changes, there’s a bit of a chicken and egg problem. > BTW the 2018-11-08 entry in the RH bug talks about adding the > workaround to sshd_config. … which is what I did instead of making the code change. Thanks so very much for the patch and (more importantly) for the discussion/solution Yuri!! I really appreciate your unblocking me. Cheers, -Enji signature.asc Description: Message signed with OpenPGP
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <0503b382-d886-39a4-d265-b43d8adc1...@yuripv.net>, Yuri Pankov write s: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --e7sW91Qf9WxzTaujtGEdAimN5k2EtpJ6Q > Content-Type: multipart/mixed; boundary="3a9zlXDI7Z2P48EdQkgwMdVOMQOEfR5Wm"; > protected-headers="v1" > From: Yuri Pankov > To: Cy Schubert > Cc: Mark Peek , Enji Cooper , > Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= > , freebsd-current > Message-ID: <0503b382-d886-39a4-d265-b43d8adc1...@yuripv.net> > Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 > changes > References: <20181027.wbmkrgwj050...@slippy.cwsent.com> > In-Reply-To: <20181027.wbmkrgwj050...@slippy.cwsent.com> > > --3a9zlXDI7Z2P48EdQkgwMdVOMQOEfR5Wm > Content-Type: text/plain; charset=utf-8 > Content-Language: en-US > Content-Transfer-Encoding: quoted-printable > > Cy Schubert wrote: > > In message , Yuri=20 > > Pankov write > > s: > >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > >> --NAG3HGfiwhsHyGq3aNdsIv1NzTEMODbUH > >> Content-Type: multipart/mixed; boundary=3D"c7yUHUJpZYpJqOrOWLAb4sE3Rmh= > 2alrdi"; > >> protected-headers=3D"v1" > >> From: Yuri Pankov > >> To: Cy Schubert > >> Cc: Mark Peek , Enji Cooper , > >> Warner Losh , =3D?UTF-8?Q?Dag-Erling_Sm=3Dc3=3Db8rgra= > v?=3D > >> , freebsd-current > >> Message-ID: > >> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8= > p1 > >> changes > >> References: <20181009.wbmk9h5t050...@slippy.cwsent.com> > >> In-Reply-To: <20181009.wbmk9h5t050...@slippy.cwsent.com> > >> > >> --c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi > >> Content-Type: text/plain; charset=3Dutf-8 > >> Content-Language: en-US > >> Content-Transfer-Encoding: quoted-printable > >> > >> Cy Schubert wrote: > >>> In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri=3D= > 20 > >>> Pankov write > >>> s: > Yuri Pankov wrote: > > In-Reply-To: ai=3D > >> > >>> l.gmail. > > com> > > Mark Peek wrote: > >> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper > > >>> wro=3D3D > > te: > >> =3D3D20 > >>> > 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=3D= > 20 > >>> interna=3D3D > > l > > VMware desktop product contact. > > Thank you. > > > What version of Workstation or Fusion is this occurring on? I=3D= > 20 > >>> saw > > Workstation 14 mentioned but curious if it occurs on=3D20 > >>> Workstation 15 > > (latest). > > Running the latest available for download: 15.0.2 build-10952284= > =2E > >>> > >>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it=3D= > 20 > >>> wasn=3D3DE2=3D3D > > =3D3D80=3D3D99t > >>> affecting me on 10.x. I didn=3D3DE2=3D3D80=3D3D99t install 11.0.0= > , so I=3D20 > >>> don=3D3DE2=3D3D80=3D3D99=3D3D > > t know if it > >>> affects that version... > >>> > >>> Thanks so much! > >>> > >>> -Enji > >> =3D3D20 > >> =3D3D20 > >> BTW, there appears to be a workaround here using -o=3D20 > >>> 'IPQoS=3D3D3Dthroughput=3D3D > > ' > >> (untested by me). I've seen the issue forwarded internally but no=3D= > 20 > >>> furth=3D3D > > er > >> discussions yet. > >> =3D3D20 > >> https://communities.vmware.com/thread/590825 > > Yes, that's exactly what the patch attached to original message does= > i=3D > >> f > we are running as a VMware guest. The workaround is known and it wo= > rk=3D > >> s, > but it's not immediately clear and I just wanted it to be the defaul= > t > for the time being. > >>> =3D20 > >>> The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this=3D= > 20 > >>> intended? > >> > >> It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it ca= > n > >> be ripped out easily when no longer needed, and yes, it's enabled > >> unconditionally for now. And the check itself is if 'kern.vm_guest' > >> reports 'vmware'. > >=20 > > It doesn't look that conditional to me. > > Indeed, and that's what I said exactly :-) The added code is enabled > unconditionally, and the added code also has a check for vmware guest. > The ifdefs are there only to show that this is local addition, nothing el= > se. > > I'm not saying it needs to be done this way, this is just something I > did quickly after installing yet another VM and forgetting to modify my > ~/.ssh/config to include the workaround. First and foremost a ticket with VMware should be opened. They really need to fix yet another regression. Regarding the Red Hat bugzilla bug, looks like they're doing the right thing by reaching out to VMware. This should be our position as well. Add it to ssh_config or sshd_config if one must but have VMware fix their bugs. Putting workarounds in our O/S to work around a bug in some other vendor's
Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
[I found my E-mail records reporting successful builds using
qemu-user-static from ports head -r484783 under FreeBSD
head -r340287.]
On 2018-Dec-22, at 00:10, Mark Millard wrote:
> [I messed up the freebsd-emulation email address the first time I sent
> this. I also forgot to indicate the qemu-user-static vintage relationship.]
>
> 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.
>
> ADDED: The qemu-user-static back with head -r340287 before installing the
> updated ports would likely be different than the -r484783 vintage. So both
> FreeBSD and qemu-user-static may have changed over the comparison.
CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful cross-builds
based on qemu-user-static from ports head -484783 --all built under FreeBSD
head -r340287 . So the use of the perl5.28 as the forced-default and the
newer FreeBSD head version -r341836 as the context are the differences here.
> 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
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert wrote: > In message , Yuri > Pankov write > s: >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) >> --NAG3HGfiwhsHyGq3aNdsIv1NzTEMODbUH >> Content-Type: multipart/mixed; boundary="c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi"; >> protected-headers="v1" >> From: Yuri Pankov >> To: Cy Schubert >> Cc: Mark Peek , Enji Cooper , >> Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= >> , freebsd-current >> Message-ID: >> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 >> changes >> References: <20181009.wbmk9h5t050...@slippy.cwsent.com> >> In-Reply-To: <20181009.wbmk9h5t050...@slippy.cwsent.com> >> >> --c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi >> Content-Type: text/plain; charset=utf-8 >> Content-Language: en-US >> Content-Transfer-Encoding: quoted-printable >> >> Cy Schubert wrote: >>> In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri=20 >>> Pankov write >>> s: Yuri Pankov wrote: > In-Reply-To: > >>> l.gmail. > com> > Mark Peek wrote: >> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper >>> wro=3D > te: >> =3D20 >>> 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=20 >>> interna=3D > l > VMware desktop product contact. Thank you. > What version of Workstation or Fusion is this occurring on? I=20 >>> saw > Workstation 14 mentioned but curious if it occurs on=20 >>> 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=20 >>> wasn=3DE2=3D > =3D80=3D99t >>> affecting me on 10.x. I didn=3DE2=3D80=3D99t install 11.0.0, so I=20 >>> don=3DE2=3D80=3D99=3D > t know if it >>> affects that version... >>> >>> Thanks so much! >>> >>> -Enji >> =3D20 >> =3D20 >> BTW, there appears to be a workaround here using -o=20 >>> 'IPQoS=3D3Dthroughput=3D > ' >> (untested by me). I've seen the issue forwarded internally but no=20 >>> furth=3D > er >> discussions yet. >> =3D20 >> https://communities.vmware.com/thread/590825 Yes, that's exactly what the patch attached to original message does i= >> f we are running as a VMware guest. The workaround is known and it work= >> s, but it's not immediately clear and I just wanted it to be the default for the time being. >>> =20 >>> The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this=20 >>> intended? >> >> It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can >> be ripped out easily when no longer needed, and yes, it's enabled >> unconditionally for now. And the check itself is if 'kern.vm_guest' >> reports 'vmware'. > > It doesn't look that conditional to me. Indeed, and that's what I said exactly :-) The added code is enabled unconditionally, and the added code also has a check for vmware guest. The ifdefs are there only to show that this is local addition, nothing else. I'm not saying it needs to be done this way, this is just something I did quickly after installing yet another VM and forgetting to modify my ~/.ssh/config to include the workaround. signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message , Yuri
Pankov write
s:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --NAG3HGfiwhsHyGq3aNdsIv1NzTEMODbUH
> Content-Type: multipart/mixed; boundary="c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi";
> protected-headers="v1"
> From: Yuri Pankov
> To: Cy Schubert
> Cc: Mark Peek , Enji Cooper ,
> Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?=
> , freebsd-current
> Message-ID:
> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1
> changes
> References: <20181009.wbmk9h5t050...@slippy.cwsent.com>
> In-Reply-To: <20181009.wbmk9h5t050...@slippy.cwsent.com>
>
> --c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi
> Content-Type: text/plain; charset=utf-8
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
>
> Cy Schubert wrote:
> > In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri=20
> > Pankov write
> > s:
> >> Yuri Pankov wrote:
> >>> In-Reply-To:
> > l.gmail.
> >>> com>
> >>> Mark Peek wrote:
> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper
> > wro=3D
> >>> te:
> =3D20
> >
> >> 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=20
> > interna=3D
> >>> l
> >>> VMware desktop product contact.
> >>
> >> Thank you.
> >>
> >>> What version of Workstation or Fusion is this occurring on? I=20
> > saw
> >>> Workstation 14 mentioned but curious if it occurs on=20
> > 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=20
> > wasn=3DE2=3D
> >>> =3D80=3D99t
> > affecting me on 10.x. I didn=3DE2=3D80=3D99t install 11.0.0, so I=20
> > don=3DE2=3D80=3D99=3D
> >>> t know if it
> > affects that version...
> >
> > Thanks so much!
> >
> > -Enji
> =3D20
> =3D20
> BTW, there appears to be a workaround here using -o=20
> > 'IPQoS=3D3Dthroughput=3D
> >>> '
> (untested by me). I've seen the issue forwarded internally but no=20
> > furth=3D
> >>> er
> discussions yet.
> =3D20
> https://communities.vmware.com/thread/590825
> >>
> >> Yes, that's exactly what the patch attached to original message does i=
> f
> >> we are running as a VMware guest. The workaround is known and it work=
> s,
> >> but it's not immediately clear and I just wanted it to be the default
> >> for the time being.
> >=20
> > The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this=20
> > intended?
>
> It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can
> be ripped out easily when no longer needed, and yes, it's enabled
> unconditionally for now. And the check itself is if 'kern.vm_guest'
> reports 'vmware'.
It doesn't look that conditional to me.
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}
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
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
Cy Schubert wrote: > In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri > Pankov write > s: >> Yuri Pankov wrote: >>> In-Reply-To: l.gmail. >>> com> >>> Mark Peek wrote: On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper > wro= >>> te: =20 > >> 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 > interna= >>> l >>> 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=E2= >>> =80=99t > affecting me on 10.x. I didn=E2=80=99t install 11.0.0, so I > don=E2=80=99= >>> t know if it > affects that version... > > Thanks so much! > > -Enji =20 =20 BTW, there appears to be a workaround here using -o > 'IPQoS=3Dthroughput= >>> ' (untested by me). I've seen the issue forwarded internally but no > furth= >>> er discussions yet. =20 https://communities.vmware.com/thread/590825 >> >> Yes, that's exactly what the patch attached to original message does if >> we are running as a VMware guest. The workaround is known and it works, >> but it's not immediately clear and I just wanted it to be the default >> for the time being. > > The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this > intended? It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can be ripped out easily when no longer needed, and yes, it's enabled unconditionally for now. And the check itself is if 'kern.vm_guest' reports 'vmware'. > Juxtaposed to this, at $JOB where our VMware guests (mostly Linux and > Windows) running on VMware clusters with NSX network (with plans to > totally virtualize the network), we've noticed other network > quirkiness, most notably with NFS between unlike O/S's, i.e. Solaris > <--> Linux. I'm not surprised that this regression also exists. > > signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri Pankov write s: > Yuri Pankov wrote: >> In-Reply-To: > com> >> Mark Peek wrote: >> > On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wro= >> te: >> >=20 >> >> >> >>> 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 interna= >> l >> 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=E2= >> =80=99t >> >> affecting me on 10.x. I didn=E2=80=99t install 11.0.0, so I don=E2=80=99= >> t know if it >> >> affects that version... >> >> >> >> Thanks so much! >> >> >> >> -Enji >> >=20 >> >=20 >> > BTW, there appears to be a workaround here using -o 'IPQoS=3Dthroughput= >> ' >> > (untested by me). I've seen the issue forwarded internally but no furth= >> er >> > discussions yet. >> >=20 >> > https://communities.vmware.com/thread/590825 > > Yes, that's exactly what the patch attached to original message does if > we are running as a VMware guest. The workaround is known and it works, > but it's not immediately clear and I just wanted it to be the default > for the time being. The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this intended? Juxtaposed to this, at $JOB where our VMware guests (mostly Linux and Windows) running on VMware clusters with NSX network (with plans to totally virtualize the network), we've noticed other network quirkiness, most notably with NFS between unlike O/S's, i.e. Solaris <--> Linux. I'm not surprised that this regression also exists. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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 Sat, Dec 22, 2018, 11:03 AM Yuri Pankov Mark Peek wrote: > > On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper > wrote: > > > >> > >>> 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 > > > > > > BTW, there appears to be a workaround here using -o 'IPQoS=throughput' > > (untested by me). I've seen the issue forwarded internally but no further > > discussions yet. > > > > https://communities.vmware.com/thread/590825 > > Yes, that's exactly what the patch attached to original message does if > we are running as a VMware guest. The workaround is known and it works, > but it's not immediately clear and I just wanted it to be the default > for the time being. > Fixes my world... Warner > ___ 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: > On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wrote: > >> >>> 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 > > > BTW, there appears to be a workaround here using -o 'IPQoS=throughput' > (untested by me). I've seen the issue forwarded internally but no further > discussions yet. > > https://communities.vmware.com/thread/590825 Yes, that's exactly what the patch attached to original message does if we are running as a VMware guest. The workaround is known and it works, but it's not immediately clear and I just wanted it to be the default for the time being. signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wrote: > > > 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 BTW, there appears to be a workaround here using -o 'IPQoS=throughput' (untested by me). I've seen the issue forwarded internally but no further discussions yet. https://communities.vmware.com/thread/590825 Mark ___ 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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
[I messed up the freebsd-emulation email address the first time I sent
this. I also forgot to indicate the qemu-user-static vintage relationship.]
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.
ADDED: The qemu-user-static back with head -r340287 before installing the
updated ports would likely be different than the -r484783 vintage. So both
FreeBSD and qemu-user-static may have changed over the comparison.
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"
