Re: netbsd-8 hang on tstile

2018-03-06 Thread Ryota Ozaki 
On Wed, Mar 7, 2018 at 7:33 AM, Manuel Bouyer  wrote:
> Hello
> on an up-to-date netbsd-8 Xen3 i386PAE kernel I see hangs on tstile.
> Hung processes shows the same pattern, they sleep in fstrans_start():
> sleepq_block(0,0,c0596900,c0639b6c,c534e802,40,c03dbcfe,75,c5356340,c534e800) 
> at netbsd:sleepq_block+0xe6
> turnstile_block(c59847f0,1,c078b6c0,c0639b6c,de8b9b70,c59847f0,c5db6020,c59a2008,0,c59a2008)
>  at netbsd:turnstile_block+0x29d
> mutex_vector_enter(c078b6c0,c0cb8fe0,c055570c,de8b9b84,c05349d7,c575ed04,1,c59a2008,de8b9ba4,c0493ff8)
>  at netbsd:mutex_vector_enter+0x28c
> fstrans_start(c59a2008,0,de8b9ba8,10,c055cf2c,c575ed04,20002,20002,c575ed04,0)
>  at netbsd:fstrans_start+0x3b6
> VOP_LOCK(c575ed04,20002,22000,0,c03dc2e7,c0746e1a,de8b9d0c,20002,c575ed04,de8b9c88)
>  at netbsd:VOP_LOCK+0x48
> vn_lock(c575ed04,20002,4,0,de8b9c14,c03af32d,de8b9edc,3,0,5) at 
> netbsd:vn_lock+0x7f
> namei_tryemulroot(0,c012a96a,c532c240,de8b9ce8,c041f909,c532c2b4,de8b9d0c,de8b9d34,0,0)
>  at netbsd:namei_tryemulroot+0x14f
> namei(de8b9d0c,1,3,de8b9d10,c042266a,0,c532c240,de8b9d20,c04211d6,0) at 
> netbsd:namei+0x27
> check_exec(c5db6020,de8b9dc8,c5f558a8,de8b9da4,9cf21000,de8b9dac,c0114f1a,bad054d0,de8b9ddc,bf7fef58)
>  at netbsd:check_exec+0x40
> execve_loadvm(bf7feab8,c03c95a0,de8b9dc8,c5a6f000,c6460c00,c700b008,404,0,0,0)
>  at netbsd:execve_loadvm+0x233
> execve1(c5db6020,bf7fef58,bad054d0,bf7feab8,c03c95a0,de8b9f9c,c0113572,c5db6020,
>  de8b9f68,de8b9f60) at netbsd:execve1+0x3c
> sys_execve(c5db6020,de8b9f68,de8b9f60,c63d8290,0,c0636ddc,de8b9f68,0,0,bf7fef58)
>  at netbsd:sys_execve+0x31
> syscall() at netbsd:syscall+0x82
>
> I guess the culprit is:
> 2650 1 3   2 0   c5f92a80  python2.7 psrlz
> (an anita process, actually)
> sleepq_block(1,0,c059af17,c0639f80,c0640804,c5356340,c5358a80,c063f93c,6406c2,c0
> 59af17) at netbsd:sleepq_block+0x1cd
> kpause(c059af17,0,1,0,c5448590,c5cec008,de5e7b5c,c048355a,c5330a28,de5e7b6c) 
> at
> n
> etbsd:kpause+0xf2
> pserialize_perform(c5330a28,de5e7b6c,c0484a6f,c638e8c0,0,c055cf2c,c5cec008,504,0,de5e7b7c)
>  at netbsd:pserialize_perform+0x10a
> fstrans_setstate(c5cec008,0,fffe,c0115914,c5cec008,c5cec008,de5e7b94,c047a2c0,c5cec008,2)
>  at netbsd:fstrans_setstate+0x3a
> genfs_suspendctl(c5cec008,2,de5e7bb0,de5e7bd4,de5e7bb0,c0483fc4,c5cec008,2,de5e7bd4,de5e7bd4)
>  at netbsd:genfs_suspendctl+0x3a
> VFS_SUSPENDCTL(c5cec008,2,de5e7bd4,de5e7bd4,504,de5e7be4,c0486fd6,c5cec008,504,0)
>  at netbsd:VFS_SUSPENDCTL+0x20
> vfs_resume(c5cec008,504,0,de5e7bd4,c011599f,4,c5cec008,c5e978e4,c5e978e4,c5f92a80)
>  at netbsd:vfs_resume+0x74
> vrevoke(c5e978e4,de5e7c14,c049370a,de5e7c04,0,0,c055d160,c5e978e4,1,0) at 
> netbsd:vrevoke+0x96
> genfs_revoke(de5e7c04,0,0,c055d160,c5e978e4,1,0,de5e7cc4,c044dea9,c5e978e4) 
> at netbsd:genfs_revoke+0x1a
> VOP_REVOKE(c5e978e4,1,c5353f00,504,0,74,c5e978e4,0,190,) at 
> netbsd:VOP_REVOKE+0x4a
> pty_grant_slave(c5f92a80,504,0,c5cec008,0,10,c055cf2c,c5c271bc,20002,20002) 
> at netbsd:pty_grant_slave+0xc9
> ptmioctl(a501,0,48087446,c6922008,3,c5f92a80,c5f92a80,48087446,c055c260,3) at 
> netbsd:ptmioctl+0xdd
> cdev_ioctl(a501,0,48087446,c6922008,3,c5f92a80,a501,c5c271bc,c5c271bc,c5fd22c0)
>  at netbsd:cdev_ioctl+0xd0
> spec_ioctl(de5e7da0,c0115914,c5df9bc0,c055d1f0,c5c271bc,48087446,c6922008,3,c5eac9c0,48087446)
>  at netbsd:spec_ioctl+0x90
> VOP_IOCTL(c5c271bc,48087446,c6922008,3,c5eac9c0,c5e74380,c6fbe790,fffe,c0115914,0)
>  at netbsd:VOP_IOCTL+0x3e
> vn_ioctl(c5fd22c0,48087446,c6922008,c5f8eb74,c5fd22c0,,,0,0,c6922008)
>  at netbsd:vn_ioctl+0x9f
> sys_ioctl(c5f92a80,de5e7f68,de5e7f60,c63d8788,0,c0636d78,de5e7f68,0,0,7) at 
> netbsd:sys_ioctl+0x10a
> syscall() at netbsd:syscall+0x82
>
> This is reproductible, restarting my automatic test script hangs the same
> way. This i plain ffs, no wapbl.
>
> Any idea ?

