daily CVS update output

2016-08-12 Thread NetBSD source update 

Updating src tree:
P src/bin/test/test.1
P src/external/mit/xorg/server/xorg-server/hw/xfree86/Xorg/Makefile
P src/lib/libc/arch/mips/genassym.cf
P src/lib/libc/arch/mips/gen/_resumecontext.S
P src/lib/libc/arch/mips/sys/getcontext.S
P src/sys/arch/zaurus/conf/INSTALL
P src/sys/arch/zaurus/conf/INSTALL_C700
P src/sys/modules/ext2fs/Makefile
P src/sys/netinet/sctp_crc32.c
P src/sys/netinet6/scope6.c
P src/sys/rump/fs/lib/libext2fs/Makefile
P src/sys/rump/net/lib/libnetinet/netinet_component.c
P src/sys/rump/net/lib/libnetinet6/netinet6_component.c
P src/sys/ufs/files.ufs
P src/sys/ufs/ext2fs/ext2fs.h
P src/sys/ufs/ext2fs/ext2fs_dinode.h
P src/sys/ufs/ext2fs/ext2fs_vnops.c
U src/sys/ufs/ext2fs/ext2fs_xattr.c
U src/sys/ufs/ext2fs/ext2fs_xattr.h
P src/sys/uvm/files.uvm
P src/usr.sbin/dumplfs/dumplfs.c

Updating xsrc tree:


Killing core files:


Updating tar files:
src/top-level: collecting... replacing... done
src/bin: collecting... replacing... done
src/common: collecting... replacing... done
src/compat: collecting... replacing... done
src/crypto: collecting... replacing... done
src/dist: collecting... replacing... done
src/distrib: collecting... replacing... done
src/doc: collecting... replacing... done
src/etc: collecting... replacing... done
src/external: collecting... replacing... done
src/extsrc: collecting... replacing... done
src/games: collecting... replacing... done
src/gnu: collecting... replacing... done
src/include: collecting... replacing... done
src/lib: collecting... replacing... done
src/libexec: collecting... replacing... done
src/regress: collecting... replacing... done
src/rescue: collecting... replacing... done
src/sbin: collecting... replacing... done
src/share: collecting... replacing... done
src/sys: collecting... replacing... done
src/tests: collecting... replacing... done
src/tools: collecting... replacing... done
src/usr.bin: collecting... replacing... done
src/usr.sbin: collecting... replacing... done
src/config: collecting... replacing... done
src: collecting... replacing... done
xsrc/top-level: collecting... replacing... done
xsrc/external: collecting... replacing... done
xsrc/local: collecting... replacing... done
xsrc: collecting... replacing... done

Running the SUP scanner:
SUP Scan for current starting at Sat Aug 13 03:09:04 2016
SUP Scan for current completed at Sat Aug 13 03:09:19 2016
SUP Scan for mirror starting at Sat Aug 13 03:09:19 2016
SUP Scan for mirror completed at Sat Aug 13 03:11:34 2016



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

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


Updating release-6 tar files:
src/top-level: collecting... replacing... done
src/bin: collecting... replacing... done
src/common: collecting... replacing... done
src/compat: collecting... replacing... done
src/crypto: collecting... replacing... done
src/dist: collecting... replacing... done
src/distrib: collecting... replacing... done
src/doc: collecting... replacing... done
src/etc: collecting... replacing... done
src/external: collecting... replacing... done
src/extsrc: collecting... replacing... done
src/games: collecting... replacing... done
src/gnu: collecting... replacing... done
src/include: collecting... replacing... done
src/lib: collecting... replacing... done
src/libexec: collecting... replacing... done
src/regress: collecting... replacing... done
src/rescue: collecting... replacing... done
src/sbin: collecting... replacing... done
src/share: collecting... replacing... done
src/sys: collecting... replacing... done
src/tests: collecting... replacing... done
src/tools: collecting... replacing... done
src/usr.bin: collecting... replacing... done
src/usr.sbin: collecting... replacing... done
src/config: collecting... replacing... done
src/x11: collecting... replacing... done
xsrc/top-level: collecting... replacing... done
xsrc/external: collecting... replacing... done
xsrc/local: collecting... replacing... done
xsrc/xfree: collecting... replacing... done

