daily CVS update output
Updating src tree: P src/distrib/sets/lists/tests/mi P src/lib/libcurses/addbytes.c P src/sys/arch/algor/conf/std.algor64 P src/sys/arch/x86/pci/amdzentemp.c P src/sys/dev/ipmi.c P src/sys/dev/iscsi/iscsi_main.c P src/sys/dev/iscsi/iscsi_send.c P src/sys/dev/usb/xhci.c P src/tests/lib/libcurses/check_files/Makefile U src/tests/lib/libcurses/check_files/addstr2.chk U src/tests/lib/libcurses/check_files/addstr3.chk U src/tests/lib/libcurses/check_files/slk1.chk U src/tests/lib/libcurses/check_files/slk3.chk U src/tests/lib/libcurses/check_files/slk5.chk U src/tests/lib/libcurses/check_files/slk6.chk U src/tests/lib/libcurses/check_files/slk_init.chk P src/tests/lib/libcurses/tests/addstr P src/tests/lib/libcurses/tests/slk Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): P distrib/miniroot/install.sub U doc/CHANGES-8.3 P sys/arch/hp300/conf/INSTALL P sys/dev/pci/if_iwmreg.h Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): P distrib/miniroot/install.sub U doc/CHANGES-9.3 P sys/arch/arm/arm32/arm32_boot.c P sys/arch/hp300/conf/INSTALL P sys/dev/pci/if_iwmreg.h Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 41354894 Jun 7 03:10 ls-lRA.gz
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.06.06.11.35.22 nonaka src/sys/arch/x86/pci/amdzentemp.c,v 1.14 2021.06.06.11.48.55 mlelstv src/sys/dev/ipmi.c,v 1.6 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2021.06.html#2021.06.06.11.48.55
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.06.06.08.45.18. An extract from the build.sh output follows: nbmake[6]: stopped in /tmp/build/2021.06.06.08.45.18-i386/src/external/gpl3 --- dependall-gdb --- nbmake[9]: stopped in /tmp/build/2021.06.06.08.45.18-i386/src/external/gpl3/gdb/lib/libgdb nbmake[8]: stopped in /tmp/build/2021.06.06.08.45.18-i386/src/external/gpl3/gdb/lib nbmake[7]: stopped in /tmp/build/2021.06.06.08.45.18-i386/src/external/gpl3/gdb nbmake[6]: stopped in /tmp/build/2021.06.06.08.45.18-i386/src/external/gpl3 nbmake[5]: stopped in /tmp/build/2021.06.06.08.45.18-i386/src/external nbmake[4]: stopped in /tmp/build/2021.06.06.08.45.18-i386/src nbmake[3]: stopped in /tmp/build/2021.06.06.08.45.18-i386/src nbmake[2]: stopped in /tmp/build/2021.06.06.08.45.18-i386/src nbmake[1]: stopped in /tmp/build/2021.06.06.08.45.18-i386/src nbmake: stopped in /tmp/build/2021.06.06.08.45.18-i386/src ERROR: Failed to make release The following commits were made between the last successful build and the failed build: 2021.06.06.08.45.18 nonaka src/sys/arch/x86/pci/amdzentemp.c,v 1.13 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2021.06.html#2021.06.06.08.45.18
Re: dump/restore out of range inode
> On 6. Jun 2021, at 10:10, Patrick Welche wrote: > > On Sat, Jun 05, 2021 at 06:45:24PM +0200, J. Hannken-Illjes wrote: >> Patrick, >> >> please try the attached diff so the "spcl.c_addr" test >> no longer runs off the spcl record. >> >> "blks" is used for multi-tape checkpointing and examining >> TS_INODE/TS_ADDR records should be sufficient as the are >> the only records that support holes in data. > > Thanks! With your patch, the dump | restore has been happily > running for about 12 hours now. Ok, will commit and request pullup next week. > In your previous email you mention: > >> This trace makes no sense, bitmaps (CLRI and BITS) don't have holes >> and therefore ignore the "c_addr" array. I have no idea how dumping >> a bitmap ends in the hole processing of flushtape(). > > Is it worth investigating further while I have the reproducer? No, this is an error that manifests on file systems with many inodes and therefore did not raise before. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig signature.asc Description: Message signed with OpenPGP
Re: dump/restore out of range inode
On Sat, Jun 05, 2021 at 06:45:24PM +0200, J. Hannken-Illjes wrote: > Patrick, > > please try the attached diff so the "spcl.c_addr" test > no longer runs off the spcl record. > > "blks" is used for multi-tape checkpointing and examining > TS_INODE/TS_ADDR records should be sufficient as the are > the only records that support holes in data. Thanks! With your patch, the dump | restore has been happily running for about 12 hours now. In your previous email you mention: > This trace makes no sense, bitmaps (CLRI and BITS) don't have holes > and therefore ignore the "c_addr" array. I have no idea how dumping > a bitmap ends in the hole processing of flushtape(). Is it worth investigating further while I have the reproducer? Cheers, Patrick