pserialize_perform can get stuck if any softints get stuck. Can you check
if such softints exist?

  ozaki-r

npf in -current amd64 (7 Mar 2018) now cannot use a "ruleset" multiple times

2018-03-06 Thread Geoff Wing 
Hi,
npf previously had no issues using a "ruleset" in multiple groups, however
it now has a problem and fails with

npfctl: (re)load failed: some table has a duplicate entry?

The following is a minimal npf.conf to illustrate with it failing due to
the second ``ruleset "blacklistd"'' causing the issue:
-
$if1_if = inet4(vmx0)
$if2_if = inet4(vmx1)

alg "icmp"

group "foo" on $if1_if {
ruleset "blacklistd"
}
group "bar" on $if2_if {
ruleset "blacklistd"
}

group default {
pass final on lo0 all
block all
}
-

I haven't investigated further yet.  Ring any bells with anyone?

System is amd64 -current.

Regards,
Geoff

daily CVS update output

2018-03-06 Thread NetBSD source update 

Updating src tree:
P src/crypto/external/bsd/openssl/dist/crypto/bn/asm/mips.pl
P src/crypto/external/bsd/openssl/dist/crypto/modes/gcm128.c
P src/crypto/external/bsd/openssl/lib/libcrypto/arch/arm/crypto.inc
U src/crypto/external/bsd/openssl/lib/libcrypto/arch/hppa/crypto.inc
U src/crypto/external/bsd/openssl/lib/libcrypto/arch/ia64/crypto.inc
P src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/mips64.S
P src/external/bsd/cron/dist/crontab.c
P src/sys/arch/aarch64/include/armreg.h
P src/sys/arch/amiga/conf/files.amiga
P src/sys/arch/emips/stand/common/devopen.c
P src/sys/arch/zaurus/conf/files.zaurus
P src/sys/compat/netbsd32/netbsd32_ioctl.c
P src/sys/compat/netbsd32/netbsd32_ioctl.h
P src/sys/dev/fdt/fdt_regulator.c
P src/sys/dev/fdt/fdt_subr.c
P src/sys/dev/pci/ixgbe/ixgbe.h
P src/sys/dev/sdmmc/sdmmc.c
P src/sys/dev/wsfb/genfb.c
P src/sys/net/if_llatbl.c
P src/sys/net/if_llatbl.h
P src/sys/netinet/icmp6.h
P src/sys/netinet/if_arp.c
P src/sys/netinet/in.c
P src/sys/netinet6/in6.c
P src/sys/netinet6/ip6_input.c
P src/sys/netinet6/nd6.c
P src/sys/netinet6/nd6.h
P src/sys/netinet6/nd6_nbr.c
P src/sys/netipsec/ipsecif.c
P src/tests/lib/libc/sys/t_ptrace_x86_wait.h
P src/tests/net/ndp/t_dad.sh
P src/usr.bin/tail/tail.c
P src/usr.sbin/dumpfs/dumpfs.c

