design problem with set lists
Hi! There is a problem with the set lists. Originally, they were just for listing the files that belong to foo.tgz. Later, checksums were added so they could be used for checking the contents on the file system still matched what was originally installed. However, many set lists contain the set list file itself, which can't work because the size and checksum are not available before it's filled in with other checksums and then you get a recursive problem, because its own checksum is supposed to be inside. So currently it most often looks like this: set.base:./etc/mtree/set.base type=file uname=root gname=wheel mode=0644 nlink=1 size=0 sha256=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 flags=none which does not match the data of the file on the file system, and sometimes it contains a size>0 and a different checksum. I see two solutions: a) do not include the set lists themselves b) remove the size and checksum parts for the set list files themselves from the set lists Comments? Thomas
daily CVS update output
Updating src tree: P src/distrib/sets/lists/base/shl.mi P src/distrib/sets/lists/debug/shl.mi P src/doc/CHANGES P src/doc/roadmaps/storage P src/external/gpl3/binutils/usr.sbin/mdsetimage/Makefile U src/external/gpl3/binutils/usr.sbin/mdsetimage/bin_bfd.c cvs update: `src/external/gpl3/binutils/usr.sbin/mdsetimage/mdsetimage.8' is no longer in the repository cvs update: `src/external/gpl3/binutils/usr.sbin/mdsetimage/mdsetimage.c' is no longer in the repository P src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h P src/external/mit/xorg/server/drivers/xf86-video-nv/Makefile P src/include/ifaddrs.h P src/lib/libc/shlib_version P src/lib/libc/arch/mips/gen/_resumecontext.S P src/lib/libc/arch/mips/gen/swapcontext.S P src/lib/libc/net/getifaddrs.3 P src/lib/libc/net/getifaddrs.c P src/lib/libm/Makefile P src/lib/libm/noieee_src/n_asincos.c U src/lib/libm/noieee_src/n_atanhf.c P src/share/man/man4/nvme.4 P src/share/man/man4/route.4 P src/sys/compat/common/Makefile U src/sys/compat/common/rtsock_70.c P src/sys/compat/net/if.h P src/sys/compat/net/route.h P src/sys/net/if.h P src/sys/net/route.h P src/sys/net/rtsock.c P src/sys/rump/net/lib/libnet/Makefile P src/sys/sys/param.h P src/sys/sys/socket.h P src/usr.sbin/ifwatchd/ifwatchd.c P src/usr.sbin/mdsetimage/Makefile U src/usr.sbin/mdsetimage/bin.h U src/usr.sbin/mdsetimage/bin_nlist.c P src/usr.sbin/mdsetimage/exec_aout.c P src/usr.sbin/mdsetimage/exec_coff.c P src/usr.sbin/mdsetimage/exec_ecoff.c P src/usr.sbin/mdsetimage/exec_elf32.c P src/usr.sbin/mdsetimage/extern.h P src/usr.sbin/mdsetimage/mdsetimage.8 P src/usr.sbin/mdsetimage/mdsetimage.c Updating xsrc tree: P xsrc/external/mit/xf86-video-nv/dist/src/g80_dma.c P xsrc/external/mit/xf86-video-nv/dist/src/g80_dma.h P xsrc/external/mit/xf86-video-nv/dist/src/g80_exa.c P xsrc/external/mit/xf86-video-nv/dist/src/g80_xaa.c P xsrc/external/mit/xf86-video-nv/dist/src/g80_xaa.h P xsrc/external/mit/xf86-video-nv/dist/src/riva_xaa.c P xsrc/external/mit/xfs/dist/os/xfstrans.c P xsrc/external/mit/xorg-server/include/dix-config.h P xsrc/external/mit/xorg-server/include/xorg-server.h P xsrc/external/mit/xorg-server.old/include/dix-config.h P xsrc/external/mit/xorg-server.old/include/xorg-server.h Killing core files: Running the SUP scanner: SUP Scan for current starting at Thu Sep 22 03:01:45 2016 SUP Scan for current completed at Thu Sep 22 03:02:02 2016 SUP Scan for mirror starting at Thu Sep 22 03:02:02 2016 SUP Scan for mirror completed at Thu Sep 22 03:04:12 2016 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 54669587 Sep 22 03:05 ls-lRA.gz
tools build is broken on amd64
With updated sources: In file included from /build/netbsd-local/src/tools/mdsetimage/../../external/gpl3/binutils/usr.sbin/mdsetimage/bin_bfd.c:33:0: /build/netbsd-local/tools/x86_64/amd64/include/compat/nbtool_config.h:656:0: warning: "PACKAGE_VERSION" redefined #define PACKAGE_VERSION "noversion" ^ :0:0: note: this is the location of the previous definition /build/netbsd-local/src/tools/mdsetimage/../../external/gpl3/binutils/usr.sbin/mdsetimage/bin_bfd.c:44:17: fatal error: bin.h: No such file or directory compilation terminated. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
WANTED: nvme(4) driver testing on MP systems on -current
Hello, NVMe driver in NetBSD-current was recently tweaked to fix several MP and locking issues, and the driver is now marked as MPSAFE by default. Most of this work was done on emulators since I lack the the hardware, so it's not clear if everything would work properly on real systems too. Anyone having the hardware, I'd appreciate if you could check the driver out, and try to punish the drive by some heavy I/O test with parallel load if possible, and report results. The driver should work on i386 and amd64, and is enabled in INSTALL/GENERIC kernels there, so you could just try to boot install iso from NetBSD daily builds, and send-pr any issues. I'd also especially welcome if someone with sparc64 system could test the driver out, too. The driver originates from OpenBSD where nvme(4) is enabled in GENERIC sparc64 kernel, so it should work. But it was not confirmed yet on NetBSD/sparc64. Note you might need fairly modern system, at least some Intel NVMe cards require PCIe Generation 3 to actually work, so this rules out e.g. T1s. I'd also very welcome any benchmark results, it would be very interesting to share some IOPS figures. Let me know the results, I'd like to update driver manpage to list known working hardware. In any reports, please include the attachment fragment from dmesg, as there is quite significant different between attachment via apic/INTx and MSI/MSI-X. Also useful would be intrctl(8) output, to confirm interrupt handlers are dispatched properly to individual available CPUs. Thank you. Jaromir
Re: USB serial problems
On Sep 21, 10:30am, Thomas Klausner wrote: } } I wanted to look at the serial console of a second machine, so I } plugged in a USB serial dongle into my NetBSD (7.99.38/amd64): } } uftdi0 at uhub4 port 3 } uftdi0: FTDI FT232R USB UART, rev 2.00/6.00, addr 3 } ucom0 at uftdi0 portno 1 } } Then I looked at ucom(4) and saw that the first mentioned entry is } /dev/dtyU?, so I set up 'minicom -s' using that device. Then I } connected using minicom. The screen stayed empty, and the process was } unkillable. I also tried 'cu -l /dev/dtyU0' which had the same result. } (Even though there should have been something visible on the serial } line.) Use /dev/ttyU0 for that purpose. dty devices are for dialup. }-- End of excerpt from Thomas Klausner
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 2016.09.21.10.54.36. An extract from the build.sh output follows: /tmp/bracket/build/2016.09.21.10.54.36-i386/tools/bin/i486--netbsdelf-gcc -O2 -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wold-style-definition -Wsign-compare -Wformat=2 -Wno-format-zero-length -Werror -fPIE -fstack-protector -Wstack-protector --param ssp-buffer-size=1 --sysroot=/tmp/bracket/build/2016.09.21.10.54.36-i386/destdir -D_LIBC -DLIBC_SCCS -DSYSLIBC_SCCS -D_REENTRANT -D_DIAGNOSTIC -DHESIOD -DINET6 -DNLS -DYP -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc/include -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/sys -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc/compat/../locale -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc/compat/stdlib -I/tmp/bracket/build/2016.09.21.1 0.54.36-i386/src/lib/libc/compat/../stdlib -D__BUILD_LEGACY -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc/../../common/lib/libc/quad -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc/../../common/lib/libc/string -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc/../../common/lib/libc/arch/i386/string -D__DBINTERFACE_PRIVATE -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/libexec/ld.elf_so -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc/dlfcn -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc/gdtoa -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc/locale -DNO_FENV_H -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc/arch/i386/gdtoa -DWITH_RUNE -I/tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc -DPOSIX_MISTAKE -DCOMPAT__RES -DUSE_POLL -DPORTMAP -DWIDE_DOUBLE -DALL_STATE -DUSG_COMPAT -D_FORTIFY_SOURCE=2 -c /tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc/net/getservbyname.c -o getservbyname.o --- getservbyport.o --- # compile libc/getservbyport.o --- getifaddrs.o --- /tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc/net/getifaddrs.c: In function '_getifaddrs': /tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc/net/getifaddrs.c:228:7: error: 'struct ifaddrs' has no member named 'ifa_addrflags' ift->ifa_addrflags = ifam->ifam_addrflags; ^ --- getpeereid.o --- /tmp/bracket/build/2016.09.21.10.54.36-i386/tools/bin/nbctfconvert -g -L VERSION getpeereid.o /tmp/bracket/build/2016.09.21.10.54.36-i386/tools/bin/i486--netbsdelf-objcopy -x getpeereid.o --- getifaddrs.o --- *** [getifaddrs.o] Error code 1 nbmake[7]: stopped in /tmp/bracket/build/2016.09.21.10.54.36-i386/src/lib/libc --- getprotobynumber_r.o --- The following commits were made between the last successful build and the failed build: 2016.09.21.10.52.13 roy src/sys/sys/param.h,v 1.505 2016.09.21.10.53.24 roy src/lib/libc/net/getifaddrs.3,v 1.17 2016.09.21.10.53.24 roy src/lib/libc/net/getifaddrs.c,v 1.16 2016.09.21.10.54.36 roy src/lib/libc/shlib_version,v 1.268 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2016.09.html#2016.09.21.10.54.36
Re: USB serial problems
Thomas Klausner writes: > I wanted to look at the serial console of a second machine, so I > plugged in a USB serial dongle into my NetBSD (7.99.38/amd64): > > uftdi0 at uhub4 port 3 > uftdi0: FTDI FT232R USB UART, rev 2.00/6.00, addr 3 > ucom0 at uftdi0 portno 1 Beware the the word floating around on the Interwebs is that there are a lot of counterfeit FTDI chipsets out there. Apparently they mostly work, and the angst is around how official binary FTDI drivers behave. Probably this is not your issue. > Then I looked at ucom(4) and saw that the first mentioned entry is > /dev/dtyU?, so I set up 'minicom -s' using that device. Then I > connected using minicom. The screen stayed empty, and the process was > unkillable. I also tried 'cu -l /dev/dtyU0' which had the same result. > (Even though there should have been something visible on the serial > line.) dtyU0 is the right file. ttyU0 and dtyU0 are for the same device, but dty is a dialout device that does not block waiting for carrier detect, vs tty that by default blocks opening until CD is asserted. (Back when I was young, we had 300 baud modems, with dialin from terminals and dialout for uucp!) I've done what you describe with usb/serial dongles, often with uplcom. > At the same time, the USB keyboard and USB mouse stopped working, > without anything visible in dmesg. > > I wanted other processes to finish before rebooting, so I waited. > > 4 hours later I saw the following in the kernel log: > ehci_sync_hc: cv_timedwait() = 35 > > 4 hours later I tried rebooting, but had to press the reset button, > 'shutdown -r' didn't work. > > Should I have used /dev/ttyU0 instead? > > I find it worrying that the USB mouse and keyboard stopped working > without any kernel messages, and that the processes hung unkillably. I think you are running into either really serious bugs in our kernel, or a broken device that is causing way more trouble than it should Did you remove the serial dongle? I have found that at times, pulling a troublesome USB device resolves things. Did you try on a netbsd-7 system? signature.asc Description: PGP signature
Re: USB serial problems
Thomas Klausner writes: > Should I have used /dev/ttyU0 instead? I've recently experienced exactly the same thing, on i386 and amd64 systems, current as of about a month ago, using /dev/ttyU0. On the (slow) i386 system, it would happen every time I tried to use the USB serial port. On the (faster) amd64 system, only occasionally. The lockup of USB occurs immediately on opening the device. -tih -- Elections cannot be allowed to change anything. --Dr. Wolfgang Schäuble
USB serial problems
Hi! I wanted to look at the serial console of a second machine, so I plugged in a USB serial dongle into my NetBSD (7.99.38/amd64): uftdi0 at uhub4 port 3 uftdi0: FTDI FT232R USB UART, rev 2.00/6.00, addr 3 ucom0 at uftdi0 portno 1 Then I looked at ucom(4) and saw that the first mentioned entry is /dev/dtyU?, so I set up 'minicom -s' using that device. Then I connected using minicom. The screen stayed empty, and the process was unkillable. I also tried 'cu -l /dev/dtyU0' which had the same result. (Even though there should have been something visible on the serial line.) At the same time, the USB keyboard and USB mouse stopped working, without anything visible in dmesg. I wanted other processes to finish before rebooting, so I waited. 4 hours later I saw the following in the kernel log: ehci_sync_hc: cv_timedwait() = 35 4 hours later I tried rebooting, but had to press the reset button, 'shutdown -r' didn't work. Should I have used /dev/ttyU0 instead? I find it worrying that the USB mouse and keyboard stopped working without any kernel messages, and that the processes hung unkillably. Suggestions? Thanks, Thomas