Running the SUP scanner:
SUP Scan for release-6 starting at Sat Aug 13 03:16:55 2016
SUP Scan for release-6 completed at Sat Aug 13 03:17:05 2016



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

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


Updating release-7 tar files:
src/top-level: collecting... replacing... done
src/bin: collecting... replacing... done
src/common: collecting... replacing... done
src/compat: collecting... replacing... done
src/crypto: collecting... replacing... done
src/dist: collecting... replacing... done
src/distrib: collecting... replacing... done
src/doc: collecting... replacing... done
src/etc: collecting... replacing... done
src/external: collecting... replacing... done
src/extsrc: collecting... replacing... done
src/games: collecting... replacing... done
src/gnu: collecting... replacing... done
src/include: collecting... replacing... done
src/lib: collecting... replacing... done
src/libexec: collecting... replacing... done
src/regress: collecting... replacing... done
src/rescue: collecting... replacing... done

Re: Building on OS X - how?

2016-08-12 Thread Michael Plass 
On Aug 12, 2016, at 6:44 PM, Michael Plass wrote:

> The config.status for host-libcpp is at 
> https://gist.github.com/mfplass/6a75e12339bc97223854953fee1fa9fc

And the relevant diffs with the working (in-jail) build is

619,620c619,620
< S["LTLIBICONV"]="-L/usr/local/lib -liconv -R/usr/local/lib"
< S["LIBICONV"]="/usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib"
---
> S["LTLIBICONV"]=""
> S["LIBICONV"]=""
656c656
< S["CPPFLAGS"]="-I/usr/local/include"
---
> S["CPPFLAGS"]=""

so maybe the linker flags for LIBICONV aren't getting pulled in where they 
should be?

Re: Building on OS X - how?

2016-08-12 Thread Michael Plass 
On Aug 12, 2016, at 12:54 PM, matthew green wrote:

> Thor Lancelot Simon writes:
>> On Thu, Aug 11, 2016 at 04:05:06PM +0100, Robert Swindells wrote:
>>> 
 2) /usr/bin/cc:
   Undefined symbols for architecture x86_64: "_iconv"
   in external/gpl3/gcc/usr.bin/backend
>>> 
>>> This should be in libc.
>> 
>> For what value of "should"?  _iconv is in the implementation-defined
>> namespace.
>> 
>> It's curious that this doesn't break the tools build, and doesn't
>> prevent using the built tools to build a kernel!  If this can break
>> the cross-build of the target compiler, I think we must have suddenly
>> sprouted a rather serious instance of host/target confusion.
> 
> this fails building the native gcc, which requires a bunch of host
> tools to run.  going on your following post, there is a problem
> with genmatch.  i don't have access to any osx to test, so i'm not
> sure where to start looking.  there aren't too many rules used in
> the creation of "genmatch" binary - can you run "make cleandir"
> in usr.bin/backend/ and then "make MAKEVERBOSE=2 genmatch", and
> post all the commands run?  there probably will be a configure
> run in here, and perhaps the output of it also matters.
> 
> 
> .mrg.
> 
> 

I still have a log from the maybe-similar failure on freebsd:

https://gist.github.com/mfplass/98801ea2ab2cd3d5abd92faa3c47ab1c

It, too, is trying to build genmatch.

The config.status for host-libcpp is at 
https://gist.github.com/mfplass/6a75e12339bc97223854953fee1fa9fc

- Michael

Automated report: NetBSD-current/i386 build success

2016-08-12 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:

2016.08.12.20.25.34 martin src/sys/rump/fs/lib/libext2fs/Makefile,v 1.8
2016.08.12.20.26.15 macallan src/sys/ufs/ext2fs/ext2fs.h,v 1.43
2016.08.12.20.30.15 macallan src/sys/ufs/ext2fs/ext2fs_xattr.h,v 1.2