Updating xsrc tree:


Killing core files:



Updating release-6 src tree (netbsd-6):

Updating release-6 xsrc tree (netbsd-6):



Updating release-7 src tree (netbsd-7):
U doc/CHANGES-7.2
P sys/arch/mips/mips/cache.c

Updating release-7 xsrc tree (netbsd-7):



Updating release-8 src tree (netbsd-8):
P doc/CHANGES
U doc/CHANGES-8.0
P lib/libc/sys/ptrace.2
P sys/arch/amd64/conf/kern.ldscript
P sys/arch/amd64/conf/kern.ldscript.Xen
P sys/arch/i386/conf/kern.ldscript
P sys/arch/i386/conf/kern.ldscript.Xen
P sys/arch/mips/mips/cache.c
P sys/arch/x86/include/cpufunc.h
P sys/arch/x86/x86/patch.c
P sys/arch/x86/x86/pmap.c
P sys/dev/pci/if_wm.c
P sys/dev/pci/ixgbe/ix_txrx.c
P sys/dev/pci/ixgbe/ixgbe.c
P sys/dev/pci/ixgbe/ixgbe.h
P sys/dev/pci/ixgbe/ixv.c
P sys/kern/sys_ptrace_common.c
P sys/netipsec/ipsec_input.c
P sys/netipsec/ipsecif.c
P sys/sys/ptrace.h
P tests/lib/libc/sys/t_ptrace_wait.c
P usr.bin/vmstat/vmstat.c

Updating release-8 xsrc tree (netbsd-8):




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  50295277 Mar  7 03:11 ls-lRA.gz

netbsd-8 hang on tstile

2018-03-06 Thread Manuel Bouyer 
Hello
on an up-to-date netbsd-8 Xen3 i386PAE kernel I see hangs on tstile.
Hung processes shows the same pattern, they sleep in fstrans_start():
sleepq_block(0,0,c0596900,c0639b6c,c534e802,40,c03dbcfe,75,c5356340,c534e800) 
at netbsd:sleepq_block+0xe6
turnstile_block(c59847f0,1,c078b6c0,c0639b6c,de8b9b70,c59847f0,c5db6020,c59a2008,0,c59a2008)
 at netbsd:turnstile_block+0x29d
