Criterion for version bump in HEAD?
I notice the numbering scheme for NetBSD-current versions, x.99.x but am curious about what determines when the rightmost component is bumped up, like 6.99.44 to 6.99.45 or 7.99.1 to 7.99.2 . Answer to this question won't make my NetBSD installations run any better or worse, but I'm still curious. Tom
Re: Is the installer supposed to work?
On Fri, Aug 22, 2014 at 10:13:14PM +0200, Maxime Villard wrote: - Wondering if it is a specific issue I reboot on Linux, and try to install the USB image and the ISO in a VM. It does not seem to complain about installboot, but now there's another issue: the installer can't download anything from the ftp repository, because dhclient returns Shared object libgssapi.so.10 not found dhclient? How does that get into the game? It uses dhcpcd, which does not depend on libgssapi.so.*, so I am confused. Martin
Re: Is the installer supposed to work?
Le 23/08/2014 13:00, Martin Husemann a écrit : On Fri, Aug 22, 2014 at 10:13:14PM +0200, Maxime Villard wrote: - Wondering if it is a specific issue I reboot on Linux, and try to install the USB image and the ISO in a VM. It does not seem to complain about installboot, but now there's another issue: the installer can't download anything from the ftp repository, because dhclient returns Shared object libgssapi.so.10 not found dhclient? How does that get into the game? It uses dhcpcd, which does not depend on libgssapi.so.*, so I am confused. The installer said the FTP repository was unreachable. ifconfig said there was no address, so I just tried to see what dhclient would say, and it couldn't even say something because of libgssapi.
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 2014.08.23.15.05.41. An extract from the build.sh output follows: obsolete_stand fix: postinstall fixes passed: obsolete_stand postinstall fixes failed: === checkflist === distrib/sets --- check_DESTDIR --- --- checkflist --- cd /tmp/bracket/build/2014.08.23.15.05.41-i386/src/distrib/sets DESTDIR=/tmp/bracket/build/2014.08.23.15.05.41-i386/destdir MACHINE=i386 MACHINE_ARCH=i386 AWK=/tmp/bracket/build/2014.08.23.15.05.41-i386/tools/bin/nbawk CKSUM=/tmp/bracket/build/2014.08.23.15.05.41-i386/tools/bin/nbcksum DB=/tmp/bracket/build/2014.08.23.15.05.41-i386/tools/bin/nbdb HOST_SH=/bin/sh MAKE=/tmp/bracket/build/2014.08.23.15.05.41-i386/tools/bin/nbmake MKTEMP=/tmp/bracket/build/2014.08.23.15.05.41-i386/tools/bin/nbmktemp MTREE=/tmp/bracket/build/2014.08.23.15.05.41-i386/tools/bin/nbmtree PAX=/tmp/bracket/build/2014.08.23.15.05.41-i386/tools/bin/nbpax COMPRESS_PROGRAM=gzip GZIP=-n PKG_CREATE=/tmp/bracket/build/2014.08.23.15.05.41-i386/tools/bin/nbpkg_create SED=/tmp/bracket/build/2014.08.23.15.05.41-i386/tools/bin/nbsed TSORT=/tmp/bracket/build/2014.08.23.15.05.41-i386/tools/bin/nbtsort\ -q /bin/sh /tmp/bracket/build/2014.08.23.15.05.41-i386/src/distrib/sets/checkflist \ -L base -M /tmp/bracket/build/2014.08.23.15.05.41-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 ? -- ./usr/tests/usr.bin/make/unit-tests/impsrc.exp ./usr/tests/usr.bin/make/unit-tests/impsrc.mk ./usr/tests/usr.bin/make/unit-tests/posix1.exp ./usr/tests/usr.bin/make/unit-tests/posix1.mk ./usr/tests/usr.bin/make/unit-tests/suffixes.exp ./usr/tests/usr.bin/make/unit-tests/suffixes.mk = end of 6 extra files === *** [checkflist] Error code 1 nbmake[2]: stopped in /tmp/bracket/build/2014.08.23.15.05.41-i386/src/distrib/sets 1 error The following commits were made between the last successful build and the failed build: 2014.08.23.14.50.24 christos src/tests/usr.bin/make/d_posix.mk,v 1.3 2014.08.23.14.50.24 christos src/tests/usr.bin/make/d_posix.out,v 1.3 2014.08.23.14.50.24 christos src/tests/usr.bin/make/t_make.sh,v 1.3 2014.08.23.14.50.24 christos src/usr.bin/make/make.1,v 1.231 2014.08.23.14.50.24 christos src/usr.bin/make/parse.c,v 1.199 2014.08.23.14.50.24 christos src/usr.bin/make/var.c,v 1.187 2014.08.23.15.02.04 christos src/usr.bin/make/unit-tests/Makefile,v 1.45 2014.08.23.15.02.04 christos src/usr.bin/make/unit-tests/posix1.exp,v 1.1 2014.08.23.15.02.04 christos src/usr.bin/make/unit-tests/posix1.mk,v 1.1 2014.08.23.15.03.22 wiz src/usr.bin/make/make.1,v 1.232 2014.08.23.15.05.40 christos src/usr.bin/make/compat.c,v 1.95 2014.08.23.15.05.40 christos src/usr.bin/make/lst.h,v 1.19 2014.08.23.15.05.40 christos src/usr.bin/make/lst.lib/lstInt.h,v 1.21 2014.08.23.15.05.40 christos src/usr.bin/make/lst.lib/lstRemove.c,v 1.15 2014.08.23.15.05.40 christos src/usr.bin/make/main.c,v 1.229 2014.08.23.15.05.40 christos src/usr.bin/make/make.1,v 1.233 2014.08.23.15.05.40 christos src/usr.bin/make/make.c,v 1.89 2014.08.23.15.05.40 christos src/usr.bin/make/make.h,v 1.94 2014.08.23.15.05.40 christos src/usr.bin/make/nonints.h,v 1.66 2014.08.23.15.05.40 christos src/usr.bin/make/parse.c,v 1.200 2014.08.23.15.05.40 christos src/usr.bin/make/suff.c,v 1.71 2014.08.23.15.05.40 christos src/usr.bin/make/targ.c,v 1.58 2014.08.23.15.05.40 christos src/usr.bin/make/unit-tests/impsrc.exp,v 1.1 2014.08.23.15.05.40 christos src/usr.bin/make/unit-tests/impsrc.mk,v 1.1 2014.08.23.15.05.40 christos src/usr.bin/make/unit-tests/suffixes.exp,v 1.1 2014.08.23.15.05.40 christos src/usr.bin/make/unit-tests/suffixes.mk,v 1.1 2014.08.23.15.05.41 christos src/tests/usr.bin/make/t_make.sh,v 1.4 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2014.08.html#2014.08.23.15.05.41
Re: More amd64 drmkms radeon
On 22 August 2014 23:39, Chavdar Ivanov ci4...@gmail.com wrote: On 22 August 2014 22:35, Robert Swindells r...@fdy2.co.uk wrote: Chavdar Ivanov wrote: On 22 August 2014 16:56, Taylor R Campbell riastr...@netbsd.org wrote: Date: Fri, 22 Aug 2014 10:18:59 +0100 From: Chavdar Ivanov ci4...@gmail.com A DRMKMS kernel from 15th works as suggested above - switches to 1280x1024 and is fine after (Xorg panics earlier; with the latest build from yesterday it even wedged the machine completely). On the other hand yesterday's kernel panics as follows: [...] drm kern error: radeon_cp: Failed to load firmware radeon/R300_cp.bin Do you still have /usr/libdata/firmware/radeon/R300_cp.bin on the root file system? Yes, the kernel from 15th of August loads it fine: $ uname -a NetBSD uksup1.delcam.local 7.99.1 NetBSD 7.99.1 (DRMKMS) #1: Fri Aug 15 14:06:51 BST 2014 root@support6.delcam.local:/root/a64/compile/DRMKMS amd64 $ ls -l /usr/libdata/firmware/radeon/R300_cp.bin -r--r--r-- 1 root wheel 2048 Jul 6 2010 /usr/libdata/firmware/radeon/R300_cp.bin $ dmesg | grep Microcode drm: Loading R300 Microcode ... I tried a custom kernel with sources from yesterday on i386 with a R300 and it works fine. We really ought to have a better story if it's not, but that's my first guess about the problem. panic: kernel diagnostic assertion ttm-caching_state == tt_cached failed: file ../../../../external/bsd/drm2/dist/drm/ttm/ttm_tt.c, line 423 This is a bug in the rat's nest of error branches in the Radeon code, ugh... Well, it doesn't show up in the earlier version, so it looks a regression. The panic is triggered while cleaning up from the failure to load the microcode. One change between your working kernel and now was to enable wedges, they are disabled in my custom kernel. I have to say, this came to my mind as well. However, that machine has been using raidframe and wedges for ages: ~ df -k -t ffs Filesystem1K-blocks Used Avail %Cap Mounted on /dev/raid0a 105311462 31680686 68365204 31% / However, I have to notice that in the case of the working non-default-slice kernel, the root is not on a wedge, so there may be something about the order in which the wedges are recognized and the firmware loaded. Chavdar /dev/dk0 116306664 65608 110425728 0% /spare /dev/dk1 71674768 615579126533120 90% /data ~ raidctl -s raid0 Components: /dev/wd5a: optimal /dev/wd4a: optimal ... ~ raidctl -s raid1 Components: /dev/wd0a: optimal /dev/wd2a: optimal /dev/wd3a: optimal ... ~ gpt show raid0 start size index contents 0 234441472 ~ gpt show raid1 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 144607293 1 GPT part - NetBSD FFSv1/FFSv2 144607327 32 Sec GPT table 144607359 1 Sec GPT header ~ dkctl raid1 listwedges /dev/rraid1d: 1 wedge: dk1: 5b5a0ae5-1568-11e3-8834-000fea5d15a1, 144607293 blocks at 34, type: ffs (from the working kernel from 15th). Robert Swindells Chavdar -- --
