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 r...@borg.lerctr

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 < > rob.rodz@gmail

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, "processing > accelerators"}, >

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 i

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 hea

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? Is there a symli

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 db_trace_self_wrapper+0x

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 dir handling in recent bm

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 /usr/o

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 wro

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? >>> >>> Is there a symlink involved here for /usr

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 (to a different file sys

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 H.

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 >> -- >> cd /us

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 /common/S4/obj/usr/src/gnu/usr.