mutex_vector_enter(c078b6c0,c0cb8fe0,c055570c,de8b9b84,c05349d7,c575ed04,1,c59a2008,de8b9ba4,c0493ff8)
 at netbsd:mutex_vector_enter+0x28c
fstrans_start(c59a2008,0,de8b9ba8,10,c055cf2c,c575ed04,20002,20002,c575ed04,0) 
at netbsd:fstrans_start+0x3b6
VOP_LOCK(c575ed04,20002,22000,0,c03dc2e7,c0746e1a,de8b9d0c,20002,c575ed04,de8b9c88)
 at netbsd:VOP_LOCK+0x48
vn_lock(c575ed04,20002,4,0,de8b9c14,c03af32d,de8b9edc,3,0,5) at 
netbsd:vn_lock+0x7f
namei_tryemulroot(0,c012a96a,c532c240,de8b9ce8,c041f909,c532c2b4,de8b9d0c,de8b9d34,0,0)
 at netbsd:namei_tryemulroot+0x14f
namei(de8b9d0c,1,3,de8b9d10,c042266a,0,c532c240,de8b9d20,c04211d6,0) at 
netbsd:namei+0x27
check_exec(c5db6020,de8b9dc8,c5f558a8,de8b9da4,9cf21000,de8b9dac,c0114f1a,bad054d0,de8b9ddc,bf7fef58)
 at netbsd:check_exec+0x40
execve_loadvm(bf7feab8,c03c95a0,de8b9dc8,c5a6f000,c6460c00,c700b008,404,0,0,0) 
at netbsd:execve_loadvm+0x233
execve1(c5db6020,bf7fef58,bad054d0,bf7feab8,c03c95a0,de8b9f9c,c0113572,c5db6020,
 de8b9f68,de8b9f60) at netbsd:execve1+0x3c
sys_execve(c5db6020,de8b9f68,de8b9f60,c63d8290,0,c0636ddc,de8b9f68,0,0,bf7fef58)
 at netbsd:sys_execve+0x31
syscall() at netbsd:syscall+0x82

I guess the culprit is:
2650 1 3   2 0   c5f92a80  python2.7 psrlz
(an anita process, actually)
sleepq_block(1,0,c059af17,c0639f80,c0640804,c5356340,c5358a80,c063f93c,6406c2,c0
59af17) at netbsd:sleepq_block+0x1cd
kpause(c059af17,0,1,0,c5448590,c5cec008,de5e7b5c,c048355a,c5330a28,de5e7b6c) at 
n
etbsd:kpause+0xf2
pserialize_perform(c5330a28,de5e7b6c,c0484a6f,c638e8c0,0,c055cf2c,c5cec008,504,0,de5e7b7c)
 at netbsd:pserialize_perform+0x10a
fstrans_setstate(c5cec008,0,fffe,c0115914,c5cec008,c5cec008,de5e7b94,c047a2c0,c5cec008,2)
 at netbsd:fstrans_setstate+0x3a
genfs_suspendctl(c5cec008,2,de5e7bb0,de5e7bd4,de5e7bb0,c0483fc4,c5cec008,2,de5e7bd4,de5e7bd4)
 at netbsd:genfs_suspendctl+0x3a
VFS_SUSPENDCTL(c5cec008,2,de5e7bd4,de5e7bd4,504,de5e7be4,c0486fd6,c5cec008,504,0)
 at netbsd:VFS_SUSPENDCTL+0x20
vfs_resume(c5cec008,504,0,de5e7bd4,c011599f,4,c5cec008,c5e978e4,c5e978e4,c5f92a80)
 at netbsd:vfs_resume+0x74
