Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2021.04.25.05.33.20 thorpej src/tests/dev/scsipi/libscsitest/scsitest.c,v 1.4 2021.04.25.05.52.22 nia src/share/man/man8/compat_linux.8,v 1.42 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2021.04.html#2021.04.25.05.52.22
Re: thorpej-cfargs branch merged
Hi, Jason Thorpe writes: > Folks -- > > I just merged the thorpej-cfargs branch, which contains some > mostly-mechanical cleanups and some small but very useful enhancements to the > device auto configuration subsystem. I've made an effort to build just about > every kernel config we have, and boot said kernel on a reasonable variety of > systems that I have (either real hardware or VMs)... but obviously I can't > try everything, so keep an eye out for crashes / panics or other bizarre new > behavior during auto configuration and ping me off-list if you encounter any. Thanks for your great work. I have encountered the following build failure: /usr/src/tests/dev/scsipi/libscsitest/scsitest.c: In function 'scsitest_attach': /usr/src/tests/dev/scsipi/libscsitest/scsitest.c:258:2: error: implicit declaration of function 'config_found_ia'; did you mean 'config_found'? [-Werror=implicit-function-declaration] 258 | config_found_ia(self, "scsi", &sc->sc_channel, scsiprint); | ^~~ | config_found Could you take a look at this failure outside src/sys? Thank you. > Thx. > > -- thorpej > -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: thorpej-cfargs branch merged
> On Apr 24, 2021, at 6:53 PM, Izumi Tsutsui wrote: > > thorpej@ wrote: > >> Folks -- >> >> I just merged the thorpej-cfargs branch, which contains some >> mostly-mechanical cleanups and some small but very useful enhancements >> to the device auto configuration subsystem. > > Maybe several section 5 and 9 man pages should be updated to sync > with the changes? config(5), autoconf(9), config(9), etc. > (though I'm not sure if they reflected reality even before merge) I’ll take a look and make updates. -- thorpej
Re: thorpej-cfargs branch merged
thorpej@ wrote: > Folks -- > > I just merged the thorpej-cfargs branch, which contains some > mostly-mechanical cleanups and some small but very useful enhancements > to the device auto configuration subsystem. Maybe several section 5 and 9 man pages should be updated to sync with the changes? config(5), autoconf(9), config(9), etc. (though I'm not sure if they reflected reality even before merge) Thanks, --- Izumi Tsutsui
Automated report: NetBSD-current/i386 build failure
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 2021.04.24.23.40.16. An extract from the build.sh output follows: nbmake[4]: stopped in /tmp/build/2021.04.24.23.40.16-i386/src --- dependall-external --- nbmake[4]: stopped in /tmp/build/2021.04.24.23.40.16-i386/src --- dependall-crypto/external --- nbmake[7]: stopped in /tmp/build/2021.04.24.23.40.16-i386/src/crypto/external/bsd/openssl --- dependall-usr.sbin --- nbmake[4]: stopped in /tmp/build/2021.04.24.23.40.16-i386/src --- dependall-share --- nbmake[4]: stopped in /tmp/build/2021.04.24.23.40.16-i386/src --- dependall-bin --- nbmake[4]: stopped in /tmp/build/2021.04.24.23.40.16-i386/src --- dependall-crypto/external --- nbmake[6]: stopped in /tmp/build/2021.04.24.23.40.16-i386/src/crypto/external/bsd nbmake[5]: stopped in /tmp/build/2021.04.24.23.40.16-i386/src/crypto/external nbmake[4]: stopped in /tmp/build/2021.04.24.23.40.16-i386/src nbmake[3]: stopped in /tmp/build/2021.04.24.23.40.16-i386/src nbmake[2]: stopped in /tmp/build/2021.04.24.23.40.16-i386/src nbmake[1]: stopped in /tmp/build/2021.04.24.23.40.16-i386/src nbmake: stopped in /tmp/build/2021.04.24.23.40.16-i386/src ERROR: Failed to make release Between the last successful build and the failed build, a total of 1149 revisions were committed, by the following developer: thorpej The first of these commits was made on CVS date 2021.04.24.23.36.23, and the last on 2021.04.24.23.40.16. Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2021.04.html#2021.04.24.23.40.16
thorpej-cfargs branch merged
Folks -- I just merged the thorpej-cfargs branch, which contains some mostly-mechanical cleanups and some small but very useful enhancements to the device auto configuration subsystem. I've made an effort to build just about every kernel config we have, and boot said kernel on a reasonable variety of systems that I have (either real hardware or VMs)... but obviously I can't try everything, so keep an eye out for crashes / panics or other bizarre new behavior during auto configuration and ping me off-list if you encounter any. Thx. -- thorpej
Re: vether vs. tap, initialization order, etc
On Sat, 24 Apr 2021 at 20:11, Martin Husemann wrote: > > On Sat, Apr 24, 2021 at 03:19:16PM +, nia wrote: > > Thank you! This works great, I'll make note of it in the NetBSD Guide's > > section > > on networking. > > Another option (as rjs hinted) is to only have a vether0.ifconfig (I did > that with bridge0.ifconfig for other setups) and use ! lines to do the > required other ifconfig commands for various interfaces all in there. > > Keeps the whole bridge config in one place and is (IMHO) a bit clearer to > read. That's what I thought better, as it doesn't depend on anything else. My ifconfig.bridge0 is create !ifconfig tap0 create up description "LxMint" !ifconfig tap1 create up description "MXLinux" !ifconfig tap2 create up description "FreeBSD12" !ifconfig tap3 create up description "NBSDc" !ifconfig tap4 create up description "OpenBSD" !ifconfig tap5 create up description "Windows10" !brconfig $int add wm0 !brconfig $int add tap0 !brconfig $int add tap1 !brconfig $int add tap2 !brconfig $int add tap3 !brconfig $int add tap4 !brconfig $int add tap5 up (for use by a bunch of qemu-nvmm guests). > > Martin --
Re: vether vs. tap, initialization order, etc
On Sat, Apr 24, 2021 at 03:19:16PM +, nia wrote: > Thank you! This works great, I'll make note of it in the NetBSD Guide's > section > on networking. Another option (as rjs hinted) is to only have a vether0.ifconfig (I did that with bridge0.ifconfig for other setups) and use ! lines to do the required other ifconfig commands for various interfaces all in there. Keeps the whole bridge config in one place and is (IMHO) a bit clearer to read. Martin
Re: vether vs. tap, initialization order, etc
On Sat, Apr 24, 2021 at 07:57:30AM -0700, Jason Thorpe wrote: > > > On Apr 24, 2021, at 5:42 AM, nia wrote: > > > > I wonder if there's an initialization order difference > > somewhere. > > If you want to have control over the initialization order, you need to set > auto_ifconfig=NO. On one of my systems that has a bunch of Qemu VMs: > > auto_ifconfig=NO > net_interfaces="tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 tap10 tap11 > bridge0” > > …otherwise I was having the problem of bridge0 being brought up before the > tap devices were created. > > -- thorpej > Thank you! This works great, I'll make note of it in the NetBSD Guide's section on networking.
Re: vether vs. tap, initialization order, etc
> On Apr 24, 2021, at 5:42 AM, nia wrote: > > I wonder if there's an initialization order difference > somewhere. If you want to have control over the initialization order, you need to set auto_ifconfig=NO. On one of my systems that has a bunch of Qemu VMs: auto_ifconfig=NO net_interfaces="tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 tap10 tap11 bridge0” …otherwise I was having the problem of bridge0 being brought up before the tap devices were created. -- thorpej
Re: vether vs. tap, initialization order, etc
nia wrote: >I just updated our home router from 9.1 to -current because a >roommate wanted to use wg(4). > >I use tap as a bridge endpoint for two NICs that are used for >the LAN. > >I thought I'd be able to copy the configs and do a straightforward >subtitution from tap to vether but this doesn't work. >/etc/rc.d/network fails to "up" the bridge on boot. > >The bridge was previously initialized in /etc/ifconfig.tap0, >like so, now /etc/ifconfig.vether0: > >create >inet 10.0.1.1 netmask 255.255.255.0 >!brconfig bridge0 add $int add re1 add re2 up If vether(4) is like other network devices then I would expect to have to bring it up as well, I don't see anything in your ifconfig.vether0 to do that. I have usually brought up the bridge explicitly in /etc/ifconfig.bridge0 rather than from brconfig(8) but don't know if it makes a difference.
vether vs. tap, initialization order, etc
I just updated our home router from 9.1 to -current because a roommate wanted to use wg(4). I use tap as a bridge endpoint for two NICs that are used for the LAN. I thought I'd be able to copy the configs and do a straightforward subtitution from tap to vether but this doesn't work. /etc/rc.d/network fails to "up" the bridge on boot. The bridge was previously initialized in /etc/ifconfig.tap0, like so, now /etc/ifconfig.vether0: create inet 10.0.1.1 netmask 255.255.255.0 !brconfig bridge0 add $int add re1 add re2 up I wonder if there's an initialization order difference somewhere.
