Automated report: NetBSD-current/i386 build failure

2016-09-16 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.09.17.00.59.59. An extract from the build.sh output follows: nbmake[2]:

daily CVS update output

2016-09-16 Thread NetBSD source update
Updating src tree: P src/distrib/sets/lists/modules/md.amd64 P src/distrib/sets/lists/modules/md.i386 P src/distrib/sets/lists/modules/mi P src/doc/3RDPARTY P src/doc/CHANGES P src/doc/roadmaps/storage P src/external/cddl/osnet/dev/fbt/fbt.c P src/external/gpl3/gcc/dist/gcc/config/m68k/m68k.c P

Re: NFS boot fails with ip_output.c rev 1.261 Re: NFS boot fails with ip_output.c rev 1.261

2016-09-16 Thread Robert Elz
Date:Fri, 16 Sep 2016 23:37:40 +0100 From:Roy Marples Message-ID: <03a78e8605c842d9d032ee3ed3a59...@mail.marples.name> | > The IN_IFF_TENTATIVE handling just breaks lots of old code. | | You can disable it by setting the appropriate sysctl

Automated report: NetBSD-current/i386 build success

2016-09-16 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.09.16.23.01.53 pgoyette src/distrib/sets/lists/modules/mi,v 1.95 2016.09.16.23.20.31 pgoyette src/sys/dev/pci/nvme_pci.c,v 1.7 Log files can be

Re: NFS boot fails with ip_output.c rev 1.261

2016-09-16 Thread Michael van Elst
r...@marples.name (Roy Marples) writes: >On 2016-09-16 23:10, mlel...@serpens.de wrote: >> r...@marples.name (Roy Marples) writes: >> >>> Sounds like NFS boot needs to wait for IN_IFF_TENTATIVE to clear from >>> the address. >> >> The IN_IFF_TENTATIVE handling just breaks lots of old code.

Re: NFS boot fails with ip_output.c rev 1.261

2016-09-16 Thread Roy Marples
On 2016-09-16 23:10, mlel...@serpens.de wrote: r...@marples.name (Roy Marples) writes: Sounds like NFS boot needs to wait for IN_IFF_TENTATIVE to clear from the address. The IN_IFF_TENTATIVE handling just breaks lots of old code. You can disable it by setting the appropriate sysctl to

Re: NFS boot fails with ip_output.c rev 1.261

2016-09-16 Thread Michael van Elst
r...@marples.name (Roy Marples) writes: >Sounds like NFS boot needs to wait for IN_IFF_TENTATIVE to clear from >the address. The IN_IFF_TENTATIVE handling just breaks lots of old code. -- -- Michael van Elst Internet: mlel...@serpens.de

Re: NFS boot fails with ip_output.c rev 1.261

2016-09-16 Thread Michael van Elst
rokuy...@rk.phys.keio.ac.jp (Rin Okuyama) writes: > nfs_boot: sosend: 49 > nfs_boot: sosend: 49 > nfs_boot: sosend: 49 > nfs_boot: mountd error=49 The change in ip_output.c prevents the use of a recently configured interface because now you have to wait for duplicate address detection to

build failure w/ up-to-the-minute src

2016-09-16 Thread bch
# compile GENERIC.bch/ocryptodev.o /usr/src/obj/tooldir.NetBSD-7.99.37-amd64/bin/x86_64--netbsd-gcc -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -mno-avx -msoft-float -ffreestanding -fno-zero-initialized-in-bss -g -O2 -fno-omit-frame-pointer -fstack-protector -Wstack-protector --param

Re: rasops15 byte order bug

2016-09-16 Thread Michael
Hello, On Fri, 16 Sep 2016 20:29:32 +0300 Valery Ushakov wrote: > On Fri, Sep 16, 2016 at 13:05:16 -0400, Michael wrote: > > > On Fri, 16 Sep 2016 11:11:34 +0200 > > Manuel Bouyer wrote: > > > > > On Wed, Sep 14, 2016 at 01:40:50PM -0700,

Re: rasops15 byte order bug

2016-09-16 Thread Valery Ushakov
On Fri, Sep 16, 2016 at 13:05:16 -0400, Michael wrote: > On Fri, 16 Sep 2016 11:11:34 +0200 > Manuel Bouyer wrote: > > > On Wed, Sep 14, 2016 at 01:40:50PM -0700, scole_mail wrote: > > > Anyone using a 15/16 bit rasops console without issues? I think there is > > > a

Re: rasops15 byte order bug

2016-09-16 Thread scole_mail
Valery Ushakov writes: > On Wed, Sep 14, 2016 at 13:40:50 -0700, scole_mail wrote: > >> Anyone using a 15/16 bit rasops console without issues? I think >> there is a byte order error in rasops15.c > > Are you sure it's not the case of missing RI_BSWAP flag in your >

Re: rasops15 byte order bug

2016-09-16 Thread Michael
On Fri, 16 Sep 2016 11:11:34 +0200 Manuel Bouyer wrote: > On Wed, Sep 14, 2016 at 01:40:50PM -0700, scole_mail wrote: > > Anyone using a 15/16 bit rasops console without issues? I think there is > > a byte order error in rasops15.c . > > > > This patch worked for me,

Automated report: NetBSD-current/i386 build failure

2016-09-16 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.09.16.11.48.10. An extract from the build.sh output follows: Target directory:

Re: NFS boot fails with ip_output.c rev 1.261

2016-09-16 Thread Roy Marples
On 16/09/2016 13:43, Rin Okuyama wrote: > NFS boot fails with ip_output.c rev 1.261 with my ERLITE (evbmips64-eb): > > root on cnmac0 > nfs_boot: trying BOOTP > cnmac0: link state DOWN (was UNKNOWN) > cnmac0: link state UP (was DOWN) > nfs_boot: BOOTP next-server: 192.168.10.128 >

NFS boot fails with ip_output.c rev 1.261

2016-09-16 Thread Rin Okuyama
NFS boot fails with ip_output.c rev 1.261 with my ERLITE (evbmips64-eb): root on cnmac0 nfs_boot: trying BOOTP cnmac0: link state DOWN (was UNKNOWN) cnmac0: link state UP (was DOWN) nfs_boot: BOOTP next-server: 192.168.10.128 nfs_boot: my_name=erlite nfs_boot:

Re: rasops15 byte order bug

2016-09-16 Thread Valery Ushakov
On Wed, Sep 14, 2016 at 13:40:50 -0700, scole_mail wrote: > Anyone using a 15/16 bit rasops console without issues? I think > there is a byte order error in rasops15.c Are you sure it's not the case of missing RI_BSWAP flag in your framebuffer attachment? -uwe

Re: rasops15 byte order bug

2016-09-16 Thread Manuel Bouyer
On Wed, Sep 14, 2016 at 01:40:50PM -0700, scole_mail wrote: > Anyone using a 15/16 bit rasops console without issues? I think there is > a byte order error in rasops15.c . > > This patch worked for me, wondering if anyone else can confirm the error > and/or verify this fix. It's been a while