vrevoke(c5e978e4,de5e7c14,c049370a,de5e7c04,0,0,c055d160,c5e978e4,1,0) at 
netbsd:vrevoke+0x96
genfs_revoke(de5e7c04,0,0,c055d160,c5e978e4,1,0,de5e7cc4,c044dea9,c5e978e4) at 
netbsd:genfs_revoke+0x1a
VOP_REVOKE(c5e978e4,1,c5353f00,504,0,74,c5e978e4,0,190,) at 
netbsd:VOP_REVOKE+0x4a
pty_grant_slave(c5f92a80,504,0,c5cec008,0,10,c055cf2c,c5c271bc,20002,20002) at 
netbsd:pty_grant_slave+0xc9
ptmioctl(a501,0,48087446,c6922008,3,c5f92a80,c5f92a80,48087446,c055c260,3) at 
netbsd:ptmioctl+0xdd
cdev_ioctl(a501,0,48087446,c6922008,3,c5f92a80,a501,c5c271bc,c5c271bc,c5fd22c0) 
at netbsd:cdev_ioctl+0xd0
spec_ioctl(de5e7da0,c0115914,c5df9bc0,c055d1f0,c5c271bc,48087446,c6922008,3,c5eac9c0,48087446)
 at netbsd:spec_ioctl+0x90
VOP_IOCTL(c5c271bc,48087446,c6922008,3,c5eac9c0,c5e74380,c6fbe790,fffe,c0115914,0)
 at netbsd:VOP_IOCTL+0x3e
vn_ioctl(c5fd22c0,48087446,c6922008,c5f8eb74,c5fd22c0,,,0,0,c6922008)
 at netbsd:vn_ioctl+0x9f
sys_ioctl(c5f92a80,de5e7f68,de5e7f60,c63d8788,0,c0636d78,de5e7f68,0,0,7) at 
netbsd:sys_ioctl+0x10a
syscall() at netbsd:syscall+0x82

This is reproductible, restarting my automatic test script hangs the same
way. This i plain ffs, no wapbl.

Any idea ?

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: Automated report: NetBSD-current/i386 build success

2018-03-06 Thread Andreas Gustafsson 
Robert Elz wrote:
> However, after his fix, the build failed again in a way I have observed in 
> the 
> b5 builds a few times recently (Christos' openssl changes did not fix this 
> one 
> either).

Looks like it has happened four times so far:

