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.5
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 sr
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.
|
| $ s
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 fou
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
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.
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
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
# 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-buf
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 ras
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 rasops1
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'
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 ca
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
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_
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
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
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 sin
18 matches
Mail list logo