Automated report: NetBSD-current/i386 build failure

[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]: 
"/tmp/bracket/build/2016.09.17.00.59.59-i386/src/share/mk/bsd.own.mk" line 176: 
Malformed conditional (${MACHINE} == "alpha" ||  ${MACHINE} == "amd64" ||  
${MACHINE} == "hppa" ||  ${MACHINE} == "i386" ||  ${MACHINE} == "ia64" ||  
${MACHINE} == "playstation2" ||  ${MACHINE} == "sparc" ||  ${MACHINE} == 
"sparc64" ||  ${MACHINE} == "vax" ||  ${MACHINE_CPU} == "m68k" ||)
nbmake[2]: 
"/tmp/bracket/build/2016.09.17.00.59.59-i386/src/share/mk/bsd.own.mk" line 185: 
Malformed conditional (${HAVE_BINUTILS} == 223)
--- kern-XEN3PAE_DOM0 ---
nbmake[2]: 
"/tmp/bracket/build/2016.09.17.00.59.59-i386/src/share/mk/bsd.own.mk" line 152: 
Malformed conditional (${MACHINE} == "alpha" ||  ${MACHINE} == "amd64" ||  
${MACHINE} == "i386" ||  ${MACHINE} == "ia64" ||  ${MACHINE} == "playstation2" 
||  ${MACHINE} == "sparc" ||  ${MACHINE} == "sparc64" ||  ${MACHINE} == "vax" 
||  ${MACHINE_CPU} == "arm" ||  ${MACHINE_CPU} == "m68k" ||  ${MACHINE_CPU} == 
"mips" ||  ${MACHINE_CPU} == "powerpc" ||  ${MACHINE_CPU} == "sh3" ||)
nbmake[2]: 
"/tmp/bracket/build/2016.09.17.00.59.59-i386/src/share/mk/bsd.own.mk" line 158: 
Malformed conditional (${HAVE_GDB} == 79)
nbmake[2]: 
"/tmp/bracket/build/2016.09.17.00.59.59-i386/src/share/mk/bsd.own.mk" line 176: 
Malformed conditional (${MACHINE} == "alpha" ||  ${MACHINE} == "amd64" ||  
${MACHINE} == "hppa" ||  ${MACHINE} == "i386" ||  ${MACHINE} == "ia64" ||  
${MACHINE} == "playstation2" ||  ${MACHINE} == "sparc" ||  ${MACHINE} == 
"sparc64" ||  ${MACHINE} == "vax" ||  ${MACHINE_CPU} == "m68k" ||)
nbmake[2]: 
"/tmp/bracket/build/2016.09.17.00.59.59-i386/src/share/mk/bsd.own.mk" line 185: 
Malformed conditional (${HAVE_BINUTILS} == 223)
--- kern-GENERIC ---
Build directory is 
/tmp/bracket/build/2016.09.17.00.59.59-i386/obj/sys/arch/i386/compile/GENERIC
Don't forget to run "make depend"
--- kern-INSTALL ---
Build directory is 
/tmp/bracket/build/2016.09.17.00.59.59-i386/obj/sys/arch/i386/compile/INSTALL
Don't forget to run "make depend"
--- kern-GENERIC ---
cd 
/tmp/bracket/build/2016.09.17.00.59.59-i386/obj/sys/arch/i386/compile/GENERIC 
&& /tmp/bracket/build/2016.09.17.00.59.59-i386/tools/bin/nbmake distclean
--- kern-INSTALL ---
cd 
/tmp/bracket/build/2016.09.17.00.59.59-i386/obj/sys/arch/i386/compile/INSTALL 
&& /tmp/bracket/build/2016.09.17.00.59.59-i386/tools/bin/nbmake distclean
--- kern-INSTALL_XEN3_DOMU ---
nbmake[2]: Fatal errors encountered -- cannot continue
nbmake[2]: stopped in 
/tmp/bracket/build/2016.09.17.00.59.59-i386/obj/sys/arch/i386/compile/INSTALL_XEN3_DOMU
*** [kern-INSTALL_XEN3_DOMU] Error code 1
nbmake[1]: stopped in /tmp/bracket/build/2016.09.17.00.59.59-i386/src/etc

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

2016.09.17.00.55.40 christos 
src/external/gpl3/gcc/dist/gcc/config/m68k/m68k.md,v 1.6
2016.09.17.00.59.59 christos src/share/mk/bsd.own.mk,v 1.957

Log files can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2016.09.html#2016.09.17.00.59.59

daily CVS update output