babylon5.netbsd.org$ cd /bracket && zgrep 'md.*non-void function' 
*/results/2018/*/build.log.tail.gz
amd64/results/2018/2018.02.20.12.49.40/build.log.tail.gz:/tmp/bracket/build/2018.02.20.12.49.40-amd64/src/external/gpl3/gcc/dist/gcc/config/i386/sse.md:25072:96:
 error: control reaches end of non-void function [-Werror=return-type]
i386/results/2018/2018.02.23.19.39.27/build.log.tail.gz:/tmp/bracket/build/2018.02.23.19.39.27-i386/src/external/gpl3/gcc/dist/gcc/config/i386/i386.md:59811:66:
 error: control reaches end of non-void function [-Werror=return-type]
i386/results/2018/2018.03.02.14.45.23/build.log.tail.gz:/tmp/bracket/build/2018.03.02.14.45.23-i386/src/external/gpl3/gcc/dist/gcc/config/i386/i386.md:24745:32:
 error: control reaches end of non-void function [-Werror=return-type]
i386/results/2018/2018.03.06.11.21.31/build.log.tail.gz:/tmp/bracket/build/2018.03.06.11.21.31-i386/src/external/gpl3/gcc/dist/gcc/config/i386/sse.md:24127:47:
 error: control reaches end of non-void function [-Werror=return-type]

> I believe all the b5 builds start with clean objdirs.

That is correct.

> Does anyone who understands the gcc build process have any idea what
> might be happening there?

I don't, and I would also like to know...
-- 
Andreas Gustafsson, g...@gson.org

Re: Automated report: NetBSD-current/i386 build success

2018-03-06 Thread Robert Elz 
Date:Tue,  6 Mar 2018 17:08:40 + (UTC)
From:NetBSD Test Fixture 
Message-ID:  <152035611931.24762.16467812075534166...@babylon5.netbsd.org>

  | The NetBSD-current/i386 build is working again.
  |
  | The following commits were made between the last failed build and the
  | successful build:
  |
  | 2018.03.06.13.37.43 christos src/crypto/external/bsd/openssl/lib/ ...   
 [2 of them]

Perhaps needless to say that Christos' openssl commits did not fix the INET6 nd
bug reported in the "build failure" automated report mail - that was fixed 
(just before that report actualy) by Martin.

However, after his fix, the build failed again in a way I have observed in the 
b5 builds a few times recently (Christos' openssl changes did not fix this one 
either).

It is a gcc related compile error (I mean, compiling gcc) ...

--- dependall-gpl3 ---
/tmp/bracket/build/2018.03.06.11.21.31-i386/src/external/gpl3/gcc/dist/gcc/config/i386/sse.md:24127:47:
 error: control reaches end of non-void function [-Werror=return-type]
cc1plus: all warnings being treated as errors
*** [insn-latencytab.o] Error code 1
nbmake[9]: stopped in 
/tmp/bracket/build/2018.03.06.11.21.31-i386/src/external/gpl3/gcc/usr.bin/backend

This one seems to be non-deterministic - it comes and goes, which to me 
suggests something related to the parallel builds - or perhaps to the build
aborting from the previous run (due to some other error, the nd6 one in this
instance) leaving something "half done" in the gcc build, causing a subsequest
build to fail (but probably not, as I believe all the b5 builds start with 
clean 
objdirs.)

Does anyone who understands the gcc build process have any idea what
might be happening there?

What causes this to fail (always the same way, as best I can tell) sometimes,
and with no apparent related changes, be OK in a later build attempt?

kre

Re: Panic on acorn32 current

2018-03-06 Thread Mike Pumford 



On 04/03/2018 17:09, Mike Pumford wrote:

Finally had some time to bring my system up to date and found a problem.

Got a panic at start of day (transcribed from a shot of the screen):
fdc0 at pioc0 offset 0x3f0-0x3f7 irq12 drq 0x2000


Now raised as port-acorn32/53076

Mike

Automated report: NetBSD-current/i386 build success

2018-03-06 Thread NetBSD Test Fixture 
The NetBSD-current/i386 build is working again.

The following commits were made between the last failed build and the
successful build:

2018.03.06.13.37.43 christos 
src/crypto/external/bsd/openssl/lib/libcrypto/arch/arm/crypto.inc,v 1.8
2018.03.06.13.47.25 christos 
src/crypto/external/bsd/openssl/lib/libcrypto/arch/mips/mips64.S,v 1.2

Log files can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2018.03.html#2018.03.06.13.47.25

Automated report: NetBSD-current/i386 build failure

2018-03-06 Thread NetBSD Test Fixture 
This is an automatically generated notice of a NetBSD-current/i386
build failure.

The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2018.03.06.10.57.00.

An extract from the build.sh output follows:

/tmp/bracket/build/2018.03.06.10.57.00-i386/tools/bin/nbctfconvert -g -L 
VERSION mpls_proto.o

/tmp/bracket/build/2018.03.06.10.57.00-i386/tools/bin/i486--netbsdelf-objcopy 
-x  mpls_proto.o
--- raw_usrreq.po ---
#   compile  libnet/raw_usrreq.po
--- rtsock.po ---
/common/include 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../include
 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../include/opt
 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../../arch
 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../..
 -DDIAGNOSTIC -DKTRACE  -DINET -DPORTALGO_INET4_DEFAULT=PORTALGO_RANDOM_START 
-DIPSEC -DINET6 -DPORTALGO_INET6_DEFAULT=PORTALGO_RANDOM_START -DIPSEC  
-D_FORTIFY_SOURCE=2 -c -DGPROF -DPROF-pg 
/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../../net/rtsock.c
 -o rtsock.po
--- raw_usrreq.po ---
/tmp/bracket/build/2018.03.06.10.57.00-i386/tools/bin/i486--netbsdelf-gcc 
-O2  -fno-delete-null-pointer-checks  -ffreestanding -fno-strict-aliasing 
-msoft-float -mno-mmx -mno-sse -mno-avx -msoft-float -mno-mmx -mno-sse -mno-avx 
  -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-sign-compare  -Wsystem-headers   -Wno-traditional   -Wa,--fatal-warnings  
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra 
-Wno-unused-parameter -Wno-sign-compare -Werror -Wno-format-zero-length 
-Wno-pointer-sign   -fPIE -fstack-protector -Wstack-protector   --param 
ssp-buffer-size=1
--sysroot=/tmp/bracket/build/2018.03.06.10.57.00-i386/destdir -DCOMPAT_50 
-DCOMPAT_60 -DCOMPAT_70 -DCOMPAT_80 -nostdinc -imacros 
/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../include/opt/opt_rumpkernel.h
 -I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet -I. 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump
 /net/lib/libnet/../../../../..--- raw_cb.po ---
--- ip6_mroute.o ---
/tmp/bracket/build/2018.03.06.10.57.00-i386/tools/bin/nbctfconvert -g -L 
VERSION ip6_mroute.o
--- raw_usrreq.po ---
/common/include 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../include
 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../include/opt
 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../../arch
 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../..
 -DDIAGNOSTIC -DKTRACE  -DINET -DPORTALGO_INET4_DEFAULT=PORTALGO_RANDOM_START 
-DIPSEC -DINET6 -DPORTALGO_INET6_DEFAULT=PORTALGO_RANDOM_START -DIPSEC  
-D_FORTIFY_SOURCE=2 -c -DGPROF -DPROF-pg 
/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../../net/raw_usrreq.c
 -o raw_usrreq.po
--- raw_cb.po ---
#   compile  libnet/raw_cb.po
/tmp/bracket/build/2018.03.06.10.57.00-i386/tools/bin/i486--netbsdelf-gcc 
-O2  -fno-delete-null-pointer-checks  -ffreestanding -fno-strict-aliasing 
-msoft-float -mno-mmx -mno-sse -mno-avx -msoft-float -mno-mmx -mno-sse -mno-avx 
  -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-sign-compare  -Wsystem-headers   -Wno-traditional   -Wa,--fatal-warnings  
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra 
-Wno-unused-parameter -Wno-sign-compare -Werror -Wno-format-zero-length 
-Wno-pointer-sign   -fPIE -fstack-protector -Wstack-protector   --param 
ssp-buffer-size=1
--sysroot=/tmp/bracket/build/2018.03.06.10.57.00-i386/destdir -DCOMPAT_50 
-DCOMPAT_60 -DCOMPAT_70 -DCOMPAT_80 -nostdinc -imacros 
/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../include/opt/opt_rumpkernel.h
 -I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet -I. 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump
 /net/lib/libnet/../../../../../common/include 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../include
 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../include/opt
 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../../arch
 
-I/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../..
 -DDIAGNOSTIC -DKTRACE  -DINET -DPORTALGO_INET4_DEFAULT=PORTALGO_RANDOM_START 
-DIPSEC -DINET6 -DPORTALGO_INET6_DEFAULT=PORTALGO_RANDOM_START -DIPSEC  
-D_FORTIFY_SOURCE=2 -c -DGPROF -DPROF-pg 
/tmp/bracket/build/2018.03.06.10.57.00-i386/src/sys/rump/net/lib/libnet/../../../../net/raw_cb.c
 -o raw_cb.po
--- ip6_mroute.o ---