Log files can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2016.08.html#2016.08.12.20.30.15

Automated report: NetBSD-current/i386 build failure

2016-08-12 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 2016.08.12.19.08.54.

An extract from the build.sh output follows:

--- dependall-tests ---

/tmp/bracket/build/2016.08.12.19.08.54-i386/destdir/usr/lib/librumpfs_ext2fs.so:
 undefined reference to `rumpns_ext2fs_setextattr'

/tmp/bracket/build/2016.08.12.19.08.54-i386/destdir/usr/lib/librumpfs_ext2fs.so:
 undefined reference to `rumpns_ext2fs_listextattr'

/tmp/bracket/build/2016.08.12.19.08.54-i386/destdir/usr/lib/librumpfs_ext2fs.so:
 undefined reference to `rumpns_ext2fs_deleteextattr'

/tmp/bracket/build/2016.08.12.19.08.54-i386/destdir/usr/lib/librumpfs_ext2fs.so:
 undefined reference to `rumpns_ext2fs_getextattr'
collect2: error: ld returned 1 exit status
*** [t_full] Error code 1
nbmake[8]: stopped in 
/tmp/bracket/build/2016.08.12.19.08.54-i386/src/tests/fs/vfs
1 error

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

2016.08.12.19.04.03 jdolecek src/sys/ufs/ext2fs/ext2fs.h,v 1.42
2016.08.12.19.04.03 jdolecek src/sys/ufs/ext2fs/ext2fs_dinode.h,v 1.36
2016.08.12.19.04.03 jdolecek src/sys/ufs/ext2fs/ext2fs_vnops.c,v 1.121
2016.08.12.19.04.03 jdolecek src/sys/ufs/ext2fs/ext2fs_xattr.c,v 1.1
2016.08.12.19.04.03 jdolecek src/sys/ufs/ext2fs/ext2fs_xattr.h,v 1.1
2016.08.12.19.04.03 jdolecek src/sys/ufs/files.ufs,v 1.43
2016.08.12.19.07.14 jdolecek src/sys/modules/ext2fs/Makefile,v 1.5
2016.08.12.19.08.54 jdolecek src/sys/netinet/sctp_crc32.c,v 1.2

Log files can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2016.08.html#2016.08.12.19.08.54

re: Building on OS X - how?

2016-08-12 Thread matthew green 
Thor Lancelot Simon writes:
> On Thu, Aug 11, 2016 at 04:05:06PM +0100, Robert Swindells wrote:
> > 
> > >2) /usr/bin/cc:
> > >Undefined symbols for architecture x86_64: "_iconv"
> > >in external/gpl3/gcc/usr.bin/backend
> > 
> > This should be in libc.
> 
> For what value of "should"?  _iconv is in the implementation-defined
> namespace.
> 
> It's curious that this doesn't break the tools build, and doesn't
> prevent using the built tools to build a kernel!  If this can break
> the cross-build of the target compiler, I think we must have suddenly
> sprouted a rather serious instance of host/target confusion.

this fails building the native gcc, which requires a bunch of host
tools to run.  going on your following post, there is a problem
with genmatch.  i don't have access to any osx to test, so i'm not
sure where to start looking.  there aren't too many rules used in
the creation of "genmatch" binary - can you run "make cleandir"
in usr.bin/backend/ and then "make MAKEVERBOSE=2 genmatch", and
post all the commands run?  there probably will be a configure
run in here, and perhaps the output of it also matters.


.mrg.

Re: Mangled file system directory panic

2016-08-12 Thread Christos Zoulas 
On Aug 12,  6:51pm, ja...@uninett.no (Jarle Greipsland) wrote:
-- Subject: Re: Mangled file system directory panic