[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 src/external/gpl3/gcc/dist/gcc/config/m68k/m68k.md
P src/lib/libc/time/Makefile
P src/lib/libc/time/NEWS
P src/lib/libc/time/Theory
P src/lib/libc/time/tz-art.htm
U src/lib/libc/time/tz-how-to.html
P src/lib/libc/time/tz-link.htm
P src/lib/libc/time/zic.c
P src/sbin/fsck_lfs/lfs.c
P src/share/man/man4/nvme.4
P src/share/man/man9/bus_space.9
P src/share/man/man9/pci_msi.9
P src/share/mk/bsd.own.mk
P src/sys/arch/amd64/amd64/trap.c
P src/sys/arch/i386/i386/copy.S
P src/sys/arch/i386/i386/trap.c
P src/sys/arch/macppc/dev/platinumfb.c
P src/sys/arch/sparc/dev/cgfourteen.c
P src/sys/compat/netbsd32/netbsd32.h
P src/sys/compat/netbsd32/netbsd32_netbsd.c
P src/sys/compat/netbsd32/netbsd32_signal.c
P src/sys/dev/ld.c
P src/sys/dev/ldvar.h
P src/sys/dev/ata/ld_ataraid.c
P src/sys/dev/i2o/ld_iop.c
P src/sys/dev/ic/ld_aac.c
P src/sys/dev/ic/ld_cac.c
P src/sys/dev/ic/ld_icp.c
P src/sys/dev/ic/ld_mlx.c
P src/sys/dev/ic/ld_nvme.c
P src/sys/dev/ic/nvme.c
P src/sys/dev/ic/nvmereg.h
P src/sys/dev/ic/rt2860reg.h
P src/sys/dev/pci/ld_amr.c
P src/sys/dev/pci/ld_twa.c
P src/sys/dev/pci/ld_twe.c
P src/sys/dev/pci/ld_virtio.c
P src/sys/dev/pci/nvme_pci.c
P src/sys/dev/pci/pcidevs
P src/sys/dev/pci/pcidevs.h
P src/sys/dev/pci/pcidevs_data.h
P src/sys/dev/sdmmc/ld_sdmmc.c
P src/sys/dev/usb/if_run.c
P src/sys/dev/usb/if_runvar.h
P src/sys/kern/files.kern
P src/sys/kern/kern_pax.c
P src/sys/modules/Makefile
P src/sys/modules/compat_netbsd32/Makefile
P src/sys/modules/dtrace/fbt/Makefile
U src/sys/modules/nvme/Makefile
U src/sys/modules/nvme/nvme.ioconf
P src/sys/net/files.net
P src/sys/net/if_spppsubr.c
P src/sys/net80211/ieee80211.h
P src/sys/netinet/if_arp.c
P src/sys/netinet/in.c
P src/sys/netinet/in_var.h
P src/sys/sys/param.h
P src/sys/uvm/pmap/pmap.c

Updating xsrc tree:
P xsrc/external/mit/xf86-video-suncg14/dist/src/cg14_accel.c
P xsrc/external/mit/xf86-video-suncg14/dist/src/cg14_cursor.c
P xsrc/external/mit/xf86-video-suncg14/dist/src/cg14_driver.c
P xsrc/external/mit/xf86-video-suncg14/dist/src/cg14_render.c


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 Sep 17 03:10:09 2016
SUP Scan for current completed at Sat Sep 17 03:10:30 2016
SUP Scan for mirror starting at Sat Sep 17 03:10:30 2016
SUP Scan for mirror completed at Sat Sep 17 03:12:48 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

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

[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 to zero.
  | 
  | $ sysctl -a | grep dad
  | net.inet.ip.dad_count = 3
  | net.inet6.ip6.dad_count = 1

That isn't disabling the IFF_TENTATIVE handling, it is dosabling DAD, which
is a different thing entirely.

As I understand it, the reason for the change in 1.261 was to prevent sending
from invalid addresses (which is a good thing) - but tentative addresses are
not invalid, they just have not been proved valid yet, which is a different
thing entirely.   99.9% (or more) of all tentative addresses are valid, and
will remain valid, and there's no good reason not to send from them (what's
more, it is require that we do so in the case that the same address is being
claimed by 2 nodes at the same time - both are performing DAD together, in
order for DAD to work properly - the ARP/ND requests must be answered.)

I think I would drop the assumption that tentative addresses are invalid,
and just allow sending from them.   But if that isn't done, then UDP should
be treated the same as TCP, and packets just "lost" rather than returning
a transmit error.

kre

Automated report: NetBSD-current/i386 build success

[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 found at:


http://releng.NetBSD.org/b5reports/i386/commits-2016.09.html#2016.09.16.23.20.31

Re: NFS boot fails with ip_output.c rev 1.261

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

>You can disable it by setting the appropriate sysctl to zero.

>$ sysctl -a | grep dad
>net.inet.ip.dad_count = 3
>net.inet6.ip6.dad_count = 1

Yes, but unfortunately that's too late for NFS boot :)

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: NFS boot fails with ip_output.c rev 1.261

[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 zero.

$ sysctl -a | grep dad
net.inet.ip.dad_count = 3
net.inet6.ip6.dad_count = 1

Roy

Re: NFS boot fails with ip_output.c rev 1.261

[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
"A potential Snark may lurk in every tree."

Re: NFS boot fails with ip_output.c rev 1.261

[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 finish.

The NFS boot code has a hard coded delay of 3 seconds between configuring
the interface and using it to start the NFS mount operation. That's
too short for DAD to complete. As the mount operation is done with UDP
the code fails immediately.

The slow DAD mechanism creates more problems than it solves.
The NFS boot code should handle such errors gracefully.

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

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

[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
ssp-buffer-size=1 -fno-strict-aliasing -fno-common -std=gnu99 -Werror
-Wall -Wno-main -Wno-format-zero-length -Wpointer-arith
-Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition
-Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code
-Wno-pointer-sign -Wno-attributes -Wextra -Wno-unused-parameter
-Wold-style-definition -Wno-sign-compare
--sysroot=/usr/src/obj/destdir.amd64 -Damd64 -Dx86_64 -I.
-I/usr/src/sys/external/bsd/acpica/dist
-I/usr/src/sys/../common/lib/libx86emu
-I/usr/src/sys/../common/include -I/usr/src/sys/arch -I/usr/src/sys
-nostdinc -DDIAGNOSTIC -D_KERNEL -D_KERNEL_OPT -std=gnu99
-I/usr/src/sys/lib/libkern/../../../common/lib/libc/quad
-I/usr/src/sys/lib/libkern/../../../common/lib/libc/string
-I/usr/src/sys/lib/libkern/../../../common/lib/libc/arch/x86_64/string
-D_FORTIFY_SOURCE=2 -I/usr/src/sys/external/bsd/ipf
-I/usr/src/sys/external/isc/atheros_hal/dist
-I/usr/src/sys/external/isc/atheros_hal/ic
-I/usr/src/sys/external/bsd/common/include
-I/usr/src/sys/external/bsd/drm2/include
-I/usr/src/sys/external/bsd/common/include
-I/usr/src/sys/external/bsd/drm2/include
-I/usr/src/sys/external/bsd/drm2/include/drm
-I/usr/src/sys/external/bsd/drm2/dist
-I/usr/src/sys/external/bsd/drm2/dist/include
-I/usr/src/sys/external/bsd/drm2/dist/include/drm
-I/usr/src/sys/external/bsd/drm2/dist/uapi
-I/usr/src/sys/external/bsd/common/include -D__KERNEL__ -DCONFIG_FB=0
-DCONFIG_BACKLIGHT_CLASS_DEVICE=0
-DCONFIG_BACKLIGHT_CLASS_DEVICE_MODULE=0
-I/usr/src/sys/../common/include -DCONFIG_AGP
-I/usr/src/sys/external/bsd/drm2/dist/drm/i915
-I/usr/src/sys/external/bsd/drm2/i915drm -DCONFIG_DRM_I915_FBDEV=1
-DCONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=0
-I/usr/src/sys/external/bsd/drm2/dist/drm/radeon
-I/usr/src/sys/external/bsd/drm2/include/radeon
-I/usr/src/sys/external/bsd/drm2/radeon
-I/usr/src/sys/external/bsd/drm2/dist/drm/nouveau
-I/usr/src/sys/external/bsd/drm2/dist/drm/nouveau/core
-I/usr/src/sys/external/bsd/drm2/dist/drm/nouveau/core/include
-I/usr/src/sys/external/bsd/drm2/nouveau -DCONFIG_NOUVEAU_DEBUG=5
-DCONFIG_NOUVEAU_DEBUG_DEFAULT=3
-I/usr/src/sys/external/bsd/acpica/dist/include -c
/usr/src/sys/opencrypto/ocryptodev.c -o ocryptodev.o
--- nvme_pci.o ---
/usr/src/sys/dev/pci/nvme_pci.c:432:13: error: unknown type name 'modcmd_t'
 nvme_modcmd(modcmd_t cmd, void *opaque)
 ^
*** [nvme_pci.o] Error code 1

nbmake: stopped in /usr/obj/sys/arch/amd64/compile/GENERIC.bch
--- ocryptodev.o ---
/usr/src/obj/tooldir.NetBSD-7.99.37-amd64/bin/nbctfconvert -g -L
VERSION -g ocryptodev.o
--- nxt2k.o ---
/usr/src/obj/tooldir.NetBSD-7.99.37-amd64/bin/nbctfconvert -g -L
VERSION -g nxt2k.o
--- nvme.o ---
/usr/src/obj/tooldir.NetBSD-7.99.37-amd64/bin/nbctfconvert -g -L
VERSION -g nvme.o
1 error

Re: rasops15 byte order bug

[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, 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 since I played with this, but I think this is used for
> > > tifb (am335x SoCs, as found on the beaglebone). AFAIK It works fine for me
> > > with a 16bit display.
> > 
> > I suspect the #ifdef shouldn't check just host byte order but host byte
> > order vs. video hardware byte order. Probably needs a new rasops_info flag.
> 
> I haven't touched this in a *very* long time, but (about early 2002)
> in rasops8.c I ended up with
> 
> #if BYTE_ORDER == BIG_ENDIAN
> #define NEED_LITTLE_ENDIAN_STAMP RI_BSWAP
> #else
> #define NEED_LITTLE_ENDIAN_STAMP 0
> #endif
>   if ((ri->ri_flg & RI_BSWAP) == NEED_LITTLE_ENDIAN_STAMP)
>   ...
> 
> Don't know how correct that was, but it's been working for the endian
> permutations we have.
> 
> Note that we apply RI_BSWAP to 32 and 15/16 bit cases in rasops.c, not
> when building stamps.

I think we need something like RI_FB_IS_BE and adjust the endianness
checks accordingly. That would also solve the igsfb thing.

have fun
Michael

Re: rasops15 byte order bug

[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 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 since I played with this, but I think this is used for
> > tifb (am335x SoCs, as found on the beaglebone). AFAIK It works fine for me
> > with a 16bit display.
> 
> I suspect the #ifdef shouldn't check just host byte order but host byte
> order vs. video hardware byte order. Probably needs a new rasops_info flag.

I haven't touched this in a *very* long time, but (about early 2002)
in rasops8.c I ended up with

#if BYTE_ORDER == BIG_ENDIAN
#define NEED_LITTLE_ENDIAN_STAMP RI_BSWAP
#else
#define NEED_LITTLE_ENDIAN_STAMP 0
#endif
if ((ri->ri_flg & RI_BSWAP) == NEED_LITTLE_ENDIAN_STAMP)
...

Don't know how correct that was, but it's been working for the endian
permutations we have.

Note that we apply RI_BSWAP to 32 and 15/16 bit cases in rasops.c, not
when building stamps.

-uwe

Re: rasops15 byte order bug

[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
> framebuffer attachment?
>

I'll have to look at this again when I have time...

I recall RI_BSWAP didn't help but the kernel option RASOPS_SMALL did.

I'll add a note in driver about it for now and leave rasops15.c alone.

Thanks

Re: rasops15 byte order bug

[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, wondering if anyone else can confirm the error
> > and/or verify this fix.
> 
> It's been a while since I played with this, but I think this is used for
> tifb (am335x SoCs, as found on the beaglebone). AFAIK It works fine for me
> with a 16bit display.

I suspect the #ifdef shouldn't check just host byte order but host byte
order vs. video hardware byte order. Probably needs a new rasops_info flag.

have fun
Michael

Automated report: NetBSD-current/i386 build failure

[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: /tmp/bracket/build/2016.09.16.11.48.10-i386/destdir/
obsolete_stand fix:
postinstall fixes passed: obsolete_stand
postinstall fixes failed:
   ===
checkflist ===> distrib/sets
--- check_DESTDIR ---
--- checkflist ---
cd /tmp/bracket/build/2016.09.16.11.48.10-i386/src/distrib/sets &&  
DESTDIR=/tmp/bracket/build/2016.09.16.11.48.10-i386/destdir  MACHINE=i386  
MACHINE_ARCH=i386  
AWK=/tmp/bracket/build/2016.09.16.11.48.10-i386/tools/bin/nbawk  
CKSUM=/tmp/bracket/build/2016.09.16.11.48.10-i386/tools/bin/nbcksum  
DB=/tmp/bracket/build/2016.09.16.11.48.10-i386/tools/bin/nbdb  EGREP=grep\ -E  
HOST_SH=/bin/sh  
MAKE=/tmp/bracket/build/2016.09.16.11.48.10-i386/tools/bin/nbmake  
MKTEMP=/tmp/bracket/build/2016.09.16.11.48.10-i386/tools/bin/nbmktemp  
MTREE=/tmp/bracket/build/2016.09.16.11.48.10-i386/tools/bin/nbmtree  
PAX=/tmp/bracket/build/2016.09.16.11.48.10-i386/tools/bin/nbpax  
COMPRESS_PROGRAM=gzip  GZIP=-n  
PKG_CREATE=/tmp/bracket/build/2016.09.16.11.48.10-i386/tools/bin/nbpkg_create  
SED=/tmp/bracket/build/2016.09.16.11.48.10-i386/tools/bin/nbsed  
TSORT=/tmp/bracket/build/2016.09.16.11.48.10-i386/tools/bin/nbtsort\ -q  
/bin/sh /tmp/bracket/build/2016.09.16.11.48.10-i386/src/distrib/sets/checkflist 
 
 -L base  -M 
/tmp/bracket/build/2016.09.16.11.48.10-i386/destdir/METALOG.sanitised
===  6 extra files in DESTDIR  =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./stand/i386-xen/7.99.38/modules/nvme
./stand/i386-xen/7.99.38/modules/nvme/nvme.kmod
./stand/i386/7.99.38/modules/nvme
./stand/i386/7.99.38/modules/nvme/nvme.kmod
./stand/i386pae-xen/7.99.38/modules/nvme
./stand/i386pae-xen/7.99.38/modules/nvme/nvme.kmod
=  end of 6 extra files  ===
*** [checkflist] Error code 1
nbmake[2]: stopped in 
/tmp/bracket/build/2016.09.16.11.48.10-i386/src/distrib/sets
1 error

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

2016.09.16.10.54.45 jdolecek src/sys/dev/ic/nvmereg.h,v 1.4
2016.09.16.10.59.28 jdolecek src/sys/dev/pci/nvme_pci.c,v 1.5
2016.09.16.11.13.47 christos src/sbin/fsck_lfs/lfs.c,v 1.72
2016.09.16.11.35.07 jdolecek src/sys/dev/pci/nvme_pci.c,v 1.6
2016.09.16.11.35.07 jdolecek src/sys/modules/Makefile,v 1.177
2016.09.16.11.35.07 jdolecek src/sys/modules/nvme/Makefile,v 1.1
2016.09.16.11.35.07 jdolecek src/sys/modules/nvme/nvme.ioconf,v 1.1
2016.09.16.11.41.40 jdolecek src/sys/dev/ic/nvme.c,v 1.6
2016.09.16.11.48.10 maxv src/sys/arch/amd64/amd64/trap.c,v 1.85
2016.09.16.11.48.10 maxv src/sys/arch/i386/i386/trap.c,v 1.279

Log files can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2016.09.html#2016.09.16.11.48.10

Re: NFS boot fails with ip_output.c rev 1.261

[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: my_name=erlite
>   nfs_boot: my_addr=192.168.10.131
>   nfs_boot: my_mask=255.255.255.0
>   nfs_boot: gateway=192.168.10.1
>   nfs_boot: sosend: 49
>   nfs_boot: sosend: 49
>   nfs_boot: sosend: 49
>   nfs_boot: mountd error=49
>   nfs_boot: mountd `cubietruck:/exports/erlite', error=49
>   cannot mount root, error = 49
>   root device (default cnmac0):
> 
> In the kernel configuration file, NFS_BOOT_BOOTP option is specified
> instead of NFS_BOOT_DHCP in the original configuration file.
> 
> By reverting ip_output.c to rev 1.260, the system boots up normally.
> And the root directory can be mounted from other (non-NetBSD) hosts.

Sounds like NFS boot needs to wait for IN_IFF_TENTATIVE to clear from
the address.

Roy

NFS boot fails with ip_output.c rev 1.261

[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: my_addr=192.168.10.131
  nfs_boot: my_mask=255.255.255.0
  nfs_boot: gateway=192.168.10.1
  nfs_boot: sosend: 49
  nfs_boot: sosend: 49
  nfs_boot: sosend: 49
  nfs_boot: mountd error=49
  nfs_boot: mountd `cubietruck:/exports/erlite', error=49
  cannot mount root, error = 49
  root device (default cnmac0):

In the kernel configuration file, NFS_BOOT_BOOTP option is specified
instead of NFS_BOOT_DHCP in the original configuration file.

By reverting ip_output.c to rev 1.260, the system boots up normally.
And the root directory can be mounted from other (non-NetBSD) hosts.

I attached the full boot message below.

Thanks,
Rin

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 7.99.38 (ERLITE_RO) #1: Fri Sep 16 21:17:13 JST 2016
rin@XXX:XXX
Cavium Octeon CN50XX
total memory = 512 MB
avail memory = 500 MB
timecounter: Timecounters tick every 10.000 msec
mainbus0 (root)
cpunode0 at mainbus0: 2 cores, crypto+kasumi, 64bit-mul, unaligned-access ok
cpu0 at cpunode0 core 0: 500.00MHz (hz cycles = 500, delay divisor = 500)
cpu0: Cavium CN50xx (0xd0601) Rev. 1 with software emulated floating point
cpu0: 64 TLB entries, 512TB (49-bit) VAs, 512TB (49-bit) PAs, 256MB max page 
size
cpu0: 32KB/128B 4-way set-associative L1 instruction cache
cpu0: 16KB/128B 64-way set-associative write-through coherent L1 data cache
cpu0: 128KB/128B 8-way set-associative write-back L2 unified cache
cpu1 at cpunode0 core 1: disabled (uniprocessor kernel)
wdog0 at cpunode0: default period is 4 seconds
iobus0 at mainbus0
iobus0: initializing POW
iobus0: initializing FPA
com0 at iobus0 address 0x000118000800: ns16650, no ERS, working fifo
com0: console
com at iobus0 address 0x000118000c00 not configured
octeon_rnm0 at iobus0 address 0x000118004000
octeon_rnm0: random number generator enabled: 1hz
octeon_twsi at iobus0 address 0x000118001000 not configured
octeon_mpi at iobus0 address 0x000107001000 not configured
octeon_gmx0 at iobus0 address 0x000118000800
cnmac0 at octeon_gmx0: address=0x000118000800: RGMII
cnmac0: Ethernet address xx:xx:xx:xx:xx:xx
atphy0 at cnmac0 phy 7: Atheros AR8035 10/100/1000 PHY, rev. 2
atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX-FDX, 
1000baseT-FDX, auto
cnmac1 at octeon_gmx0: address=0x000118000800: RGMII
cnmac1: Ethernet address xx:xx:xx:xx:xx:xx
atphy1 at cnmac1 phy 6: Atheros AR8035 10/100/1000 PHY, rev. 2
atphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX-FDX, 
1000baseT-FDX, auto
cnmac2 at octeon_gmx0: address=0x000118000800: RGMII
cnmac2: Ethernet address xx:xx:xx:xx:xx:xx
atphy2 at cnmac2 phy 5: Atheros AR8035 10/100/1000 PHY, rev. 2
atphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX-FDX, 
1000baseT-FDX, auto
dwctwo0 at iobus0 address 0x000118006800
usb0 at dwctwo0: USB revision 2.0
bootbus0 at mainbus0
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
timecounter: Timecounter "mips3_cp0_counter" frequency 5 Hz quality 100
uhub0 at usb0: vendor  DWC2 root hub, class 9/0, rev 2.00/1.00, addr 1
uhub0: 1 port with 1 removable, self powered
umass0 at uhub0 port 1 configuration 1 interface 0
umass0: vendor 13fe USB DISK 2.0, rev 2.00/1.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
uhub0: illegal enable change, port 1
sd0 at scsibus0 target 0 lun 0: <, USB DISK 2.0, PMAP> disk removable
sd0: 3700 MB, 928 cyl, 255 head, 32 sec, 512 bytes/sect x 7579008 sectors
WARNING: 1 error while detecting hardware; check system log.
boot device: sd0
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: my_addr=192.168.10.131
nfs_boot: my_mask=255.255.255.0
nfs_boot: gateway=192.168.10.1
nfs_boot: sosend: 49
nfs_boot: sosend: 49
nfs_boot: sosend: 49
nfs_boot: mountd error=49
nfs_boot: mountd `cubietruck:/exports/erlite', error=49
cannot mount root, error = 49
root device (default cnmac0):

Re: rasops15 byte order bug

[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

[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 since I played with this, but I think this is used for
tifb (am335x SoCs, as found on the beaglebone). AFAIK It works fine for me
with a 16bit display.

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