poudriere extract failures with TAR=/usr/local/bin/gtar with gtar from ports

2018-10-15 Thread Graham Perrin
For example: > [00:01:10] [02] [00:00:19] Finished www/qt5-webkit | > qt5-webkit-5.212.0.a2_13: Failed: extract In full: root@momh167-gjp4-hpelitebook8570p-freebsd:~ # date ; uname -v ; pkg upgrade -f -r poudriere archivers/gtar Tue 16 Oct 2018 06:03:24 BST FreeBSD 12.0-ALPHA9 r339356

Re: Problem compiling rust: observations on swap: GNU tar

2018-10-15 Thread Cy Schubert
In message <97680f3e-fb00-abc7-81d5-c61c9cae7...@gmail.com>, Graham Perrin writ es: > On 14/10/2018 22:34, Cy Schubert wrote: > > > Set TAR in make.conf to gnu tar from ports. Some tarballs will cause bsdtar > to exhaust memory and swap. There was discussion a while ago suggesting this > is a

Problem compiling rust: observations on swap: GNU tar

2018-10-15 Thread Graham Perrin
On 14/10/2018 22:34, Cy Schubert wrote: > Set TAR in make.conf to gnu tar from ports. Some tarballs will cause bsdtar > to exhaust memory and swap. There was discussion a while ago suggesting this > is a bug in vmm. Thanks! My make.conf for poudriere:

Re: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

2018-10-15 Thread Enji Cooper (yaneurabeya)
> On Oct 15, 2018, at 6:10 AM, Gleb Smirnoff wrote: > > Enji, > > can you please check that with this patch all your tests pass? Hi Gleb! It almost compiled. I just needed to dereference the `so` pointer: $ git diff /usr/src/sys/kern/kern_sendfile.c diff --git

Re: OpenSSL 1.1.1 Update report (ongoing)

2018-10-15 Thread Eric McCorkle
* gnome-vfs: C compile errors related to openssl, no viable mitigation Almost done now, though ptlib and gnome-vfs may cause runtime trouble On 10/14/18 7:13 PM, Eric McCorkle wrote: > * ptlib; Fails to build, due to C compiler errors arising from > source-level incompatibilities. This gets

Re: vm_fault on boot with NVMe/nda

2018-10-15 Thread Warner Losh
At Netflix we have our OCA firmware based on FreeBSD -current (we take a snapshot every 5 weeks or so). We've been booting thousands of machines off nda for over a year... It absolutely works and is one of the things that lets us deliver the content we do... I have some patches in my queue

Re: vm_fault on boot with NVMe/nda

2018-10-15 Thread Yuri Pankov
Daniel Nebdal wrote: > Hi. I have a 12-ALPHA9 / r339331 amd64 system (a HPE ProLiant ML30 G9), > with a Kingston NVMe SSD ("KINGSTON SKC1000480G") on a PCIe card. > > By default, it shows up as /dev/nvd0, and this is how I installed the > system. It has a single large UFS2 (with SJ and TRIM

vm_fault on boot with NVMe/nda

2018-10-15 Thread Daniel Nebdal
Hi. I have a 12-ALPHA9 / r339331 amd64 system (a HPE ProLiant ML30 G9), with a Kingston NVMe SSD ("KINGSTON SKC1000480G") on a PCIe card. By default, it shows up as /dev/nvd0, and this is how I installed the system. It has a single large UFS2 (with SJ and TRIM support) partition mounted as /.

Re: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

2018-10-15 Thread Gleb Smirnoff
Enji, can you please check that with this patch all your tests pass? -- Gleb Smirnoff Index: sys/kern/kern_sendfile.c === --- sys/kern/kern_sendfile.c (revision 339098) +++ sys/kern/kern_sendfile.c (working copy) @@ -526,6 +526,8

Re: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

2018-10-15 Thread Gleb Smirnoff
On Sun, Oct 14, 2018 at 10:17:28PM -0700, Enji Cooper (yaneurabeya) wrote: E> Oh yipes. I guess passing in a server socket (a bound and listening socket) instead of a client socket (connect’ed to a server socket) for `s` will result in a crash? Oh, thanks enough info. Thanks! Isn't related to

Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-15 Thread Mike Tancsa
On 10/14/2018 2:19 PM, Mateusz Guzik wrote: > On 10/14/18, Mike Tancsa wrote: >> On 10/13/2018 12:48 PM, Allan Jude wrote: >>> Strange that your crash is in ZFS here... >>> >>> Can you take a crash dump? >>> >>> It looks like something is trying to write to uninitialized memory here. >> I will