| chris...@astron.com (Christos Zoulas) writes:
| > In article <20160811.153708.78150616.ja...@uninett.no>,
| > Jarle Greipsland   wrote:
| >>> The panic messages reported by crash is something like:
| >>> System panicked: /mnt: bad dir ino 42369 at offset 560: NUL in name []
| >>i=0, namlen=4
| [ ... ]
| >>I have since managed to pin-point where things started to go
| >>wrong -- CVS commit-wise.  A -current kernel from CVS with tag
| >>'2016.04.03.03.00.00' works just fine, while a kernel with tag
| >>'2016.04.03.07.00.00' panics.  The only significant commit in
| >>that interval is a change of compiler for the i386 port to GCC
| >>5.3 (http://mail-index.netbsd.org/source-changes/2016/04/03/msg073782.html).
| >>
| >>Are there known bugs in our compiler for (plain) i486 systems?
| >>
| > 
| > Please try compiling ufs_lookup.c with -O0...
| I have now tried a kernel with the following lines in the config
| file:
| makeoptions CPUFLAGS="-march=i486 -fno-tree-vrp"
| makeoptions "CPUFLAGS.ufs_lookup.c"+="-O0"
| makeoptions DEBUG="-g"  # compile full symbol table
| 
| It still panics.

Thanks! We are back to the drawing board on this one. The way I debugged
this the last time is by having 2 object directories compiled with the two
different compilers, and bisecting the working and the non-working object
files until I found the guilty one.

christos

Re: Mangled file system directory panic

2016-08-12 Thread Jarle Greipsland 
chris...@astron.com (Christos Zoulas) writes:
> In article <20160811.153708.78150616.ja...@uninett.no>,
> Jarle Greipsland   wrote:
>>> The panic messages reported by crash is something like:
>>> System panicked: /mnt: bad dir ino 42369 at offset 560: NUL in name []
>>i=0, namlen=4
[ ... ]
>>I have since managed to pin-point where things started to go
>>wrong -- CVS commit-wise.  A -current kernel from CVS with tag
>>'2016.04.03.03.00.00' works just fine, while a kernel with tag
>>'2016.04.03.07.00.00' panics.  The only significant commit in
>>that interval is a change of compiler for the i386 port to GCC
>>5.3 (http://mail-index.netbsd.org/source-changes/2016/04/03/msg073782.html).
>>
>>Are there known bugs in our compiler for (plain) i486 systems?
>>
> 
> Please try compiling ufs_lookup.c with -O0...
I have now tried a kernel with the following lines in the config
file:
makeoptions CPUFLAGS="-march=i486 -fno-tree-vrp"
makeoptions "CPUFLAGS.ufs_lookup.c"+="-O0"
makeoptions DEBUG="-g"  # compile full symbol table

It still panics.
-jarle
-- 
"I remarked to Dennis that easily half the code I was writing in Multics was
 error recovery code. He said, "We left all that stuff out. If there's an
 error, we have this routine called panic, and when it is called, the machine
 crashes, and you holler down the hall, 'Hey, reboot it.'"
   Tom van Vleck and Dennis Ritchie about Multics <-> UNIX relationship

Re: Mangled file system directory panic

2016-08-12 Thread Jarle Greipsland 
co...@sdf.org writes:
> On Thu, Aug 11, 2016 at 03:37:08PM +0200, Jarle Greipsland wrote:
>> [ Followups to port-i386, please ]
>> I wrote[1]:
>> > I have a system where I can almost deterministally provoke a
>> > kernel panic by doing a 'tar -zxpf comp.tgz'.
>> > 
>> > The panic messages reported by crash is something like:
>> > System panicked: /mnt: bad dir ino 42369 at offset 560: NUL in name [] 
>> > i=0, namlen=4
[ ... ]
>> I have since managed to pin-point where things started to go
>> wrong -- CVS commit-wise.  A -current kernel from CVS with tag
>> '2016.04.03.03.00.00' works just fine, while a kernel with tag
>> '2016.04.03.07.00.00' panics.  The only significant commit in
>> that interval is a change of compiler for the i386 port to GCC
>> 5.3 (http://mail-index.netbsd.org/source-changes/2016/04/03/msg073782.html).
>> 
>> Are there known bugs in our compiler for (plain) i486 systems?
[ ... ]

> Is that PR/51094?
It certainly looks closely related, symptom-wise.  I have tried
the suggested workaround, but the kernel still panics.

-jarle