crash: umount_nfs: Current

Recent current, playing with new FreeNAS Corral, client is FreeBSD -CURRENT. Lovely crash: borg.lerctr.org dumped core - see /var/crash/vmcore.1 Wed Mar 15 21:38:53 CDT 2017 FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r315289: Tue Mar 14 20:55:36 CDT 2017

Re: ntpd dies nightly on a server with jails

Hi O.Hartmann, I'll try to answer as much as I can in the noon hour I have left. In message <20170315071724.78bb0...@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > Running a host with several jails on recent CURRENT (12.0-CURRENT #8 r315187: > Sun Mar 12 11:22:38 CET 2017 amd64)

Re: fail world build

Hi, world is amd64-20170309-r314972 # ls /usr/include/pci ls: /usr/include/pci: No such file or directory Havent been able to buildworld since r314495 Thanks -R On Wed, Mar 15, 2017 at 11:57 PM, Manfred Antar wrote: > > > On Mar 15, 2017, at 4:44 PM, Roberto Rodriguez Jr < >

Re: fail world build

> On Mar 15, 2017, at 4:44 PM, Roberto Rodriguez Jr > wrote: > > Hey, > > r315336 > > --- pciconf.o --- > /usr/src/head/usr.sbin/pciconf/pciconf.c:703:3: error: use of > undeclared identifier 'PCIC_ACCEL' >{PCIC_ACCEL,-1,

Re: fail world build

Hey, r315336 --- pciconf.o --- /usr/src/head/usr.sbin/pciconf/pciconf.c:703:3: error: use of undeclared identifier 'PCIC_ACCEL' {PCIC_ACCEL,-1, "processing accelerators"}, ^ /usr/src/head/usr.sbin/pciconf/pciconf.c:704:3: error: use of undeclared

fail world build

Hello, buildkernel as of r315323 GOOD buildworld FAILS: /usr/src/head/usr.sbin/pciconf/pciconf.c:703:3: error: use of undeclared identifier 'PCIC_ACCEL' {PCIC_ACCEL,-1, "processing accelerators"}, ^ /usr/src/head/usr.sbin/pciconf/pciconf.c:704:3:

Re: Apparent build race(s), r315238 -> r315298

On Wed, Mar 15, 2017 at 03:40:42PM -0700, Ngie Cooper (yaneurabeya) wrote: > ... > > This should fix it: https://svnweb.freebsd.org/changeset/base/315332 > > > > Yeah, that would do it >_>… > Thanks, > -Ngie After hand-applying r315332 to a

Re: Apparent build race(s), r315238 -> r315298

> On Mar 15, 2017, at 2:19 PM, Bryan Drewery wrote: > > On 3/15/2017 2:10 PM, Bryan Drewery wrote: >> On 3/15/2017 11:23 AM, David Wolfskill wrote: >>> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote: ... So where is /common/S4/obj coming from?

Re: r314708: panic: Assertion err == 0 failed at /usr/src/sys/net/iflib.c:2241

On 3/9/2017 1:31 PM, Bryan Drewery wrote: > This came up at shutdown in r314708. I don't yet know if I will have a > core to diagnose. > >> panic: Assertion err == 0 failed at /usr/src/sys/net/iflib.c:2241 >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at

Re: Apparent build race(s), r315238 -> r315298

Ngie Cooper (yaneurabeya) wrote: > Alternatively, could you please revert just r313650 in another > branch/workspace (I wonder if changing from .OBJDIR to OBJTOP had some > unintended consequences that unrooted issues with how bmake evaluates paths)? The only change to

Re: Apparent build race(s), r315238 -> r315298

On 3/15/2017 2:10 PM, Bryan Drewery wrote: > On 3/15/2017 11:23 AM, David Wolfskill wrote: >> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote: >>> ... >>> So where is /common/S4/obj coming from? >>> >>> Is there a symlink involved here for /usr/obj? >>> >> >> Yes; I've had

Re: Apparent build race(s), r315238 -> r315298

On 3/15/2017 11:23 AM, David Wolfskill wrote: > On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote: >> ... >> So where is /common/S4/obj coming from? >> >> Is there a symlink involved here for /usr/obj? >> > > Yes; I've had /usr/obj as a symlink (to a different file system) for

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Something strange happened to the automatic CC: fill-in for my original reply. Also I should have mentioned that for my test program if a variant is made that does not fork the swapping works fine.] On 2017-Mar-15, at 9:37 AM, Mark Millard wrote: > On 2017-Mar-15, at 6:15 AM, Scott Bennett

Re: Apparent build race(s), r315238 -> r315298

> On Mar 15, 2017, at 11:24, Ngie Cooper (yaneurabeya) > wrote: > > >> On Mar 15, 2017, at 11:23, David Wolfskill wrote: >> >> On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote: >>> ... >>> So where is /common/S4/obj coming from? >>>

Re: Apparent build race(s), r315238 -> r315298

> On Mar 15, 2017, at 11:23, David Wolfskill wrote: > > On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote: >> ... >> So where is /common/S4/obj coming from? >> >> Is there a symlink involved here for /usr/obj? >> > > Yes; I've had /usr/obj as a symlink

Re: Apparent build race(s), r315238 -> r315298

On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote: > ... > So where is /common/S4/obj coming from? > > Is there a symlink involved here for /usr/obj? > Yes; I've had /usr/obj as a symlink (to a different file system) for ... a couple of decades, now Peace, david -- David

Re: Apparent build race(s), r315238 -> r315298

> On Mar 15, 2017, at 11:09, Bryan Drewery wrote: > > On 3/15/2017 10:04 AM, David Wolfskill wrote: > >> -- > stage 1.1: legacy release compatibility shims >>

Re: Apparent build race(s), r315238 -> r315298

On 3/15/2017 10:04 AM, David Wolfskill wrote: > -- stage 1.1: legacy release compatibility shims > -- > cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp Ok it is trying

Apparent build race(s), r315238 -> r315298

Both the biuld machine ("freebeast") and my laptop encountered errors during the "make -jN buildworld" -- each completed on restart, and the (initially-detected) errors were different: Build machine: ... ===> usr.bin/mkimg/tests (all) --- all_subdir_gnu --- Building

ntpd dies nightly on a server with jails

Running a host with several jails on recent CURRENT (12.0-CURRENT #8 r315187: Sun Mar 12 11:22:38 CET 2017 amd64) makes me trouble on a daily basis. The box is an older two-socket Fujitsu server equipted with two four-core Intel(R) Xeon(R) CPU L5420 @ 2.50GHz. The box has several jails, each