Crash with HEAD on amd64 - in setrunnable()
With a very current kernel, I just got this: # crash -M /var/crash/netbsd.21.core -N /netbsd.gdb Crash version 9.99.18, image version 9.99.18. System panicked: kernel diagnostic assertion "lwp_locked(l, l->l_cpu->ci_schedstate.spc_lwplock)" failed: file "/build/netbsd-local/src_ro/sys/kern/kern_synch.c", line 910 Backtrace from time of crash is available. crash> bt _KERNEL_OPT_NVGA_RASTERCONSOLE() at 0 ?() at de890ce0af54 vpanic() at vpanic+0x181 kern_assert() at kern_assert+0x48 setrunnable() at setrunnable+0x179 lwp_start() at lwp_start+0xba do_lwp_create() at do_lwp_create+0xa1 sys__lwp_create() at sys__lwp_create+0xc1 syscall() at syscall+0x28a --- syscall (number 309) --- 45ae46: crash> (Obviously, I have a core dump, so I'll be happy to investigate further if anyone has suggestions.) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
firefox dumping core after NetBSD upgrade
I recently upgraded my system from 9.99.4 to 9.99.15, and I've noticed
that firefox is repeatedly dumping core. I haven't found the specific
trigger yet, but...
* The host system is a NetBSD amd64
* firefox 69.0.1 (and all of its dependencies) was build from pkgsrc,
while the host was still running 9.99.4
I don't have debug symbols available, but I was able to get a stack
back-trace using gdb; hopefully someone might recognize what the
problem is...
Core was generated by `firefox'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7af20d009a7b in _atomic_cas_ptr (new=, old=0x0,
ptr=0x7af20d3cb730)
at /build/netbsd-local/src_ro/lib/libpthread/arch/x86_64/pthread_md.h:77
77 __asm __volatile ("lock; cmpxchgq %2, %1"
[Current thread is 1 (process 1)]
(gdb)
(gdb) bt
#0 0x7af20d009a7b in _atomic_cas_ptr (new=, old=0x0,
ptr=0x7af20d3cb730)
at /build/netbsd-local/src_ro/lib/libpthread/arch/x86_64/pthread_md.h:77
#1 pthread_mutex_lock (ptm=ptm@entry=0x7af20d3cb720)
at /build/netbsd-local/src_ro/lib/libpthread/pthread_mutex.c:201
#2 0x7af1ec643f74 in mtx_lock (mtx=0x7af20d3cb720)
at
/build/netbsd-local/xsrc_ro/external/mit/MesaLib/dist/include/c11/threads_posix.h:223
#3 simple_mtx_lock (mtx=0x7af20d3cb720)
at
/build/netbsd-local/xsrc_ro/external/mit/MesaLib/dist/src/util/simple_mtx.h:125
#4 _mesa_error (ctx=ctx@entry=0x7af20d3b9868, error=error@entry=1282,
fmtString=fmtString@entry=0x7af1ee415f84 "Inside glBegin/glEnd")
at
/build/netbsd-local/xsrc_ro/external/mit/MesaLib/dist/src/mesa/main/errors.c:309
#5 0x7af1ec65e256 in _mesa_GetString (name=7938)
at
/build/netbsd-local/xsrc_ro/external/mit/MesaLib/dist/src/mesa/main/getstring.c:124
#6 0x7af1fbdd534d in ?? () from /usr/pkg/lib/firefox/libxul.so
#7 0x7af1fbdd5828 in ?? () from /usr/pkg/lib/firefox/libxul.so
#8 0x7af1fbdcb6a4 in ?? () from /usr/pkg/lib/firefox/libxul.so
#9 0x7af1fbdd2df8 in ?? () from /usr/pkg/lib/firefox/libxul.so
#10 0x7af1fbdd3649 in ?? () from /usr/pkg/lib/firefox/libxul.so
#11 0x00012e805f57 in _start ()
(gdb)
++--+-------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Recent if_stat changes have broken sysutils/xosview
The package no longer builds. Fails with (among others) error: 'struct ifnet' has no member named 'if_ibytes'; did you mean 'if_index'? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Bad system call errors during an upgrade of -current
On Tue, 11 Feb 2020, Kamil Rytarowski wrote: Another question is whether your kernel config contains compat glue for old syscalls. It would also be nice to find out which syscall(s) are missing. Can you use ktrace/kdump (or ktruss) to find out which syscall is returning ENOSYS (error number 78). On 11.02.2020 02:07, Dustin Marquess wrote: Looking at my history, I did: ./build.sh -O ../obj -T ../tools tools distribution kernel=MYCONFIG modules ./build.sh -O ../obj -T ../tools installmodules=/ cp -p /netbsd /onetbsd cp /usr/obj/sys/arch/amd64/compile/MYCONFIG/netbsd / shutdown -r now /stand still has modules for both versions listed. Went go to install the new userland after the reboot and it never got that far since things started crashing. Rebooting back into onetbsd seems to work, so I'm fairly certain that it didn't upgrade the userland yet, but I'll double check. On a side note, it would be really nice if the modules stuff got added to https://www.netbsd.org/docs/guide/en/chap-updating.html#updating-procedure so I don't have to keep referring to my old notes every time :) -Dustin On Mon, Feb 10, 2020 at 6:57 PM Kamil Rytarowski wrote: On 11.02.2020 01:49, Dustin Marquess wrote: I'm trying to upgrade a VM from a 9.99.10 install that was built around Sep 2th to a 9.99.46 install compiled yesterday. I installed the new kernel and modules and rebooted into the new kernel / old userland. Once done, almost everything crashes with Bad system call. So far "su -", "ls" and even the configure instance the a build.sh install kicked off died with one. Is this a known issue? I don't believe I missed a step in the upgrade instructions... Thanks! -Dustin Make sure that you upgraded your kernel and kernel modules before installing new userland. The otherway around upgrade is not supported and can break like it (there was an ABI change in struct statvfs). ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Bad system call errors during an upgrade of -current
As Robert Elz said in previous reply, you're most likely missing some compatability code. Since you initially indicated that it worked on 9.99.10, you most likely don't have COMPAT_90 in your config. COMPAT_90 brings in stuff for compatability with the 9.0 release. The contents of COMPAT_90 will grow as new ABI changes occur, but these changes in content don't result in changes to the kernel configuration description files such as GENERIC or ALL. The ABI changes are sort of buried inside the kernel configuration _definition_ files, typically named src/sys/.../files* :) For a quick test, just add ``options COMPAT_90'' to your MYCONFIG kernel description. On Mon, 10 Feb 2020, Dustin Marquess wrote: So as part of my nasty process, after I do a 'cvs update', I diff the old GENERIC and the new GENERIC and look for any major changes and then replicate those into my local config file. The only config changes I saw where for the various *san(itiziers). I'll attempt to reproduce on GENERIC, and if I can reproduce it, I'll try and ktrace/kdump/ktruss to figure out where it's broken. Thanks all, -Dustin On Mon, Feb 10, 2020 at 9:28 PM Robert Elz wrote: Date:Mon, 10 Feb 2020 19:07:50 -0600 From:Dustin Marquess Message-ID: | Looking at my history, I did: | | ./build.sh -O ../obj -T ../tools tools distribution kernel=MYCONFIG modules As Kamil suggested, this will be your problem. To start with, use a GENERIC kernel which will have all the correct COMPAT_xxx options defined. Once you have the new userland installed you can build your own tailored kernel and run that. You can also add the needed COMPAT_xxx options to your kernel config file, but doing it that way can take more try & retry until you finally get everything needed. kre !DSPAM:5e42233b188721095115340! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Build broken for amd64 - rump vs tests/dev/audio
With sources updated as of 2020-03-01 at 22:13:02 UTC # link audio/audiotest /build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-gcc --sysroot=/build/netbsd-compat/dest/amd64 -Wl,--warn-shared-textrel -Wl,-z,relro -pie -shared-libgcc -o audiotest audiotest.o -Wl,-rpath-link,/build/netbsd-compat/dest/amd64/lib -L=/lib -lrumpdev_pad -lrumpdev_audio -lrumpvfs -lrump -lrumpvfs -lrumpuser -lrump -lpthread-lutil /build/netbsd-compat/tools/x86_64/amd64/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld: /build/netbsd-compat/dest/amd64/usr/lib/librumpdev_pad.so: undefined reference to `rumpns_pmf_device_deregister' /build/netbsd-compat/tools/x86_64/amd64/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld: /build/netbsd-compat/dest/amd64/usr/lib/librumpdev_audio.so: undefined reference to `rumpns_pmf_event_deregister' /build/netbsd-compat/tools/x86_64/amd64/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld: /build/netbsd-compat/dest/amd64/usr/lib/librumpdev_audio.so: undefined reference to `rumpns_pmf_event_register' /build/netbsd-compat/tools/x86_64/amd64/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld: /build/netbsd-compat/dest/amd64/usr/lib/librumpdev_pad.so: undefined reference to `rumpns_pmf_device_register1' collect2: error: ld returned 1 exit status ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error for port-sparc
OK, this turns out to be a problem only for building with MKPAM=0 If I enable PAM, it builds correctly. On Tue, 3 Mar 2020, Paul Goyette wrote: And with even more recent sources (updated on 2020-03-04 at 02:52:55 UTC), I'm getting an error even earlier in the build: dependall ===> external/bsd/pam-u2f/bin/pamu2fcfg #create pamu2fcfg/explicit_bzero.d CC=/build/netbsd-compat/tools/x86_64/sparc/bin/sparc--netbsdelf-gcc /build/netbsd-compat/tools/x86_64/sparc/bin/nbmkdep -f explicit_bzero.d.tmp -- -std=gnu99 --sysroot=/build/netbsd-compat/dest/sparc -I/build/netbsd-compat/src_ro/external/bsd/pam-u2f/dist -I/build/netbsd-compat/src_ro/external/bsd/pam-u2f/bin/pamu2fcfg -DPACKAGE='"pam_u2f"' -DVERSION='"1.0.9"' -DHAVE_UNISTD_H /build/netbsd-compat/src_ro/external/bsd/pam-u2f/dist/explicit_bzero.c && mv -f explicit_bzero.d.tmp explicit_bzero.d In file included from /build/netbsd-compat/src_ro/external/bsd/pam-u2f/dist/explicit_bzero.c:16: /build/netbsd-compat/src_ro/external/bsd/pam-u2f/dist/util.h:9:10: fatal error: security/pam_appl.h: No such file or directory #include ^ compilation terminated. nbmkdep: compile failed. *** [explicit_bzero.d] Error code 1 Again, I'm seeing this _only_ for sparc. I've done ``build.sh release'' for literally dozens of other $ARCH without any problems. Anyone got a clue? On Tue, 3 Mar 2020, Paul Goyette wrote: With sources updated on 2020-03-02 at 13:13:48 UTC I am getting the following build error when doing a ``build.sh release'' # compile ramdisk/gethost.o /build/netbsd-compat/tools/x86_64/sparc/bin/sparc--netbsdelf-gcc -Os -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Werror --sysroot=/build/netbsd-compat/dest/sparc -DSMALL -DLIBHACK -D_REENTRANT -c -I/build/netbsd-compat/src_ro/distrib/utils/libhack/../../../lib/libc/net /build/netbsd-compat/src_ro/distrib/utils/libhack/gethost.c /build/netbsd-compat/src_ro/distrib/utils/libhack/gethost.c:76:1: error: function declaration isn't a prototype [-Werror=strict-prototypes] int h_errno; ^~~ cc1: all warnings being treated as errors ++------+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++------+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++------+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Minor anomaly with -current
On my "production" amd64 system running 9.99.42, if I log in on the console as root I get one log message: Mar 2 07:40:40 login: ROOT LOGIN (root) on tty constty However, if I creatae a 9.99.48 vm using qemu, I get two messages! Mar 2 15:21:23 login: ROOT LOGIN (root) on tty constty Mar 2 15:21:23 login: ROOT LOGIN (root) ON constty Note also the subtle difference - the additional message has done the equivalent of s/on tty//ON/ :) Both systems have the following in /etc/ttys: console "/usr/libexec/getty Pc" vt100 off secure constty "/usr/libexec/getty Pc" vt100 on secure It's obviously not a big problem, just something I noticed. ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error for port-sparc
And with even more recent sources (updated on 2020-03-04 at 02:52:55 UTC), I'm getting an error even earlier in the build: dependall ===> external/bsd/pam-u2f/bin/pamu2fcfg #create pamu2fcfg/explicit_bzero.d CC=/build/netbsd-compat/tools/x86_64/sparc/bin/sparc--netbsdelf-gcc /build/netbsd-compat/tools/x86_64/sparc/bin/nbmkdep -f explicit_bzero.d.tmp -- -std=gnu99 --sysroot=/build/netbsd-compat/dest/sparc -I/build/netbsd-compat/src_ro/external/bsd/pam-u2f/dist -I/build/netbsd-compat/src_ro/external/bsd/pam-u2f/bin/pamu2fcfg -DPACKAGE='"pam_u2f"' -DVERSION='"1.0.9"' -DHAVE_UNISTD_H /build/netbsd-compat/src_ro/external/bsd/pam-u2f/dist/explicit_bzero.c && mv -f explicit_bzero.d.tmp explicit_bzero.d In file included from /build/netbsd-compat/src_ro/external/bsd/pam-u2f/dist/explicit_bzero.c:16: /build/netbsd-compat/src_ro/external/bsd/pam-u2f/dist/util.h:9:10: fatal error: security/pam_appl.h: No such file or directory #include ^ compilation terminated. nbmkdep: compile failed. *** [explicit_bzero.d] Error code 1 Again, I'm seeing this _only_ for sparc. I've done ``build.sh release'' for literally dozens of other $ARCH without any problems. Anyone got a clue? On Tue, 3 Mar 2020, Paul Goyette wrote: With sources updated on 2020-03-02 at 13:13:48 UTC I am getting the following build error when doing a ``build.sh release'' # compile ramdisk/gethost.o /build/netbsd-compat/tools/x86_64/sparc/bin/sparc--netbsdelf-gcc -Os -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Werror --sysroot=/build/netbsd-compat/dest/sparc -DSMALL -DLIBHACK -D_REENTRANT -c -I/build/netbsd-compat/src_ro/distrib/utils/libhack/../../../lib/libc/net /build/netbsd-compat/src_ro/distrib/utils/libhack/gethost.c /build/netbsd-compat/src_ro/distrib/utils/libhack/gethost.c:76:1: error: function declaration isn't a prototype [-Werror=strict-prototypes] int h_errno; ^~~ cc1: all warnings being treated as errors ++------+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++------+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
config(1) warning for amd64 release
++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ -- Forwarded message -- Date: Sat, 25 Jan 2020 10:53:45 -0800 (PST) From: Paul Goyette To: p...@whooppee.com Subject: ../BUILD -Z3 -TurdJ1 -N2 -S src -e VPS1 -e TEST With sources updated as of updated Sat Jan 25 16:18:15 UTC 2020 $SRC/sys/dev/files.audio:3: warning: The use of `defopt' is deprecated
Re: config(1) warning for amd64 release
On Sat, 25 Jan 2020, Paul Goyette wrote: With sources updated as of updated Sat Jan 25 16:18:15 UTC 2020 $SRC/sys/dev/files.audio:3: warning: The use of `defopt' is deprecated I just saw jmcneill's commit to fix this - thanks! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
USB umass hard drive "failed to create xfers" when attaching
With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC I get the following errors when plugging in a USB hard drive: umass0 at uhub1 port 2 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 32 umass0: using SCSI over Bulk-Only umass0: autoconfiguration error: failed to create xfers This worked correctly with a 9.99.42 kernel built from sources dated 2020-01-25 19:35:05 UTC Anyone got any clues on how this got broke? Or how to fix? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: USB umass hard drive "failed to create xfers" when attaching
On Mon, 17 Feb 2020, Paul Goyette wrote: With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC I get the following errors when plugging in a USB hard drive: umass0 at uhub1 port 2 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 32 umass0: using SCSI over Bulk-Only umass0: autoconfiguration error: failed to create xfers This worked correctly with a 9.99.42 kernel built from sources dated 2020-01-25 19:35:05 UTC When it was working, this is what dmesg reported: umass0 at uhub1 port 1 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 6 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: disk fixed sd0: fabricating a geometry sd0: 1863 GB, 1907727 cyl, 64 head, 32 sec, 512 bytes/sect x 3907024896 sectors sd0: fabricating a geometry Anyone got any clues on how this got broke? Or how to fix? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: USB umass hard drive "failed to create xfers" when attaching
On Mon, 17 Feb 2020, Paul Goyette wrote: On Mon, 17 Feb 2020, Paul Goyette wrote: With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC I get the following errors when plugging in a USB hard drive: umass0 at uhub1 port 2 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 32 umass0: using SCSI over Bulk-Only umass0: autoconfiguration error: failed to create xfers This worked correctly with a 9.99.42 kernel built from sources dated 2020-01-25 19:35:05 UTC When it was working, this is what dmesg reported: umass0 at uhub1 port 1 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 6 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: disk fixed sd0: fabricating a geometry sd0: 1863 GB, 1907727 cyl, 64 head, 32 sec, 512 bytes/sect x 3907024896 sectors sd0: fabricating a geometry Anyone got any clues on how this got broke? Or how to fix? More info... First, this is on a amd64 system, witwh 8core/16thread and 128GB of RAM. On IRC it was suggested (thanks, maya!) that the error message might be related to memory fragmentation. I didn't believe it (given how much RAM I have), but a quick check with top(1) showed that I had more than 100GB of 'file cache' active. So, I unmounted all my development trees (to force the cache to get flushed). Sure enough, I am now able to successfully mount the USB drive! So, sounds like "something somewhere isn't quite right (tm)". I would have expected a memory allocation failure to automatically trigger some mechanism to reclaim some of the file cache... ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: USB umass hard drive "failed to create xfers" when attaching
With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC I get the following errors when plugging in a USB hard drive: umass0 at uhub1 port 2 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 32 umass0: using SCSI over Bulk-Only umass0: autoconfiguration error: failed to create xfers This worked correctly with a 9.99.42 kernel built from sources dated 2020-01-25 19:35:05 UTC When it was working, this is what dmesg reported: umass0 at uhub1 port 1 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 6 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: disk fixed sd0: fabricating a geometry sd0: 1863 GB, 1907727 cyl, 64 head, 32 sec, 512 bytes/sect x 3907024896 sectors sd0: fabricating a geometry Anyone got any clues on how this got broke? Or how to fix? More info... First, this is on a amd64 system, witwh 8core/16thread and 128GB of RAM. On IRC it was suggested (thanks, maya!) that the error message might be related to memory fragmentation. I didn't believe it (given how much RAM I have), but a quick check with top(1) showed that I had more than 100GB of 'file cache' active. So, I unmounted all my development trees (to force the cache to get flushed). Sure enough, I am now able to successfully mount the USB drive! So, sounds like "something somewhere isn't quite right (tm)". I would have expected a memory allocation failure to automatically trigger some mechanism to reclaim some of the file cache... And, based on more discussion, this would seem to be a kernel virtual address fragmentation issue, and not related to physical memory being available. The concensus on IRC is that this is a bug in the xhci(4) driver. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: USB umass hard drive "failed to create xfers" when attaching
This is now PR kern/54997 On Mon, 17 Feb 2020, Paul Goyette wrote: With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC I get the following errors when plugging in a USB hard drive: umass0 at uhub1 port 2 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 32 umass0: using SCSI over Bulk-Only umass0: autoconfiguration error: failed to create xfers This worked correctly with a 9.99.42 kernel built from sources dated 2020-01-25 19:35:05 UTC When it was working, this is what dmesg reported: umass0 at uhub1 port 1 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 6 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: disk fixed sd0: fabricating a geometry sd0: 1863 GB, 1907727 cyl, 64 head, 32 sec, 512 bytes/sect x 3907024896 sectors sd0: fabricating a geometry Anyone got any clues on how this got broke? Or how to fix? More info... First, this is on a amd64 system, witwh 8core/16thread and 128GB of RAM. On IRC it was suggested (thanks, maya!) that the error message might be related to memory fragmentation. I didn't believe it (given how much RAM I have), but a quick check with top(1) showed that I had more than 100GB of 'file cache' active. So, I unmounted all my development trees (to force the cache to get flushed). Sure enough, I am now able to successfully mount the USB drive! So, sounds like "something somewhere isn't quite right (tm)". I would have expected a memory allocation failure to automatically trigger some mechanism to reclaim some of the file cache... And, based on more discussion, this would seem to be a kernel virtual address fragmentation issue, and not related to physical memory being available. The concensus on IRC is that this is a bug in the xhci(4) driver. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ !DSPAM:5e4abe59169311060514377! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: USB umass hard drive "failed to create xfers" when attaching
On Mon, 17 Feb 2020, Michael van Elst wrote: p...@whooppee.com (Paul Goyette) writes: So, sounds like "something somewhere isn't quite right (tm)". I would have expected a memory allocation failure to automatically trigger some mechanism to reclaim some of the file cache... It's not the file cache. Freeing the file cache however also cleans up other data structures in KVA space and that helps. Something that almost always helps is to reduce the value of the kernel variable desiredvnodes (you may restore it a few seconds later). Would that be ``sysctl kern.maxvnodes'' or some other variable? Since free memory is not the problem, none of this is triggered automatically. Got it. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Recent if_stat changes have broken sysutils/xosview
On Sun, 9 Feb 2020, Roy Marples wrote: "struct ifnet" is private to the kernel. This application should be using the properly exported data that's available via ioctls for this purpose. We have far too many kernel only things exposed to userland. Totally agree. A constant beef of mine is that we #define if_type in sys/net/if.h which causes conflict building hostapd/wpa_supplicant has they have an enum if_type. If we can resolve this it would make me a lot happier! I tried to have a go solving this about a year ago, but gave up due to some userland stuff like this no longer working. If we can solve it via ioctl then awesome. For now I am simply commenting out the network stuff completely, since I don't use that part of xosview. A proper solution is far beyond me. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 build failure
.50 jmcneill src/sys/dev/acpi/acpi.c,v 1.282 2019.12.31.12.27.50 jmcneill src/sys/dev/acpi/acpi_resource.c,v 1.39 2019.12.31.12.27.50 jmcneill src/sys/dev/acpi/acpivar.h,v 1.79 2019.12.31.12.40.27 ad src/sys/arch/hppa/hppa/pmap.c,v 1.102 2019.12.31.12.40.27 ad src/sys/arch/x86/x86/pmap.c,v 1.349 2019.12.31.12.40.27 ad src/sys/miscfs/genfs/genfs_io.c,v 1.82 2019.12.31.12.40.27 ad src/sys/rump/librump/rumpkern/vm.c,v 1.178 2019.12.31.12.40.27 ad src/sys/uvm/uvm_page.c,v 1.218 2019.12.31.12.40.27 ad src/sys/uvm/uvm_page.h,v 1.91 2019.12.31.12.40.27 ad src/sys/uvm/uvm_pdaemon.c,v 1.120 2019.12.31.12.40.27 ad src/sys/uvm/uvm_pdpolicy_clock.c,v 1.26 2019.12.31.12.40.27 ad src/sys/uvm/uvm_pdpolicy_clockpro.c,v 1.21 2019.12.31.13.07.09 ad src/external/cddl/osnet/dist/uts/common/fs/zfs/arc.c,v 1.18 2019.12.31.13.07.09 ad src/sys/arch/alpha/alpha/machdep.c,v 1.357 2019.12.31.13.07.09 ad src/sys/arch/atari/atari/machdep.c,v 1.182 2019.12.31.13.07.10 ad src/sys/arch/cesfic/cesfic/machdep.c,v 1.70 2019.12.31.13.07.10 ad src/sys/arch/emips/emips/machdep.c,v 1.15 2019.12.31.13.07.10 ad src/sys/arch/evbppc/explora/machdep.c,v 1.39 2019.12.31.13.07.10 ad src/sys/arch/evbppc/virtex/machdep.c,v 1.24 2019.12.31.13.07.10 ad src/sys/arch/evbppc/walnut/machdep.c,v 1.58 2019.12.31.13.07.10 ad src/sys/arch/ews4800mips/ews4800mips/machdep.c,v 1.30 2019.12.31.13.07.10 ad src/sys/arch/hp300/hp300/machdep.c,v 1.232 2019.12.31.13.07.10 ad src/sys/arch/hppa/hppa/machdep.c,v 1.12 2019.12.31.13.07.10 ad src/sys/arch/luna68k/luna68k/machdep.c,v 1.105 2019.12.31.13.07.11 ad src/sys/arch/mac68k/mac68k/machdep.c,v 1.357 2019.12.31.13.07.11 ad src/sys/arch/mips/mips/cpu_subr.c,v 1.44 2019.12.31.13.07.11 ad src/sys/arch/mvme68k/mvme68k/machdep.c,v 1.157 2019.12.31.13.07.11 ad src/sys/arch/news68k/news68k/machdep.c,v 1.106 2019.12.31.13.07.11 ad src/sys/arch/next68k/next68k/machdep.c,v 1.114 2019.12.31.13.07.11 ad src/sys/arch/powerpc/booke/booke_machdep.c,v 1.29 2019.12.31.13.07.11 ad src/sys/arch/powerpc/ibm4xx/ibm4xx_machdep.c,v 1.28 2019.12.31.13.07.11 ad src/sys/arch/powerpc/oea/oea_machdep.c,v 1.78 2019.12.31.13.07.12 ad src/sys/arch/riscv/riscv/riscv_machdep.c,v 1.8 2019.12.31.13.07.12 ad src/sys/arch/sgimips/sgimips/machdep.c,v 1.149 2019.12.31.13.07.12 ad src/sys/arch/sh3/sh3/sh3_machdep.c,v 1.109 2019.12.31.13.07.12 ad src/sys/arch/sparc/sparc/machdep.c,v 1.333 2019.12.31.13.07.12 ad src/sys/arch/sparc64/sparc64/machdep.c,v 1.297 2019.12.31.13.07.12 ad src/sys/arch/sun2/sun2/machdep.c,v 1.80 2019.12.31.13.07.12 ad src/sys/arch/sun3/sun3/machdep.c,v 1.211 2019.12.31.13.07.12 ad src/sys/arch/sun3/sun3x/machdep.c,v 1.138 2019.12.31.13.07.12 ad src/sys/arch/vax/vax/machdep.c,v 1.195 2019.12.31.13.07.13 ad src/sys/arch/x68k/x68k/machdep.c,v 1.202 2019.12.31.13.07.13 ad src/sys/compat/linux/common/linux_misc.c,v 1.247 2019.12.31.13.07.13 ad src/sys/compat/linux32/common/linux32_sysinfo.c,v 1.10 2019.12.31.13.07.13 ad src/sys/dev/ccd.c,v 1.183 2019.12.31.13.07.13 ad src/sys/fs/tmpfs/tmpfs_mem.c,v 1.12 2019.12.31.13.07.13 ad src/sys/kern/init_main.c,v 1.514 2019.12.31.13.07.13 ad src/sys/kern/kern_module.c,v 1.143 2019.12.31.13.07.13 ad src/sys/kern/kern_proc.c,v 1.239 2019.12.31.13.07.13 ad src/sys/kern/vfs_bio.c,v 1.286 2019.12.31.13.07.13 ad src/sys/miscfs/procfs/procfs_linux.c,v 1.79 2019.12.31.13.07.13 ad src/sys/rump/librump/rumpkern/vm.c,v 1.179 2019.12.31.13.07.13 ad src/sys/ufs/chfs/chfs_subr.c,v 1.11 2019.12.31.13.07.14 ad src/sys/ufs/lfs/lfs_bio.c,v 1.144 2019.12.31.13.07.14 ad src/sys/uvm/uvm_extern.h,v 1.217 2019.12.31.13.07.14 ad src/sys/uvm/uvm_glue.c,v 1.174 2019.12.31.13.07.14 ad src/sys/uvm/uvm_meter.c,v 1.73 2019.12.31.13.07.14 ad src/sys/uvm/uvm_page.c,v 1.219 2019.12.31.13.07.14 ad src/sys/uvm/uvm_pdaemon.c,v 1.121 2019.12.31.13.07.14 ad src/sys/uvm/uvm_pdpolicy_clock.c,v 1.27 2019.12.31.13.07.14 ad src/sys/uvm/uvm_pglist.c,v 1.79 2019.12.31.13.07.14 ad src/sys/uvm/uvm_stat.c,v 1.43 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.12.html#2019.12.31.13.07.14 !DSPAM:5e0b6508209901749451217! ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: 9.99.32 panic
Hmmm, I'm running X on amd64-9.99.32 built from sources that were updated just a couple hours ago, without any problem. I've got a nouveau graphics card (CTX 1050Ti) if it matters. I'm not using xfce, just plain xdm and fvwm On Wed, 1 Jan 2020, Chavdar Ivanov wrote: Hi, I get: ... #0 0x80224245 in cpu_reboot () #1 0x807b9723 in db_reboot_cmd () #2 0x807b9f3b in db_command () #3 0x807ba2a6 in db_command_loop () #4 0x807bdc2a in db_trap () #5 0x80220b15 in kdb_trap () #6 0x80225c86 in trap () #7 0x8021ed63 in alltraps () #8 0x8021f57d in breakpoint () #9 0x80a33270 in vpanic () #10 0x80e79e33 in kern_assert () #11 0x809ae062 in uvm_pageactivate () #12 0x809947a2 in amap_cow_now () #13 0x809a8d1e in uvmspace_fork () #14 0x8099eea9 in uvm_proc_fork () #15 0x809d9e8b in fork1 () #16 0x809daa12 in sys_fork () #17 0x80254d49 in syscall () #18 0x802096bd in handle_syscall () on uname -a NetBSD marge.lorien.lan 9.99.32 NetBSD 9.99.32 (GENERIC) #13: Wed Jan 1 12:31:34 GMT 2020 sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC amd64 when I try to startxfce4. Normal startx works, as well as xrandr to get me to the right resolution under VirtualBox (with client additions 6.1); gdm also starts OK and subsequently the mate session works. Chavdar -- !DSPAM:5e0cdbd0269651875828750! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
How to make XZ_SETS compress using multiple threads?
I see that we have an XZ_ARGS variable which we can force to define with ``-V XZ_ARGS=-T6'' and that appears that it will add the "-T6" argument when invoking xz to build sets. However, this would break the evbmips Makefile, which already uses XZ_ARGS to conditionally set several other flags. Is there something equivalent to XZ_ARGS which can be set by a user without interfering with the existing build mechanisms? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: How to make XZ_SETS compress using multiple threads?
On Sun, 5 Jan 2020, Martin Husemann wrote: On Sun, Jan 05, 2020 at 05:34:51AM -0800, Paul Goyette wrote: I see that we have an XZ_ARGS variable which we can force to define with ``-V XZ_ARGS=-T6'' and that appears that it will add the "-T6" argument when invoking xz to build sets. ... which won't help as the tools xz version is not threaded. Ah, I see. Thanks. Per discussion on IRC I will investigate using pigz ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
[no subject]
Failure to build install-image - sources current as of 2020-01-06 at 13:03:23 UTC Creating rootfs... chmod +r work/var/spool/ftp/hidden /build/netbsd-local/tools/x86_64/amd64/bin/nbmakefs -M 1519386624 -m 1519386624 -B 1234 -F work.spec -N work/etc -o bsize=16384,fsize=2048,density=8192 work.rootfs work nbmakefs: `work' size of 1994735616 is larger than the maxsize of 1519386624. *** Failed target: imgroot.fs ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Failure with ``build.sh -V USE_PIGZGZIP=yes install-image''
On Mon, 6 Jan 2020, Paul Goyette wrote: Failure to build install-image - sources current as of 2020-01-06 at 13:03:23 UTC Creating rootfs... chmod +r work/var/spool/ftp/hidden /build/netbsd-local/tools/x86_64/amd64/bin/nbmakefs -M 1519386624 -m 1519386624 -B 1234 -F work.spec -N work/etc -o bsize=16384,fsize=2048,density=8192 work.rootfs work nbmakefs: `work' size of 1994735616 is larger than the maxsize of 1519386624. *** Failed target: imgroot.fs This seems to be a repeatable failure. Running without specifying USE_PIGZGZIP works correctly. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Panic during reboot on amd64 9.99.52
On Fri, 27 Mar 2020, Paul Goyette wrote: With a curent built from sources updated just a few hours ago (on 2020-03-27 at 16:13:55 UTC), I get a panic during shutdown. The stack trace doesn't seem to be saved, but I manually transcribed it: vpanic + 0x178 kern_assert + 0x48 config_detach + 0x65 mii_detach + 0x109 wm_detach + 0xb0 config_detach + 0xe5 config_detach_all + 0x97 cpu_reboot + 0x198 sys_reboot sys_reboot + 0x63 syscall + 0x299 (syscall #208) Unfortunately, the actual panic message had scrolled off the screen, but it included "bad device fstate". The only mii on my machine should be ihphy0 at wm0 phy 2: i217 10/100/1000 media interface, rev. 5 and is configured as ihphy0 at mii? phy ? Anyone got any ideas? For now I have reverted to my previous 9.99.46 kernel... A bit more info... The panic message is from the KASSERTMSG() at line 1742 in source file kern/subr_autoconf.c rev 1.269 (very early in config_detach()): KASSERTMSG((cf == NULL || cf->cf_fstate == FSTATE_FOUND || cf->cf_fstate == FSTATE_STAR), "config_detach: %s: bad device fstate: %d", device_xname(dev), cf ? cf->cf_fstate : -1); The actual panic message is config_detach: ihphy0: bad device fstate: 0 According to the #defines in sys/device.h we have #define FSTATE_NOTFOUND 0 /* has not been found */ Just idle curiousity (I am unfamiliar with these drivers), I wonder if it's possible for the ihphy to be detached twice? Perhaps it can be detached by config_detach_all() and then the wm driver tries to detach again? ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Panic during reboot on amd64 9.99.52
With a curent built from sources updated just a few hours ago (on 2020-03-27 at 16:13:55 UTC), I get a panic during shutdown. The stack trace doesn't seem to be saved, but I manually transcribed it: vpanic + 0x178 kern_assert + 0x48 config_detach + 0x65 mii_detach + 0x109 wm_detach + 0xb0 config_detach + 0xe5 config_detach_all + 0x97 cpu_reboot + 0x198 sys_reboot sys_reboot + 0x63 syscall + 0x299 (syscall #208) Unfortunately, the actual panic message had scrolled off the screen, but it included "bad device fstate". The only mii on my machine should be ihphy0 at wm0 phy 2: i217 10/100/1000 media interface, rev. 5 and is configured as ihphy0 at mii? phy ? Anyone got any ideas? For now I have reverted to my previous 9.99.46 kernel... ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Panic during reboot on amd64 9.99.52
I've filed PR kern/55121 for this issue... I _do_ have a crash dump available if anyone wants me to provide any additional info. On Fri, 27 Mar 2020, Paul Goyette wrote: On Fri, 27 Mar 2020, Paul Goyette wrote: With a curent built from sources updated just a few hours ago (on 2020-03-27 at 16:13:55 UTC), I get a panic during shutdown. The stack trace doesn't seem to be saved, but I manually transcribed it: vpanic + 0x178 kern_assert + 0x48 config_detach + 0x65 mii_detach + 0x109 wm_detach + 0xb0 config_detach + 0xe5 config_detach_all + 0x97 cpu_reboot + 0x198 sys_reboot sys_reboot + 0x63 syscall + 0x299 (syscall #208) Unfortunately, the actual panic message had scrolled off the screen, but it included "bad device fstate". The only mii on my machine should be ihphy0 at wm0 phy 2: i217 10/100/1000 media interface, rev. 5 and is configured as ihphy0 at mii? phy ? Anyone got any ideas? For now I have reverted to my previous 9.99.46 kernel... A bit more info... The panic message is from the KASSERTMSG() at line 1742 in source file kern/subr_autoconf.c rev 1.269 (very early in config_detach()): KASSERTMSG((cf == NULL || cf->cf_fstate == FSTATE_FOUND || cf->cf_fstate == FSTATE_STAR), "config_detach: %s: bad device fstate: %d", device_xname(dev), cf ? cf->cf_fstate : -1); The actual panic message is config_detach: ihphy0: bad device fstate: 0 According to the #defines in sys/device.h we have #define FSTATE_NOTFOUND 0 /* has not been found */ Just idle curiousity (I am unfamiliar with these drivers), I wonder if it's possible for the ihphy to be detached twice? Perhaps it can be detached by config_detach_all() and then the wm driver tries to detach again? ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ !DSPAM:5e7e69ae64171663757142! ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: new dmesg line: sysctl_createv: sysctl_locate(maxtypenum) returned 2
On Thu, 26 Mar 2020, Thomas Klausner wrote: Hi! Reading the dmesg after a recent reboot (on 0.99.51) I see: sysctl_createv: sysctl_locate(maxtypenum) returned 2 I guess this is a debug printf that slipped into production? The code has been around for a long time (in kern/kern_sysctl.c:2065) but seems to suddenly have started triggering. I will investigate. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
MKDEBUG=yes results in hundreds of extra files in $DESTDIR
Looks like recent changes to module .mk files doesn't work with MKDEBUG=yes ... === 615 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/libdata/debug/stand/amd64-xen ./usr/libdata/debug/stand/amd64-xen/9.99.59 ./usr/libdata/debug/stand/amd64-xen/9.99.59/modules ... ./usr/libdata/debug/stand/amd64-xen/9.99.59/modules/zl10353 ./usr/libdata/debug/stand/amd64-xen/9.99.59/modules/zl10353/zl10353.kmod.debug ./usr/libdata/debug/stand/amd64-xen/9.99.59/modules/zlib ./usr/libdata/debug/stand/amd64-xen/9.99.59/modules/zlib/zlib.kmod.debug = end of 615 extra files === --- checkflist --- *** [checkflist] Error code 1 ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Build error when crypto and swcrypto are omitted from kernel
With the recent introduction of swap encryption, it is now mandatory to include "pseudo-device crypto" and/or "pseudo-device swcrypto" in the kernel. Without this, the kernel fails to link, with undefined references to several symbols: rijndael_cipherInit rijndael_blockEncrypt rijndael_blockDecrypt rijndael_makeKey Since the two crypto devices are optional (and run-time loadable) components of the kernel, it seems to me that encrypted-swap should also be optional. ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Michael van Elst wrote: p...@whooppee.com (Paul Goyette) writes: the kernel. Without this, the kernel fails to link, with undefined references to several symbols: rijndael_cipherInit rijndael_blockEncrypt rijndael_blockDecrypt rijndael_makeKey Since the two crypto devices are optional (and run-time loadable) components of the kernel, it seems to me that encrypted-swap should also be optional. rijndael isn't (yet) optional as it is required by ipsec and wlan code. We just miss the dependency for the encrypted swap functionality. Prior to the encrypted-swap commit, a kernel configured without the ``pseudo-device crypto'' was able to link and run successfully. (Any attempt to use rijndael results in an auto-load of the crypto module.) Here is a patch that makes encrypted swap (but not rijndael) optional: http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/uvm_swap.diff which might be useful to create small kernels (it's just about 16kB). Otherwise you could just add the dependency to uvm unconditionally. Seems to me that any attempt to enable encrypted-swap should also trigger an auto-load for the crypto module. Appropriate module hooks should be used to avoid the undefined symbols. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Michael van Elst wrote: On Sun, May 10, 2020 at 07:54:06AM -0700, Paul Goyette wrote: Prior to the encrypted-swap commit, a kernel configured without the ``pseudo-device crypto'' was able to link and run successfully. (Any attempt to use rijndael results in an auto-load of the crypto module.) Even without 'pseudo-device crypto' some kernels still build, as long as the dependency to the rijndael files exists in the kernel configuration. This is e.g. true if you built with wlan drivers or cgd. Here is a patch that makes encrypted swap (but not rijndael) optional: http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/uvm_swap.diff which might be useful to create small kernels (it's just about 16kB). Otherwise you could just add the dependency to uvm unconditionally. Seems to me that any attempt to enable encrypted-swap should also trigger an auto-load for the crypto module. Appropriate module hooks should be used to avoid the undefined symbols. The rijndael code is not a module, and the crypto module is neither used nor referenced, it shouldn't be loaded then. You would be perfectly right if it wasn't rijndael but e.g. des. Ah, OK, I got it now. Thanks for your patience. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
Here is a patch that makes encrypted swap (but not rijndael) optional: http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/uvm_swap.diff That looks good to me, too. I guess you should also add VM_SWAPCRYPT option to various kernels (GENERIC*, XEN3*, ...)? Please commit. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Paul Goyette wrote: Here is a patch that makes encrypted swap (but not rijndael) optional: http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/uvm_swap.diff That looks good to me, too. I guess you should also add VM_SWAPCRYPT option to various kernels (GENERIC*, XEN3*, ...)? Oh never mind - you already added it to std. :) Please commit. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Michael van Elst wrote: p...@whooppee.com (Paul Goyette) writes: FWIW, here's an additional patch to update the options(4) man page: But is it worth the effort to make 16kB optional ? Well, 90%+ of the effort has already been expended, so why not? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Paul Goyette wrote:
On Sun, 10 May 2020, Michael van Elst wrote:
p...@whooppee.com (Paul Goyette) writes:
FWIW, here's an additional patch to update the options(4) man page:
But is it worth the effort to make 16kB optional ?
Well, 90%+ of the effort has already been expended, so why not?
FWIW, I have just successfully completed my build of my custom kernel
(and an entire ``build.sh release'') and it correctly included the
rijndael stuff (even without the two {,sw}crypto pseudo-devices).
I'd be happy to do the commit if you don't want to expend any further
effort here.
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Michael van Elst wrote: On Sun, May 10, 2020 at 08:46:30AM -0700, Paul Goyette wrote: Here is a patch that makes encrypted swap (but not rijndael) optional: http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/uvm_swap.diff That looks good to me, too. I guess you should also add VM_SWAPCRYPT option to various kernels (GENERIC*, XEN3*, ...)? It's a default option in sys/conf/std. Individual kernels can disable it with 'no options VMSWAPCRYPT'. Yeah, found that. FWIW, here's an additional patch to update the options(4) man page: Index: share/man/man4/options.4 === RCS file: /cvsroot/src/share/man/man4/options.4,v retrieving revision 1.512 diff -u -p -r1.512 options.4 --- share/man/man4/options.424 Apr 2020 13:54:56 - 1.512 +++ share/man/man4/options.410 May 2020 17:11:27 - @@ -2221,6 +2221,9 @@ for port specific details including avai .It Cd options VMSWAP Enable paging device/file support. This option is on by default. +.It Cd options VMSWAPCRYPT +Enable encryption of swapfile. +This option is on by default. .It Cd options PDPOLICY_CLOCKPRO Use CLOCK-Pro, an alternative page replace policy. .El ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error when crypto and swcrypto are omitted from kernel
On Sun, 10 May 2020, Michael van Elst wrote:
p...@whooppee.com (Paul Goyette) writes:
Well, 90%+ of the effort has already been expended, so why not?
90%+ is probably the time needed to test optional builds in the future.
FWIW, I have just successfully completed my build of my custom kernel
(and an entire ``build.sh release'') and it correctly included the
rijndael stuff (even without the two {,sw}crypto pseudo-devices).
And I'd like to talk to Martin, since 100% of the task is done if
we just add the missing dependency without the option. Even an
#ifdef SMALL could be easier to maintain.
Yep, that would work, too. I'm open to either approach, just would
like to move forward.
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: How long to build from source?
On Fri, 8 May 2020, Benny Siegert wrote: The short answer: It depends. Slightly longer: Does the laptop have an SSD, an NVMe disk or a spinning hard drive? Which build options do you choose -- for instance, do you want to build X as well, do you want to build the graphics acceleration stuff (which requires building LLVM IIRC), etc. pp. Add to the questions: * How much RAM do you have? * Where is your /tmp located? tmpfs (in RAM)? SSD? spinning disk? I think it's going to be a couple hours. You could run the build overnight if you want. If you're also building in-tree X11, you can add a couple more hours to the estimate! :) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 test failure
/zfs_acl.c,v 1.6 2020.03.17.00.57.54 fox src/external/bsd/iscsi/dist/src/lib/initiator.c,v 1.10 2020.03.17.01.36.29 fox src/external/cddl/osnet/lib/libdtrace/Makefile,v 1.28 2020.03.17.05.04.10 kre src/sys/arch/xen/xen/xennetback_xenbus.c,v 1.79 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.03.html#2020.03.17.05.04.10 !DSPAM:5e72660a223071884218826! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build failure for ``build.sh release'' on amd64
Hmmm, OK, this seems to have resolved itself after I removed the
XEN3_DOM0 kernel objects (forcing everything to be re-made).
On Fri, 22 May 2020, Paul Goyette wrote:
With sources updated on 2020-05-22 at 20:57:47 UTC, I'm getting the
following errors:
# link XEN3_DOM0/netbsd
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld -Map netbsd.map
--cref -T netbsd.ldscript -Ttext 0x8020 -e start -X -o netbsd
${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ} vers.o swapnetbsd.o
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld: pci_stub.o: in
function `pci_msi_alloc':
/build/netbsd-compat/src_ro/sys/dev/pci/pci_stub.c:112: multiple definition
of `pci_msi_alloc';
pci_msi_machdep.o:/build/netbsd-compat/src_ro/sys/arch/x86/pci/pci_msi_machdep.c:504:
first defined here
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld: pci_stub.o: in
function `pci_msi_alloc_exact':
/build/netbsd-compat/src_ro/sys/dev/pci/pci_stub.c:120: multiple definition
of `pci_msi_alloc_exact';
pci_msi_machdep.o:/build/netbsd-compat/src_ro/sys/arch/x86/pci/pci_msi_machdep.c:534:
first defined here
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld: pci_stub.o: in
function `pci_msix_alloc':
/build/netbsd-compat/src_ro/sys/dev/pci/pci_stub.c:120: multiple definition
of `pci_msix_alloc';
pci_msi_machdep.o:/build/netbsd-compat/src_ro/sys/arch/x86/pci/pci_msi_machdep.c:563:
first defined here
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld: pci_stub.o: in
function `pci_msix_alloc_exact':
/build/netbsd-compat/src_ro/sys/dev/pci/pci_stub.c:120: multiple definition
of `pci_msix_alloc_exact';
pci_msi_machdep.o:/build/netbsd-compat/src_ro/sys/arch/x86/pci/pci_msi_machdep.c:590:
first defined here
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld: pci_stub.o: in
function `pci_msix_alloc_map':
/build/netbsd-compat/src_ro/sys/dev/pci/pci_stub.c:144: multiple definition
of `pci_msix_alloc_map';
pci_msi_machdep.o:/build/netbsd-compat/src_ro/sys/arch/x86/pci/pci_msi_machdep.c:624:
first defined here
*** [netbsd] Error code 1
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: build failure when optimizing
This is done deliberately, to enable you to run NetBSD-i386 images on a NetBSD-amd64 host. If you want to eliminate these compatability libraries, you can set the MKCOMPAT variable to NO: build.sh ... -V MKCOMPAT=NO release On Sat, 23 May 2020, os...@fessel.org wrote: Hej, I just tried to build release with optimisation for my little xeon server. That fails, but I don???t understand why it seems to build some 386 32bit libs. ??? # build libgcc_s/libgcc_s.so.1.0 rm -f libgcc_s.so.1.0 /hurz/obj/tooldir.NetBSD-9.99.63-amd64/bin/x86_64--netbsd-gcc -nodefaultlibs -shared -Wl,-soname,libgcc_s.so.1 -Wl,--warn-shared-textrel -Wl,-Map=libgcc_s.so.1.map -m32 --sysroot=/hurz/obj/destdir.NetBSD-9.99.63-amd64 -nodefaultlibs -Wl,-z -Wl,nodelete -Wl,--version-script=/hurz/src/external/gpl3/gcc/lib/libgcc/libgcc_s/libgcc.map -Wl,-z,relro -o libgcc_s.so.1.0.tmp -Wl,-rpath,/usr/lib/i386 -L=/usr/lib/i386 -Wl,-x -Wl,--whole-archive libgcc_s_pic.a -Wl,--no-whole-archive -m32 /hurz/obj/tooldir.NetBSD-9.99.63-amd64/lib/gcc/x86_64--netbsd/8.4.0/../../../../x86_64--netbsd/bin/ld: i386:x86-64 architecture of input file `/hurz/obj/destdir.NetBSD-9.99.63-amd64/usr/lib/../lib/i386/crti.o' is incompatible with i386 output ??? optimization was done using cpuflags: ARCH: -march=native FEATURES: -mfpmath=sse -msse3 CPUFLAGS: -mfpmath=sse -msse3 -march=native GCC version : 8.4.0 OS : 'NetBSD' OS version : '9.99.63' hw.model: 'Intel 686-class' hw.machine : 'amd64' hw.machine_arch : 'x86_64' CPU : '' cpu_name="highest basic info 000d" cpu_brand="IntelR XeonR CPU E5-2640 0 @ 2.50GHz??? Any ideas? cheers Oskar ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
HEAD tools build broken on amd64
With up-to-date sources, I am getting this while building tools: /build/netbsd-compat/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd /netbsd.h:54:10: fatal error: bfd.h: No such file or directory #include "bfd.h" ^~~ (I can provide additional log context if needed) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
re: HEAD tools build broken on amd64
On Sun, 6 Sep 2020, Paul Goyette wrote: On Mon, 7 Sep 2020, matthew green wrote: /build/netbsd-compat/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/netbsd.h:54:10: fatal error: bfd.h: No such file or directory #include "bfd.h" ^~~ do you have a bfd.h lying around somewhere it shouldn't? check your source tree for extra files? eg 'cvs up -dPA -I\! -ICVS'. sometimes make can find something gcc won't, and this happens. Hmmm. "Extra files" would mean "file that _is_ there but _should_not_ be there", while the actual error message would seem to indicate that the "file bfd.h _is_not_ there but _should_ be there". In either case I ran the sugggested ``cvs up'' command (with the -q option, to avoid the plethora of "Updating " messages) and nothing out of the ordinary shows up. I probably ought to mention a couple more items: * This happens in two separate sources trees, and * it happens with a completely empty TOOLDIR (and OBJDIR and DESTDIR) And one more item which likely will help find the real culprit: Running the exact same build.sh with -j12 succeeds! So it would seem that something somewhere (TM) is creating the required bfd.h file, in the tools-object directory perhaps? ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
re: HEAD tools build broken on amd64
On Mon, 7 Sep 2020, matthew green wrote: /build/netbsd-compat/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/netbsd.h:54:10: fatal error: bfd.h: No such file or directory #include "bfd.h" ^~~ do you have a bfd.h lying around somewhere it shouldn't? check your source tree for extra files? eg 'cvs up -dPA -I\! -ICVS'. sometimes make can find something gcc won't, and this happens. Hmmm. "Extra files" would mean "file that _is_ there but _should_not_ be there", while the actual error message would seem to indicate that the "file bfd.h _is_not_ there but _should_ be there". In either case I ran the sugggested ``cvs up'' command (with the -q option, to avoid the plethora of "Updating " messages) and nothing out of the ordinary shows up. I probably ought to mention a couple more items: * This happens in two separate sources trees, and * it happens with a completely empty TOOLDIR (and OBJDIR and DESTDIR) ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: HEAD tools build broken on amd64
With up-to-date sources (updated on 2020-09-06 at 15:51:27 UTC), I am still getting this while building tools: ... In file included from /build/netbsd-compat/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/i386netbsd.c:38: /build/netbsd-compat/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/netbsd.h:54:10: fatal error: bfd.h: No such file or directory #include "bfd.h" ^~~ compilation terminated. *** [i386netbsd.lo] Error code 1 nbmake[7]: stopped in /build/netbsd-compat/obj/amd64/tools/binutils/build/bfd 1 error ... (I can provide additional log context if needed) It seems that the babylon5 test bed is not seeing this, so I wonder if there is a problem running on an NetBSD-amd64-9.99.66 host (my system) vs whatever b5 is running? Anyone have a clue? Is something perhaps including a header from the host system rather than from the $SRCDIR tree? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: HEAD tools build broken on amd64
I can confirm that this fixes my problem! Please commit! On Mon, 7 Sep 2020, Tom Spindler (moof) wrote: /build/netbsd-compat/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/netbsd.h:54:10: fatal error: bfd.h: No such file or directory #include "bfd.h" ^~~ Try this; it's cargo-culted cut-n-paste, so I'm not convinced it's correct - but `build.sh tools` succeeds for both -j1 and -j6, and the problem doesn't occur in trees with sources prior to the recreation of i386netbsd.c on 2020-aug-08. cvs diff: Diffing external/gpl3/binutils/dist/bfd Index: external/gpl3/binutils/dist/bfd/Makefile.am === RCS file: /cvsroot/src/external/gpl3/binutils/dist/bfd/Makefile.am,v retrieving revision 1.7 diff -u -w -p -r1.7 Makefile.am --- external/gpl3/binutils/dist/bfd/Makefile.am 3 Apr 2020 23:48:45 - 1.7 +++ external/gpl3/binutils/dist/bfd/Makefile.am 7 Sep 2020 07:46:11 - @@ -363,6 +363,7 @@ BFD32_BACKENDS = \ i386bsd.lo \ i386lynx.lo \ i386msdos.lo \ + i386netbsd.lo \ mach-o.lo \ mach-o-i386.lo \ mach-o-arm.lo \ @@ -499,6 +500,7 @@ BFD32_BACKENDS_CFILES = \ i386bsd.c \ i386lynx.c \ i386msdos.c \ + i386netbsd.c \ mach-o.c \ mach-o-i386.c \ mach-o-arm.c \ Index: external/gpl3/binutils/dist/bfd/Makefile.in === RCS file: /cvsroot/src/external/gpl3/binutils/dist/bfd/Makefile.in,v retrieving revision 1.8 diff -u -w -p -r1.8 Makefile.in --- external/gpl3/binutils/dist/bfd/Makefile.in 3 Apr 2020 23:48:45 - 1.8 +++ external/gpl3/binutils/dist/bfd/Makefile.in 7 Sep 2020 07:46:12 - @@ -792,6 +792,7 @@ BFD32_BACKENDS = \ i386bsd.lo \ i386lynx.lo \ i386msdos.lo \ + i386netbsd.lo \ mach-o.lo \ mach-o-i386.lo \ mach-o-arm.lo \ @@ -930,6 +931,7 @@ BFD32_BACKENDS_CFILES = \ i386bsd.c \ i386lynx.c \ i386msdos.c \ + i386netbsd.c \ mach-o.c \ mach-o-i386.c \ mach-o-arm.c \ @@ -1537,6 +1539,7 @@ distclean-compile: @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/i386bsd.Plo@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/i386lynx.Plo@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/i386msdos.Plo@am__quote@ +@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/i386netbsd.Plo@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ihex.Plo@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/init.Plo@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/irix-core.Plo@am__quote@ cvs diff: Diffing external/gpl3/binutils/dist/bfd/doc cvs diff: Diffing external/gpl3/binutils/dist/bfd/hosts cvs diff: Diffing external/gpl3/binutils/dist/bfd/po !DSPAM:5f55e7cb237471722618051! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Build failure for ``no options PTRACE''
For a custom kernel build with ``no options PTRACE'' and ``no options
COREDUMP'' defined, and sources updated on 2020-10-16 at 13:18:24 UTC,
I get the following linker error:
# link SPEEDY/netbsd
/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-ld -Map netbsd.map
--cref -T netbsd.ldscript -Ttext 0x8020 -e start -z
max-page-size=0x20 -X -o netbsd ${SYSTEM_OBJ:[@]:Nswapnetbsd.o}
${EXTRA_OBJ} vers.o swapnetbsd.o
/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-ld:
process_machdep.o: in function `ptrace_machdep_dorequest':
/build/netbsd-local/src/sys/arch/amd64/amd64/process_machdep.c:329: undefined
reference to `ptrace_update_lwp'
/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-ld:
/build/netbsd-local/src/sys/arch/amd64/amd64/process_machdep.c:372: undefined
reference to `ptrace_update_lwp'
*** [netbsd] Error code 1
nbmake: stopped in /build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY
1 error
nbmake: stopped in /build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY
ERROR: Failed to make all in
"/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY"
*** BUILD ABORTED ***
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Build failure for ``no options PTRACE''
Thanks - I'll give it a try.
On Sat, 17 Oct 2020, Christos Zoulas wrote:
In article ,
Paul Goyette wrote:
For a custom kernel build with ``no options PTRACE'' and ``no options
COREDUMP'' defined, and sources updated on 2020-10-16 at 13:18:24 UTC,
I get the following linker error:
# link SPEEDY/netbsd
/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-ld -Map
netbsd.map --cref -T netbsd.ldscript -Ttext 0x8020 -e start
-z max-page-size=0x20 -X -o netbsd ${SYSTEM_OBJ:[@]:Nswapnetbsd.o}
${EXTRA_OBJ} vers.o swapnetbsd.o
/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-ld:
process_machdep.o: in function `ptrace_machdep_dorequest':
/build/netbsd-local/src/sys/arch/amd64/amd64/process_machdep.c:329:
undefined reference to `ptrace_update_lwp'
/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-ld:
/build/netbsd-local/src/sys/arch/amd64/amd64/process_machdep.c:372:
undefined reference to `ptrace_update_lwp'
*** [netbsd] Error code 1
nbmake: stopped in /build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY
1 error
nbmake: stopped in /build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY
ERROR: Failed to make all in
"/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY"
*** BUILD ABORTED ***
process_machdep.c provides 2 functions:
The read+write regs functions: used by ptrace and coredump
The machdep ptrace function: handling used only by ptrace
These dependencies are not reflected correctly in the patch below.
Perhaps we want a regs module by splitting and then coredump
and ptrace depends on that.
This patch puts process_machdep.c in the ptrace module, and
moves all the coredump functions in the coredump module. I have
only compile-tested this.
christos
Index: arch/amd64/amd64/process_machdep.c
===
RCS file: /cvsroot/src/sys/arch/amd64/amd64/process_machdep.c,v
retrieving revision 1.48
diff -u -u -r1.48 process_machdep.c
--- arch/amd64/amd64/process_machdep.c 15 Oct 2020 17:37:35 - 1.48
+++ arch/amd64/amd64/process_machdep.c 17 Oct 2020 13:19:59 -
@@ -76,7 +76,9 @@
#include
__KERNEL_RCSID(0, "$NetBSD: process_machdep.c,v 1.48 2020/10/15 17:37:35 mgorny Exp
$");
+#ifdef _KERNEL_OPT
#include "opt_xen.h"
+#endif
#include
#include
#include
Index: arch/amd64/conf/MODULAR
===
RCS file: /cvsroot/src/sys/arch/amd64/conf/MODULAR,v
retrieving revision 1.17
diff -u -u -r1.17 MODULAR
--- arch/amd64/conf/MODULAR 27 Sep 2020 13:48:49 - 1.17
+++ arch/amd64/conf/MODULAR 17 Oct 2020 13:19:59 -
@@ -4,8 +4,6 @@
# XXX: incomplete
include "arch/amd64/conf/GENERIC"
-optionsMODULAR # new style module(7) framework
-optionsMODULAR_DEFAULT_AUTOLOAD
-no acpicpu*at cpu?
-no est0at cpu0
@@ -85,6 +83,9 @@
-no options AIO
+-no optionsPTRACE
+-no optionsCOREDUMP
+
-no acpiacad* at acpi?# ACPI AC Adapter
-no acpibat*at acpi?# ACPI Battery
-no acpibut*at acpi?# ACPI Button
Index: arch/amd64/conf/files.amd64
===
RCS file: /cvsroot/src/sys/arch/amd64/conf/files.amd64,v
retrieving revision 1.117
diff -u -u -r1.117 files.amd64
--- arch/amd64/conf/files.amd64 15 Oct 2020 17:40:13 - 1.117
+++ arch/amd64/conf/files.amd64 17 Oct 2020 13:19:59 -
@@ -47,7 +47,7 @@
filearch/amd64/amd64/gdt.c machdep
filearch/amd64/amd64/machdep.c machdep
filearch/amd64/amd64/prekern.c kaslr
-file arch/amd64/amd64/process_machdep.c machdep
+file arch/amd64/amd64/process_machdep.c machdep & ptrace
filearch/amd64/amd64/trap.c machdep
filearch/x86/x86/fpu.c machdep
filearch/x86/x86/dbregs.c machdep
Index: kern/compat_stub.c
===
RCS file: /cvsroot/src/sys/kern/compat_stub.c,v
retrieving revision 1.19
diff -u -u -r1.19 compat_stub.c
--- kern/compat_stub.c 20 Nov 2019 19:37:53 - 1.19
+++ kern/compat_stub.c 17 Oct 2020 13:20:00 -
@@ -280,6 +280,8 @@
struct coredump_offset_hook_t coredump_offset_hook;
struct coredump_write_hook_t coredump_write_hook;
struct coredump_netbsd_hook_t coredump_netbsd_hook;
+struct coredump_elf32_hook_t coredump_elf32_hook;
+struct coredump_elf64_hook_t coredump_elf64_hook;
struct uvm_coredump_walkmap_hook_t uvm_coredump_walkmap_hook;
struct uvm_coredump_count_segs_hook_t uvm_coredump_count_segs_hook;
Index: kern/core_elf32.c
===
RCS file: /cvsroot/src/sys/kern/core_elf32.c,v
retrieving revision 1.65
diff -u -u -r1.65 core_elf32.c
--- kern/core_elf32.c 10 Oct 2020 00:10:06 - 1.65
+++ ke
Re: Build failure for ``no options PTRACE''
Kamil wrote: This, I propose to do the following: 1. Remove the modularization of ptrace. This does not affect the compat layers that still can and should be in my opinion modular. 2. Either abandon 'no PTRACE' or make it complete ifdefing all the ptrace-related code from the kernel core. I'm not commenting on usefulness of having a PTRACE module; I'll leave that discussion to others. However, you cannot implement #2 without also implementing #1. You cannot simply ifdef-out the calls to the ptrace code if it is still possible to load ptrace as a module. 3. If we have security related concerns, add "security.models.extensions.ptrace". Of course, the sysctl would/should only exist if the kernel includes ``options PTRACE'' ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build failure for ``no options PTRACE''
OK, I got a build failure for modules:
# compile coredump/kern_core.o
/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-gcc -O2 -g
-std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
-Wno-unused-parameter -Wno-sign-compare -Werror
-Wno-error=address-of-packed-member -ffreestanding -fno-strict-aliasing
-Wno-pointer-sign -mno-red-zone -mno-mmx -mno-sse -mno-avx -msoft-float
-mcmodel=kernel -fno-omit-frame-pointer
-I/build/netbsd-local/src/common/include -DDIAGNOSTIC
--sysroot=/build/netbsd-local/dest/amd64
-I/build/netbsd-local/src/common/include -DDIAGNOSTIC -nostdinc -I.
-I/build/netbsd-local/src/sys/modules/coredump -isystem
/build/netbsd-local/src/sys -isystem /build/netbsd-local/src/sys/arch -isystem
/build/netbsd-local/src/sys/../common/include -D_KERNEL -D_MODULE
-DSYSCTL_INCLUDE_DESCR -c -Wno-cast-function-type
/build/netbsd-local/src/sys/kern/kern_
core.c
In file included from /build/netbsd-local/src/sys/sys/compat_stub.h:35,
from /build/netbsd-local/src/sys/kern/kern_core.c:53:
/build/netbsd-local/src/sys/kern/kern_core.c: In function 'coredump_modcmd':
/build/netbsd-local/src/sys/kern/kern_core.c:80:40: error:
'real_coredump_elf32' undeclared (first use in this function); did you mean
'real_coredump_netbsd'?
80 | MODULE_HOOK_SET(coredump_elf32_hook, real_coredump_elf32);
|^~~
/build/netbsd-local/src/sys/kern/kern_core.c:80:40: note: each undeclared
identifier is reported only once for each function it appears in
/build/netbsd-local/src/sys/kern/kern_core.c:81:40: error:
'real_coredump_elf64' undeclared (first use in this function); did you mean
'real_coredump_netbsd'?
81 | MODULE_HOOK_SET(coredump_elf64_hook, real_coredump_elf64);
|^~~
*** [kern_core.o] Error code 1
nbmake[2]: stopped in /build/netbsd-local/src/sys/modules/coredump
1 error
nbmake[2]: stopped in /build/netbsd-local/src/sys/modules/coredump
ERROR: Failed to make dependall in "sys/modules"
*** BUILD ABORTED ***
On Sat, 17 Oct 2020, Paul Goyette wrote:
Oh, ignore this for now. I might have to also rebuild my modules again.
On Sat, 17 Oct 2020, Paul Goyette wrote:
On Sat, 17 Oct 2020, Paul Goyette wrote:
Thanks - I'll give it a try.
OK, it builds. But it doesn't work, and least not completely!
FWIW, in addition to
no options COREDUMP
no options PTRACE
my custom kernel also has
no options EXEC_ELF32
no options EXEC_ELF64
These modules are expected to be auto-loaded as necessary.
It seems that the exec_elf* modules fail to load, since the symbol
coredump_elf{32,64} is already defined in the kernel, even though
I have the ``no options EXEC_ELF*'' in the config.
...
[ 8.0347157] init: copying out path `/sbin/init' 11
[ 8.0544213] kobj_checksyms, 1026: [%M/exec_elf32/exec_elf32.kmod]:
linker error: global symbol `coredump_elf32' redefined
[ 8.0544213] WARNING: module error: vfs load failed for `exec_elf32',
error 8
[ 8.0544213] kobj_checksyms, 1026: [%M/exec_elf64/exec_elf64.kmod]:
linker error: global symbol `coredump_elf64' redefined
[ 8.0544213] WARNING: module error: vfs load failed for `exec_elf64',
error 8
...
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
!DSPAM:5f8b271b6532105318807!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Build failure for ``no options PTRACE''
On Sat, 17 Oct 2020, Paul Goyette wrote:
Thanks - I'll give it a try.
OK, it builds. But it doesn't work, and least not completely!
FWIW, in addition to
no options COREDUMP
no options PTRACE
my custom kernel also has
no options EXEC_ELF32
no options EXEC_ELF64
These modules are expected to be auto-loaded as necessary.
It seems that the exec_elf* modules fail to load, since the symbol
coredump_elf{32,64} is already defined in the kernel, even though
I have the ``no options EXEC_ELF*'' in the config.
...
[ 8.0347157] init: copying out path `/sbin/init' 11
[ 8.0544213] kobj_checksyms, 1026: [%M/exec_elf32/exec_elf32.kmod]: linker
error: global symbol `coredump_elf32' redefined
[ 8.0544213] WARNING: module error: vfs load failed for `exec_elf32', error 8
[ 8.0544213] kobj_checksyms, 1026: [%M/exec_elf64/exec_elf64.kmod]: linker
error: global symbol `coredump_elf64' redefined
[ 8.0544213] WARNING: module error: vfs load failed for `exec_elf64', error 8
...
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Build failure for ``no options PTRACE''
Oh, ignore this for now. I might have to also rebuild my modules again.
On Sat, 17 Oct 2020, Paul Goyette wrote:
On Sat, 17 Oct 2020, Paul Goyette wrote:
Thanks - I'll give it a try.
OK, it builds. But it doesn't work, and least not completely!
FWIW, in addition to
no options COREDUMP
no options PTRACE
my custom kernel also has
no options EXEC_ELF32
no options EXEC_ELF64
These modules are expected to be auto-loaded as necessary.
It seems that the exec_elf* modules fail to load, since the symbol
coredump_elf{32,64} is already defined in the kernel, even though
I have the ``no options EXEC_ELF*'' in the config.
...
[ 8.0347157] init: copying out path `/sbin/init' 11
[ 8.0544213] kobj_checksyms, 1026: [%M/exec_elf32/exec_elf32.kmod]: linker
error: global symbol `coredump_elf32' redefined
[ 8.0544213] WARNING: module error: vfs load failed for `exec_elf32', error
8
[ 8.0544213] kobj_checksyms, 1026: [%M/exec_elf64/exec_elf64.kmod]: linker
error: global symbol `coredump_elf64' redefined
[ 8.0544213] WARNING: module error: vfs load failed for `exec_elf64', error
8
...
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
!DSPAM:5f8b25a2111031694517160!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Build failure for ``no options PTRACE''
On Sat, 17 Oct 2020, Christos Zoulas wrote:
Just add their declarations in exec_elf.h they have the same
signatures as the "unreal" ones :-)
Tried that, but now kern_core.c won't compile as part of the coredump
module:
...
# compile coredump/kern_core.o
... (gcc command line elided)
In file included from /build/netbsd-local/src_ro/sys/sys/compat_stub.h:35,
from /build/netbsd-local/src_ro/sys/kern/kern_core.c:53:
/build/netbsd-local/src_ro/sys/kern/kern_core.c: In function 'coredump_modcmd':
/build/netbsd-local/src_ro/sys/kern/kern_core.c:80:40: error:
'real_coredump_elf32' undeclared (first use in this function); did you mean
'real_coredump_netbsd'?
80 | MODULE_HOOK_SET(coredump_elf32_hook, real_coredump_elf32);
|^~~
/build/netbsd-local/src_ro/sys/kern/kern_core.c:80:40: note: each undeclared
identifier is reported only once for each function it appears in
/build/netbsd-local/src_ro/sys/kern/kern_core.c:81:40: error:
'real_coredump_elf64' undeclared (first use in this function); did you mean
'real_coredump_netbsd'?
81 | MODULE_HOOK_SET(coredump_elf64_hook, real_coredump_elf64);
|^~~
*** [kern_core.o] Error code 1
christos
On Oct 17, 2020, at 1:32 PM, Paul Goyette wrote:
OK, I got a build failure for modules:
# compile coredump/kern_core.o
/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-gcc -O2 -g
-std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
-Wno-unused-parameter -Wno-sign-compare -Werror
-Wno-error=address-of-packed-member -ffreestanding -fno-strict-aliasing
-Wno-pointer-sign -mno-red-zone -mno-mmx -mno-sse -mno-avx -msoft-float
-mcmodel=kernel -fno-omit-frame-pointer
-I/build/netbsd-local/src/common/include -DDIAGNOSTIC
--sysroot=/build/netbsd-local/dest/amd64
-I/build/netbsd-local/src/common/include -DDIAGNOSTIC -nostdinc -I.
-I/build/netbsd-local/src/sys/modules/coredump -isystem
/build/netbsd-local/src/sys -isystem /build/netbsd-local/src/sys/arch -isystem
/build/netbsd-local/src/sys/../common/include -D_KERNEL -D_MODULE
-DSYSCTL_INCLUDE_DESCR -c -Wno-cast-function-type
/build/netbsd-local/src/sys/kern/kern_
core.c
In file included from /build/netbsd-local/src/sys/sys/compat_stub.h:35,
from /build/netbsd-local/src/sys/kern/kern_core.c:53:
/build/netbsd-local/src/sys/kern/kern_core.c: In function 'coredump_modcmd':
/build/netbsd-local/src/sys/kern/kern_core.c:80:40: error:
'real_coredump_elf32' undeclared (first use in this function); did you mean
'real_coredump_netbsd'?
80 | MODULE_HOOK_SET(coredump_elf32_hook, real_coredump_elf32);
|^~~
/build/netbsd-local/src/sys/kern/kern_core.c:80:40: note: each undeclared
identifier is reported only once for each function it appears in
/build/netbsd-local/src/sys/kern/kern_core.c:81:40: error:
'real_coredump_elf64' undeclared (first use in this function); did you mean
'real_coredump_netbsd'?
81 | MODULE_HOOK_SET(coredump_elf64_hook, real_coredump_elf64);
|^~~
*** [kern_core.o] Error code 1
nbmake[2]: stopped in /build/netbsd-local/src/sys/modules/coredump
1 error
nbmake[2]: stopped in /build/netbsd-local/src/sys/modules/coredump
ERROR: Failed to make dependall in "sys/modules"
*** BUILD ABORTED ***
On Sat, 17 Oct 2020, Paul Goyette wrote:
Oh, ignore this for now. I might have to also rebuild my modules again.
On Sat, 17 Oct 2020, Paul Goyette wrote:
On Sat, 17 Oct 2020, Paul Goyette wrote:
Thanks - I'll give it a try.
OK, it builds. But it doesn't work, and least not completely!
FWIW, in addition to
no options COREDUMP
no options PTRACE
my custom kernel also has
no options EXEC_ELF32
no options EXEC_ELF64
These modules are expected to be auto-loaded as necessary.
It seems that the exec_elf* modules fail to load, since the symbol
coredump_elf{32,64} is already defined in the kernel, even though
I have the ``no options EXEC_ELF*'' in the config.
...
[ 8.0347157] init: copying out path `/sbin/init' 11
[ 8.0544213] kobj_checksyms, 1026: [%M/exec_elf32/exec_elf32.kmod]: linker
error: global symbol `coredump_elf32' redefined
[ 8.0544213] WARNING: module error: vfs load failed for `exec_elf32', error 8
[ 8.0544213] kobj_checksyms, 1026: [%M/exec_elf64/exec_elf64.kmod]: linker
error: global symbol `coredump_elf64' redefined
[ 8.0544213] WARNING: module error: vfs load failed for `exec_elf64', error 8
...
++--+-------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Reti
Re: Build failure for ``no options PTRACE''
OK, I updated kern/kern_core.c to #include exec_elf.h and made is past
the modules.
I'll install in the morning and make sure that all combinations of
modules from {coredump, exec_elf32, exec_elf64} work. At the very
least, they all have to successfully load in any sequence without
requiring any circular dependencies!
More info tomorrow...
On Sat, 17 Oct 2020, Paul Goyette wrote:
On Sat, 17 Oct 2020, Christos Zoulas wrote:
Just add their declarations in exec_elf.h they have the same signatures as
the "unreal" ones :-)
Tried that, but now kern_core.c won't compile as part of the coredump
module:
...
# compile coredump/kern_core.o
... (gcc command line elided)
In file included from /build/netbsd-local/src_ro/sys/sys/compat_stub.h:35,
from /build/netbsd-local/src_ro/sys/kern/kern_core.c:53:
/build/netbsd-local/src_ro/sys/kern/kern_core.c: In function
'coredump_modcmd':
/build/netbsd-local/src_ro/sys/kern/kern_core.c:80:40: error:
'real_coredump_elf32' undeclared (first use in this function); did you mean
'real_coredump_netbsd'?
80 | MODULE_HOOK_SET(coredump_elf32_hook, real_coredump_elf32);
|^~~
/build/netbsd-local/src_ro/sys/kern/kern_core.c:80:40: note: each undeclared
identifier is reported only once for each function it appears in
/build/netbsd-local/src_ro/sys/kern/kern_core.c:81:40: error:
'real_coredump_elf64' undeclared (first use in this function); did you mean
'real_coredump_netbsd'?
81 | MODULE_HOOK_SET(coredump_elf64_hook, real_coredump_elf64);
|^~~
*** [kern_core.o] Error code 1
christos
On Oct 17, 2020, at 1:32 PM, Paul Goyette wrote:
OK, I got a build failure for modules:
# compile coredump/kern_core.o
/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-gcc -O2 -g
-std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional
-Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual
-Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror
-Wno-error=address-of-packed-member -ffreestanding -fno-strict-aliasing
-Wno-pointer-sign -mno-red-zone -mno-mmx -mno-sse -mno-avx -msoft-float
-mcmodel=kernel -fno-omit-frame-pointer
-I/build/netbsd-local/src/common/include -DDIAGNOSTIC
--sysroot=/build/netbsd-local/dest/amd64
-I/build/netbsd-local/src/common/include -DDIAGNOSTIC -nostdinc -I.
-I/build/netbsd-local/src/sys/modules/coredump -isystem
/build/netbsd-local/src/sys -isystem /build/netbsd-local/src/sys/arch
-isystem /build/netbsd-local/src/sys/../common/include -D_KERNEL -D_MODULE
-DSYSCTL_INCLUDE_DESCR -c -Wno-cast-function-type
/build/netbsd-local/src/sys/kern/kern_
core.c
In file included from /build/netbsd-local/src/sys/sys/compat_stub.h:35,
from /build/netbsd-local/src/sys/kern/kern_core.c:53:
/build/netbsd-local/src/sys/kern/kern_core.c: In function
'coredump_modcmd':
/build/netbsd-local/src/sys/kern/kern_core.c:80:40: error:
'real_coredump_elf32' undeclared (first use in this function); did you
mean 'real_coredump_netbsd'?
80 | MODULE_HOOK_SET(coredump_elf32_hook, real_coredump_elf32);
|^~~
/build/netbsd-local/src/sys/kern/kern_core.c:80:40: note: each undeclared
identifier is reported only once for each function it appears in
/build/netbsd-local/src/sys/kern/kern_core.c:81:40: error:
'real_coredump_elf64' undeclared (first use in this function); did you
mean 'real_coredump_netbsd'?
81 | MODULE_HOOK_SET(coredump_elf64_hook, real_coredump_elf64);
|^~~
*** [kern_core.o] Error code 1
nbmake[2]: stopped in /build/netbsd-local/src/sys/modules/coredump
1 error
nbmake[2]: stopped in /build/netbsd-local/src/sys/modules/coredump
ERROR: Failed to make dependall in "sys/modules"
*** BUILD ABORTED ***
On Sat, 17 Oct 2020, Paul Goyette wrote:
Oh, ignore this for now. I might have to also rebuild my modules again.
On Sat, 17 Oct 2020, Paul Goyette wrote:
On Sat, 17 Oct 2020, Paul Goyette wrote:
Thanks - I'll give it a try.
OK, it builds. But it doesn't work, and least not completely!
FWIW, in addition to
no options COREDUMP
no options PTRACE
my custom kernel also has
no options EXEC_ELF32
no options EXEC_ELF64
These modules are expected to be auto-loaded as necessary.
It seems that the exec_elf* modules fail to load, since the symbol
coredump_elf{32,64} is already defined in the kernel, even though
I have the ``no options EXEC_ELF*'' in the config.
...
[ 8.0347157] init: copying out path `/sbin/init' 11
[ 8.0544213] kobj_checksyms, 1026: [%M/exec_elf32/exec_elf32.kmod]:
linker error: global symbol `coredump_elf32' redefined
[ 8.0544213] WARNING: module error: vfs load failed for `e
Re: Build failure for ``no options PTRACE''
On Sat, 17 Oct 2020, Paul Goyette wrote:
OK, I updated kern/kern_core.c to #include exec_elf.h and made is past
the modules.
I'll install in the morning and make sure that all combinations of
modules from {coredump, exec_elf32, exec_elf64} work. At the very
least, they all have to successfully load in any sequence without
requiring any circular dependencies!
I guess I actually spoke too soon. #include exec_elf.h allowed me to
compile kern_core.c but it then failed to compile kern/core_elf32.c
with the following errors:
# compile coredump/core_elf32.o
/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-gcc -O2 -g
-std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
-Wno-unused-parameter -Wno-sign-compare -Werror
-Wno-error=address-of-packed-member -ffreestanding -fno-strict-aliasing
-Wno-pointer-sign -mno-red-zone -mno-mmx -mno-sse -mno-avx -msoft-float
-mcmodel=kernel -fno-omit-frame-pointer
-I/build/netbsd-local/src_ro/common/include -DDIAGNOSTIC
--sysroot=/build/netbsd-local/dest/amd64
-I/build/netbsd-local/src_ro/common/include -DDIAGNOSTIC -nostdinc -I.
-I/build/netbsd-local/src_ro/sys/modules/coredump -isystem
/build/netbsd-local/src_ro/sys -isystem /build/netbsd-local/src_ro/sys/arch
-isystem /build/netbsd-local/src_ro/sys/../common/include -D_KERNEL -D_MODULE
-DSYSCTL_INCLUDE_DESCR -c/build/netbsd-local/src_ro/sys/kern/core_elf3
2.c
In file included from /build/netbsd-local/src_ro/sys/kern/core_elf32.c:42:
/build/netbsd-local/src_ro/sys/kern/core_elf32.c: In function
'coredump_note_procinfo':
/build/netbsd-local/src_ro/sys/kern/core_elf32.c:424:13: error: implicit
declaration of function 'coredump_savenote_elf32'; did you mean
'coredump_note_elf32'? [-Werror=implicit-function-declaration]
424 | ELFNAMEEND(coredump_savenote)(ns, ELF_NOTE_NETBSD_CORE_PROCINFO,
| ^
/build/netbsd-local/src_ro/sys/kern/core_elf32.c: In function
'coredump_note_elf32':
/build/netbsd-local/src_ro/sys/kern/core_elf32.c:541:2: error: 'PT32_GETXSTATE'
undeclared (first use in this function); did you mean 'PT64_GETXSTATE'?
541 | COREDUMP_MACHDEP_LWP_NOTES(l, ns, d->name);
| ^~
/build/netbsd-local/src_ro/sys/kern/core_elf32.c:541:2: note: each undeclared
identifier is reported only once for each function it appears in
/build/netbsd-local/src_ro/sys/kern/core_elf32.c: At top level:
/build/netbsd-local/src_ro/sys/kern/core_elf32.c:583:12: error: no previous
prototype for 'coredump_savenote_elf32' [-Werror=missing-prototypes]
583 | ELFNAMEEND(coredump_savenote)(struct note_state *ns, unsigned int type,
|^
/build/netbsd-local/src_ro/sys/kern/core_elf32.c:583:12: error: conflicting
types for 'coredump_savenote_elf32' [-Werror]
/build/netbsd-local/src_ro/sys/kern/core_elf32.c:424:13: note: previous
implicit declaration of 'coredump_savenote_elf32' was here
424 | ELFNAMEEND(coredump_savenote)(ns, ELF_NOTE_NETBSD_CORE_PROCINFO,
| ^
cc1: all warnings being treated as errors
*** [core_elf32.o] Error code 1
I'm getting lost inside all this elf stuff :)
Just add their declarations in exec_elf.h they have the same signatures as
the "unreal" ones :-)
Tried that, but now kern_core.c won't compile as part of the coredump
module:
...
# compile coredump/kern_core.o
... (gcc command line elided)
In file included from /build/netbsd-local/src_ro/sys/sys/compat_stub.h:35,
from /build/netbsd-local/src_ro/sys/kern/kern_core.c:53:
/build/netbsd-local/src_ro/sys/kern/kern_core.c: In function
'coredump_modcmd':
/build/netbsd-local/src_ro/sys/kern/kern_core.c:80:40: error:
'real_coredump_elf32' undeclared (first use in this function); did you mean
'real_coredump_netbsd'?
80 | MODULE_HOOK_SET(coredump_elf32_hook, real_coredump_elf32);
|^~~
/build/netbsd-local/src_ro/sys/kern/kern_core.c:80:40: note: each
undeclared identifier is reported only once for each function it appears in
/build/netbsd-local/src_ro/sys/kern/kern_core.c:81:40: error:
'real_coredump_elf64' undeclared (first use in this function); did you mean
'real_coredump_netbsd'?
81 | MODULE_HOOK_SET(coredump_elf64_hook, real_coredump_elf64);
|^~~
*** [kern_core.o] Error code 1
FWIW, in addition to
no options COREDUMP
no options PTRACE
my custom kernel also has
no options EXEC_ELF32
no options EXEC_ELF64
These modules are expected to be auto-loaded as necessary.
It seems that the exec_elf* modules fail to load, since the symbol
coredump_elf{32,64} is already defined in the kernel, even though
I have the ``no opt
Re: Build failure for ``no options PTRACE''
I've opened PR kern/55731 for this issue. On Sun, 18 Oct 2020, Kamil Rytarowski wrote: On 18.10.2020 15:00, Paul Goyette wrote: I'm getting lost inside all this elf stuff?? :) ptrace is not really pluggable and the maintenance burden to have part of it as loadable modules questions the usefulness of this. My request to demodularize it stands. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: -current amd64 build failure
=== 2 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/share/man/html3/getentropy.html ./usr/share/man/man3/getentropy.3 = end of 2 extra files === The build finished OK after I removed the two files from destdir, as expected. Apparently they have been obsoleted just after I initiated my last overnight full build from scratch. That's because nia@ simply removed the entries in the sets-list file rather than marking them as obsolete! Nia, please fix! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: -current amd64 build failure
On Thu, 24 Sep 2020, Paul Goyette wrote: === 2 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/share/man/html3/getentropy.html ./usr/share/man/man3/getentropy.3 = end of 2 extra files === The build finished OK after I removed the two files from destdir, as expected. Apparently they have been obsoleted just after I initiated my last overnight full build from scratch. That's because nia@ simply removed the entries in the sets-list file rather than marking them as obsolete! Nia, please fix! Looks like nia@ is offline right now, so I just committed the fix for this. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Another build failure for MKDEBUG=yes
Even after Roy's most recent commits (sources updated on 2020-09-30 at 20:42:53 UTC) I am seeing the following error: ... checkflist ===> distrib/sets === 3 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/libdata/debug/usr/tests/net/if_tap ./usr/libdata/debug/usr/tests/net/if_tap/rump_open_tap.debug ./usr/libdata/debug/usr/tests/net/if_vether = end of 3 extra files === --- checkflist --- *** [checkflist] Error code 1 ... ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Build broken when MKDEBUG=yes
An amd64 build (on a 9.99.73 NetBSD-amd64 host) fails when building with -V MKDEBUG=yes Here's the error detail: ... install ===> tests/net/if_tap # install /build/netbsd-compat/dest/amd64/usr/libdata/debug/usr/tests/net/if_tap/rump_open_tap.debug /build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-install -U -M /build/netbsd-compat/dest/amd64/METALOG -D /build/netbsd-compat/dest/amd64 -h sha256 -N /build/netbsd-compat/src_ro/etc -c -p -r -o root -g wheel -m 444 rump_open_tap.debug /build/netbsd-compat/dest/amd64/usr/libdata/debug/usr/tests/net/if_tap/rump_open_tap.debug x86_64--netbsd-install: /build/netbsd-compat/dest/amd64/usr/libdata/debug/usr/tests/net/if_tap/rump_open_tap.debug.inst.nKLa0w: mkstemp: No such file or directory *** [/build/netbsd-compat/dest/amd64/usr/libdata/debug/usr/tests/net/if_tap/rump_open_tap.debug] Error code 1 nbmake[7]: stopped in /build/netbsd-compat/src_ro/tests/net/if_tap 1 error nbmake[7]: stopped in /build/netbsd-compat/src_ro/tests/net/if_tap (Also reported to roy@ on IRC) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: How to load ffs module via boot.cfg?
On Mon, 1 Jun 2020, Paul Goyette wrote: On Mon, 1 Jun 2020, Jukka Ruohonen wrote: On Mon, Jun 01, 2020 at 01:36:01PM +0300, Jukka Ruohonen wrote: I'd like to run amd64/MODULAR, but I have forgotten how to load modules via the boot loader. In particular, I need FFS in order to boot. To reply to myself: it works if I uncomment "-no file-system FFS". I do not know whether I actually have ever had FFS as a module. It's really easy. Just fix your syntax: load=ffs Also, you'll need to include a couple of dependency/required modules: load=ufs load=wapbl And finally, there are a couple of options which are not yet modular. You may need to remove some options from the modules' Makefile and build custom modules. Oh yeah, one more thing! You will also need to update the boot loader stuff: Index: sys/lib/libsa/ffsv1.c === RCS file: /cvsroot/src/sys/lib/libsa/ffsv1.c,v retrieving revision 1.7 diff -u -p -r1.7 ffsv1.c --- sys/lib/libsa/ffsv1.c 24 Jun 2019 13:58:24 - 1.7 +++ sys/lib/libsa/ffsv1.c 5 May 2020 19:39:22 - @@ -15,7 +15,7 @@ #define ufs_dinode ufs1_dinode #define indp_t int32_t -#if 0 +#if 1 /*XXX-PRG 0 */ #defineFSMOD "wapbl/ufs/ffs" #endif Index: sys/lib/libsa/ffsv2.c === RCS file: /cvsroot/src/sys/lib/libsa/ffsv2.c,v retrieving revision 1.7 diff -u -p -r1.7 ffsv2.c --- sys/lib/libsa/ffsv2.c 24 Jun 2019 13:58:24 - 1.7 +++ sys/lib/libsa/ffsv2.c 5 May 2020 19:39:23 - @@ -15,7 +15,7 @@ #define ufs_dinode ufs2_dinode #define indp_t int64_t -#if 0 +#if 1 /*XXX-PRG 0 */ #defineFSMOD "wapbl/ufs/ffs" #endif In any case, amd64/MODULAR is not really that modular... $ modstat | grep builtin | wc -l 143 You can strip out a lot more modules and still have a functioning system. Mostly you can remove all the device drivers for devices that don't exist, but there are other things, too. FWIW, $ modstat | grep builtin | wc -l 21 $ ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: How to load ffs module via boot.cfg?
On Mon, 1 Jun 2020, Jukka Ruohonen wrote: On Mon, Jun 01, 2020 at 01:36:01PM +0300, Jukka Ruohonen wrote: I'd like to run amd64/MODULAR, but I have forgotten how to load modules via the boot loader. In particular, I need FFS in order to boot. To reply to myself: it works if I uncomment "-no file-system FFS". I do not know whether I actually have ever had FFS as a module. It's really easy. Just fix your syntax: load=ffs Also, you'll need to include a couple of dependency/required modules: load=ufs load=wapbl And finally, there are a couple of options which are not yet modular. You may need to remove some options from the modules' Makefile and build custom modules. In any case, amd64/MODULAR is not really that modular... $ modstat | grep builtin | wc -l 143 You can strip out a lot more modules and still have a functioning system. Mostly you can remove all the device drivers for devices that don't exist, but there are other things, too. FWIW, $ modstat | grep builtin | wc -l 21 $ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: How to load ffs module via boot.cfg?
On Mon, 1 Jun 2020, Jukka Ruohonen wrote: FWIW, $ modstat | grep builtin | wc -l 21 Nice! Since you seem to have this nailed down already, do you have time to update the off-the-shelf MODULAR config? I'd also fancy a good development kernel with which I can unload/patch/load/etc. as much code as is possible. I've left the MODULAR kernel to Christos. My local kernel is very specific to my local set-up, and it has (almost) all of my devices hardwired and includes no unneeded device drivers. In addition, I have _no_ file-systems defined, only a few of the "standard system options", and no unnecessary pseudo-devices. I've disabled all of the following (which are enabled in sys/conf/std on all kernels): no options EXEC_SCRIPT no options EXEC_ELF64 no options COREDUMP no options AIO no options MQUEUE no options SEMAPHORE no options PTRACE (Note that SEMAPHORE is actually an addition in my local tree (I have resurrected the old ksem module!) so my local kernel has to exclude it. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Build failure for ``build.sh release'' on amd64
With sources updated on 2020-05-22 at 20:57:47 UTC, I'm getting the
following errors:
# link XEN3_DOM0/netbsd
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld -Map netbsd.map
--cref -T netbsd.ldscript -Ttext 0x8020 -e start -X -o netbsd
${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ} vers.o swapnetbsd.o
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld: pci_stub.o: in
function `pci_msi_alloc':
/build/netbsd-compat/src_ro/sys/dev/pci/pci_stub.c:112: multiple definition of
`pci_msi_alloc';
pci_msi_machdep.o:/build/netbsd-compat/src_ro/sys/arch/x86/pci/pci_msi_machdep.c:504:
first defined here
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld: pci_stub.o: in
function `pci_msi_alloc_exact':
/build/netbsd-compat/src_ro/sys/dev/pci/pci_stub.c:120: multiple definition of
`pci_msi_alloc_exact';
pci_msi_machdep.o:/build/netbsd-compat/src_ro/sys/arch/x86/pci/pci_msi_machdep.c:534:
first defined here
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld: pci_stub.o: in
function `pci_msix_alloc':
/build/netbsd-compat/src_ro/sys/dev/pci/pci_stub.c:120: multiple definition of
`pci_msix_alloc';
pci_msi_machdep.o:/build/netbsd-compat/src_ro/sys/arch/x86/pci/pci_msi_machdep.c:563:
first defined here
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld: pci_stub.o: in
function `pci_msix_alloc_exact':
/build/netbsd-compat/src_ro/sys/dev/pci/pci_stub.c:120: multiple definition of
`pci_msix_alloc_exact';
pci_msi_machdep.o:/build/netbsd-compat/src_ro/sys/arch/x86/pci/pci_msi_machdep.c:590:
first defined here
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld: pci_stub.o: in
function `pci_msix_alloc_map':
/build/netbsd-compat/src_ro/sys/dev/pci/pci_stub.c:144: multiple definition of
`pci_msix_alloc_map';
pci_msi_machdep.o:/build/netbsd-compat/src_ro/sys/arch/x86/pci/pci_msi_machdep.c:624:
first defined here
*** [netbsd] Error code 1
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: How to load ffs module via boot.cfg?
On Tue, 2 Jun 2020, Jukka Ruohonen wrote: On Mon, Jun 01, 2020 at 05:26:16AM -0700, Paul Goyette wrote: You can strip out a lot more modules and still have a functioning system. Mostly you can remove all the device drivers for devices that don't exist, but there are other things, too. Another small module question: when running a -current kernel with 9.0 userland, the compat_90 module is loaded, as I believe it should given the MODULAR_DEFAULT_AUTOLOAD option. Due to module_start_unload_thread(9), it is also over and over again unloaded: $ modstat > d && sleep 3 && modstat > dd && diff -u d dd --- d 2020-06-02 08:19:44.893168878 +0300 +++ dd 2020-06-02 08:19:47.915516801 +0300 @@ -26,6 +26,7 @@ cir driver builtin -1 - ir clockctl driver builtin -0 - - coda vfs builtin -0 - vcoda +compat_90 exec filesys a0 - - compat_util misc builtin -0 - - coredump misc builtin -0 - - coretemp driver boot -0 - sysmon_envsys This kind of constant unload/load trashing does not seem optimal. I would expect there to be also a performance impact. So can I control module unloading at runtime? That is, I want: $ sysctl kern.module.autoload kern.module.autoload = 1 But there is no "kern.module.autounload", which I would want to be 0. Set kern.module.autotime=0 to disable auto-unload ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Failure to build graphics/graphviz
With up-to-date pkgsrc running on a NetBSD 9.99.66 amd64 host: => Automatic manual page handling => Generating post-install file lists => Checking file-check results for graphviz-2.44.1 ERROR: ERROR: The following files are in /tmp/pkgs/graphics/graphviz/work.x86_64/.destdir/usr/pkg but not in the PLIST: ERROR: /tmp/pkgs/graphics/graphviz/work.x86_64/.destdir/usr/pkg/man/man3/gv.3python ERROR: /tmp/pkgs/graphics/graphviz/work.x86_64/.destdir/usr/pkg/share/graphviz/doc/pdf/gv.3python.pdf *** Error code 1 ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Failure to build graphics/graphviz
Oops wrong list - please ignore On Thu, 6 Aug 2020, Paul Goyette wrote: With up-to-date pkgsrc running on a NetBSD 9.99.66 amd64 host: => Automatic manual page handling => Generating post-install file lists => Checking file-check results for graphviz-2.44.1 ERROR: ERROR: The following files are in /tmp/pkgs/graphics/graphviz/work.x86_64/.destdir/usr/pkg but not in the PLIST: ERROR: /tmp/pkgs/graphics/graphviz/work.x86_64/.destdir/usr/pkg/man/man3/gv.3python ERROR: /tmp/pkgs/graphics/graphviz/work.x86_64/.destdir/usr/pkg/share/graphviz/doc/pdf/gv.3python.pdf *** Error code 1 ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ !DSPAM:5f2c8619260971627217311! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Failure to build graphics/graphviz
I just rebuilt it under 9.99.69 from yesterday without any problems. I do not have any graphviz option changed in /etc/mk.conf. There have been many changes to make recently. Hmmm. I have PKG_OPTIONS.graphviz= -lua to prevent it from using lua. Maybe the PLIST for the two extra files should be conditional on lua? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Failure to build graphics/graphviz
On Fri, 7 Aug 2020, m...@netbsd.org wrote: On Thu, Aug 06, 2020 at 03:38:31PM -0700, Paul Goyette wrote: Oops wrong list - please ignore It's actually a netbsd issue, but I think it'd be reasonable to USE_TOOLS+= gmake until it is fixed. Adding gmake doesn't help - fails with exact same error. http://gnats.netbsd.org/55539 I'll look when gnats.netbsd.org is available. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Failure to build graphics/graphviz
On Fri, 7 Aug 2020, Chavdar Ivanov wrote:
On Fri, 7 Aug 2020 at 21:35, Paul Goyette wrote:
I just rebuilt it under 9.99.69 from yesterday without any problems. I
do not have any graphviz option changed in /etc/mk.conf. There have
been many changes to make recently.
Hmmm. I have
PKG_OPTIONS.graphviz= -lua
to prevent it from using lua. Maybe the PLIST for the two extra files
should be conditional on lua?
Correct, perhaps an error:
# grep python PLIST
${PLIST.lua}man/man3/gv.3python
${PLIST.lua}share/graphviz/doc/pdf/gv.3python.pdf
Doesn't make sense.
Rebuilt successfully after removing the ${PLIST.lua} stuff.
Should I commit the change?
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: System crash
On Sat, 8 Aug 2020, Robert Nestor wrote: Stumbled over this trying to check on the format of a NetBSD CD. This is a newly installed system of 9.99.69 downloaded two days ago with all the installed packages rebuilt and installed under it, so everything is pretty much up to date. vndconfig -c vnd0 NetBSD-9.99.69-amd64.iso gpt show vnd0 And the system immediately crashed. Now maybe what I tried doing isn't permitted, but should the system crash just from trying to do it? No it should not crash. Please file a PR ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Strange vi behavior
When trying to edit a file to which I don't have access, vi reports a "record not found" error rather than reporting a permissions error! I noticed while trying to edit /var/log/maillog from a non-privileged user. :) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Build error on amd64
While building tools, I get In file included from /build/netbsd-local/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/i386netbsd.c:38: /build/netbsd-local/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/ netbsd.h:54:10: fatal error: bfd.h: No such file or directory #include "bfd.h" ^~~ compilation terminated. *** [i386netbsd.lo] Error code 1 ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
build failure for amd64
With sources updated on Wed Jul 1 14:05:15 UTC 2020, and with a completely empty $OBJDIR and $DESTDIR, I got the following error: ... depend ===> etc/amd64/kmod nbmake[4]: nbmake[4]: don't know how to make miniroot.kmod.c. Stop nbmake[4]: stopped in $SRCDIR/distrib/amd64/kmod ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build error for HEAD on amd64
Looks like this has already been fixed. On Thu, 2 Jul 2020, Paul Goyette wrote: With sources updated on 2020-07-02 at 14:06:53 UTC, and using build.sh -T /build/netbsd-compat/tools/x86_64/amd64 \ -D /build/netbsd-compat/dest/amd64 \ -O /build/netbsd-compat/obj/amd64 \ -R /build/netbsd-compat/release \ -V RELEASEMACHINEDIR=amd64 \ -V MKDEBUG=yes \ -V MKKDEBUG=yes \ -U -N2 -m amd64 -j1 release I get: /build/netbsd-compat/src_ro/external/bsd/dhcpcd/dist/src/logerr.c: In function 'vlogprintf_r': /build/netbsd-compat/src_ro/external/bsd/dhcpcd/dist/src/logerr.c:120:8: error:unused variable 'err' [-Werror=unused-variable] FILE *err; ^~~ cc1: all warnings being treated as errors *** [logerr.o] Error code 1 ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Build error on amd64 -current
With up-to-date sources I'm getting /build/netbsd-compat/src_ro/sys/arch/xen/x86/cpu.c: In function 'mp_cpu_start': /build/netbsd-compat/src_ro/sys/arch/xen/x86/cpu.c:999:1: error: stack usage is5408 bytes [-Werror=stack-usage=] mp_cpu_start(struct cpu_info *ci, vaddr_t target) ^~~~ cc1: all warnings being treated as errors *** [cpu.o] Error code 1 nbmake[2]: stopped in /build/netbsd-compat/obj/amd64/sys/arch/amd64/compile/INSTALL_XEN3_DOMU 1 error ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Another build failure for amd64
With MKDEBUG=yes I get the following: === 1 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/libdata/debug/usr/tests/lib/libc/stdlib/t_mbtowc.debug = end of 1 extra files === *** [checkflist] Error code 1 ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Build error with MKDEBUG=yes
With MKDEBUG=yes I get == 1 missing files in DESTDIR Files in flist but missing from DESTDIR. File wasn't installed ? -- ./usr/libdata/debug/usr/tests/lib/libprop/t_basic.debug end of 1 missing files == *** [checkflist] Error code 1 This is with sources updated on 2020-06-07 at 19:48:54 UTC ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: compiling amd64-kernel fails (w/o cgd)
Known issue, riastradh@ should be fixing soon. As a workaround, add ``select chacha'' to yhe end of your kernel config. On Tue, 28 Jul 2020, Kurt Schreiner wrote: Hi, after cvs-updating -current an hour or so ago, compiling a new (custonized) kernel fails like so: making sure the kern library is up to date... `libkern.o' is up to date. create vers.c compile vNBx64/vers.o link vNBx64/netbsd /u/NetBSD/arch/amd64/TOOLS/bin/x86_64--netbsd-ld: identcpu.o: in function `cpu_probe': /u/NetBSD/src/sys/arch/x86/x86/identcpu.c:1024: undefined reference to `chacha_sse2_impl' /u/NetBSD/arch/amd64/TOOLS/bin/x86_64--netbsd-ld: /u/NetBSD/src/sys/arch/x86/x86/identcpu.c:1024: undefined reference to `chacha_md_init' --- netbsd --- *** [netbsd] Error code 1 nbmake: stopped in /u/NetBSD/arch/amd64/obj/sys/arch/amd64/compile/vNBx64 1 error If I add "pseudo-devicecgd" to my configuration, compiling a new kernel works fine again. Is there a technical reason for chacha & co depending on cgd? And is it documented somewhere? ;-) Kurt !DSPAM:5f201fff161574613110541! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Missing "something" in nvme config messages
On Tue, 28 Jul 2020, Jaromír Dole�~Mek wrote: I changed the message, now it should say 'ld at nvme0 nsid 1 not configured' Thanks! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Recent addition of chacha breaks custom config build (amd64)
I ran into a undefined reference to chacha_md_init() while building a kernel (configs attached). On IRC I discovered a work-around of "add ``select chacha'' at the end of the config. Seems that this should be fixed to not require explicit selection of the option. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+include "arch/amd64/conf/std.amd64" #ident "GENERIC-$Revision: 1.573 $" ident "WHOOPPEE-common" options INCLUDE_CONFIG_FILE # embed config file in kernel binary config netbsd root on ? type ffs maxusers64 # estimated number of users # Remove standard options, as they are provided by modules no options EXEC_SCRIPT no options EXEC_ELF64 no options COREDUMP no options AIO no options MQUEUE no options SEMAPHORE no options PTRACE # Standard system options options INSECURE# disable kernel security levels - X needs this options RTC_OFFSET=0# hardware clock is this many mins. west of GMT options NTP # NTP phase/frequency locked loop options KTRACE # system call tracing via ktrace(1) options CPU_UCODE # cpu ucode loading support options KDTRACE_HOOKS # kernel DTrace hooks options MODULAR # new style module(7) framework options MODULAR_DEFAULT_AUTOLOAD options VGA_POST# in-kernel support for VGA POST options USERCONF# userconf(4) support options SYSCTL_INCLUDE_DESCR# Include sysctl descriptions in kernel # CPU-related options options USER_LDT# User-settable LDT, used by Wine options SVS # Separate Virtual Space options PCPU_IDT# Per CPU IDTs # GCC Spectre variant 2 mitigation makeoptions SPECTRE_V2_GCC_MITIGATION=1 options SPECTRE_V2_GCC_MITIGATION options DIAGNOSTIC # inexpensive kernel consistency checks options DEBUG # expensive debugging checks/support options LOCKDEBUG # expensive locking checks/support options MSGBUFSIZE=524288 makeoptions COPTS="-O2 -fno-omit-frame-pointer" makeoptions DEBUG="-g" # compile full symbol table - CTF needs this # DDB_* options - see ddb(4), sysctl(7), and options(4) options DDB # in-kernel debugger #optionsDDB_ONPANIC=1 # enter ddb if panic(9) options DDB_COMMANDONENTER="bt" # backtrace at entry #optionsDDB_DUMPSTACK=1 # backtrace at entry options DDB_HISTORY_SIZE=512# enable history editing in DDB # File systems #file-systemFFS # UFS #optionsQUOTA2 # new, in-filesystem UFS quotas #optionsFFS_EI # FFS Endian Independent support #optionsDISKLABEL_EI# disklabel Endian Independent support #optionsWAPBL # File system journaling support #optionsUFS_EXTATTR # Extended attribute support for UFS1 # Networking options options INET# IP + ICMP + TCP + UDP options INET6 # IPV6 pseudo-device loop# network loopback # wscons options # options WSEMUL_VT100# VT100 / VT220 emulation options WS_KERNEL_FG=WSCOL_GREEN #optionsWS_KERNEL_BG=WSCOL_BLACK # compatibility to other console drivers options WSDISPLAY_COMPAT_PCVT # emulate some ioctls options WSDISPLAY_COMPAT_SYSCONS# emulate some ioctls options WSDISPLAY_COMPAT_USL# wsconscfg VT handling options WSDISPLAY_COMPAT_RAWKBD # can get raw scancodes # don't attach pckbd as the console if no PS/2 keyboard is found options PCKBD_CNATTACH_MAY_FAIL options PCDISPLAY_SOFTCURSOR options WSDISPLAY_SCROLLSUPPORT pseudo-device wsmux # mouse & keyboard multiplexor # Give us a choice of font depending on monitor size pseudo-device wsfont options FONT_BOLD8x16 options FONT_BOLD16x32 # Miscellaneous options options FILEASSOC # fileassoc(9) - needed by Veriexec # and PAX_SEGVGUARD options PAX_SEGVGUARD=0 # PaX Segmentation fault guard options PAX_MPROTECT=1 # PaX mprotect(2) restrictions options PAX_MPROTECT_DEBUG=1# PaX mprotect debug options PAX_ASLR=1 # PaX Address Space Layout Randomization options PAX_ASLR_DEBUG=1# PaX ASLR debug
Build failure on HEAD for amd64 in sys/modules/nvmm
With up-to-date sources, I'm getting /build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-gcc -O2 -g -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror -ffreestanding -fno-strict-aliasing -Wno-pointer-sign -mno-red-zone -mno-mmx -mno-sse -mno-avx -msoft-float -mcmodel=kernel -fno-omit-frame-pointer -I/build/netbsd-compat/src_ro/common/include -DDIAGNOSTIC --sysroot=/build/netbsd-compat/dest/amd64 -I/build/netbsd-compat/src_ro/common/include -DDIAGNOSTIC -nostdinc -I. -I/build/netbsd-compat/src_ro/sys/modules/nvmm -isystem /build/netbsd-compat/src_ro/sys -isystem /build/netbsd-compat/src_ro/sys/arch -isystem /build/netbsd-compat/src_ro/sys/../common/include -D_KERNEL -D_LKM -D_MODULE -DSYSCTL_INCLUDE_DESCR -c /build/netbsd-compat/src_ro/sys/dev/nvmm/x86/nvmm_x86_vmx.c /build/netbsd-compat/src_ro/sys/dev/nvmm/x86/nvmm_x86_vmx.c:193: error: "MSR_IA32_FEATURE_CONTROL" redefined [-Werror] #define MSR_IA32_FEATURE_CONTROL 0x003A In file included from /build/netbsd-compat/src_ro/sys/dev/nvmm/x86/nvmm_x86_vmx.c:48: ./x86/specialreg.h:868: note: this is the location of the previous definition #define MSR_IA32_FEATURE_CONTROL 0x03a cc1: all warnings being treated as errors *** [nvmm_x86_vmx.o] Error code 1 nbmake[8]: stopped in /build/netbsd-compat/src_ro/sys/modules/nvmm 1 error nbmake[8]: stopped in /build/netbsd-compat/src_ro/sys/modules/nvmm ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Unfinished unichrome driver
BTW, we should _not_ remove things from the ALL configs. The ALL is supposed to contain "just about everything". ALL is _never_ guaranteed to work, or even reliably build! :) On Wed, 15 Jul 2020, m...@netbsd.org wrote: On Wed, Jul 15, 2020 at 09:18:09PM +0300, Andrius V wrote: Hi, Since my VIA based hardware wasn't attaching a unichrome driver, I decided to take a look at it. After investigation, I found out that the driver had been mainly unfinished: * It matches only one unichrome graphics ID from (CN700 and related chipsets) and have some hard coded values referencing it here and there (also, erratically driver refers to graphics from non existent CN900 chipset in few places, including pcidevs, likely CN700 was meant). * The code itself has definitions for some other unichrome graphics from CN400, CLE266 (and related) chipsets but not the newer ones (VX800/VX855/VX900). * Not included in amd64 ports, similarly to some other VIA specific hardware drivers. * It is mentioned in amd64 ALL configuration but without wsdisplay* at unichromefb?. Likely leftover from i386 and should be removed for now, same as viadrmums (which causes system to crash in amd64, at least on VX800/900). * Driver was made compatible with the legacy viadrm driver but it doesn't seem to work with viadrmums. My system crashed spectacularly once both enabled. It successfully attached and booted with higher resolution for me on CN400 unichrome graphics, once I added its ID without any other modifications. So, I believe, adding support for all unichrome drivers should not be too hard. Not sure why it was abandoned and what was unfinished though. So out of that I am planning to create PRs unless someone can look at those: * Add support for all unichrome graphics (possibly can take a look at this)... * Make it compatible with viadrmums as it was with viadrm, if that possible. Besides that I believe tha viadrmums and unichromefb should be removed from amd64 ALL kernel configuration, at least for now. And CN900 should be renamed to CN700 in all places. Regards, Andrius V There's someone working on drm*kms* drivers for VIA graphics hardware for Linux, and also the X driver. It's a good direction to look for anyone that is interested. !DSPAM:5f0fc1f8262394047222629! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 build failure
This has already been fixed - thanks, Roy! On Fri, 3 Jul 2020, NetBSD Test Fixture wrote: 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 2020.07.03.11.03.42. An extract from the build.sh output follows: obsolete_stand fix: postinstall fixes passed: obsolete_stand postinstall fixes failed: AWK=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbawk DB=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbdb HOST_SH=/bin/sh MAKE=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbmake PWD_MKDB=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbpwd_mkdb SED=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbsed STAT=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbstat /bin/sh /tmp/bracket/build/2020.07.03.11.03.42-i386/obj/usr.sbin/postinstall/postinstall -m i386 -a i386 -s /tmp/bracket/build/2020.07.03.11.03.42-i386/src -d /tmp/bracket/build/2020.07.03.11.03.42-i386/destdir/ fix obsolete_stand_debug Source directory: /tmp/bracket/build/2020.07.03.11.03.42-i386/src Target directory: /tmp/bracket/build/2020.07.03.11.03.42-i386/destdir/ obsolete_stand_debug fix: postinstall fixes passed: obsolete_stand_debug postinstall fixes failed: === checkflist ===> distrib/sets --- check_DESTDIR --- --- checkflist --- cd /tmp/bracket/build/2020.07.03.11.03.42-i386/src/distrib/sets && DESTDIR=/tmp/bracket/build/2020.07.03.11.03.42-i386/destdir MACHINE=i386 MACHINE_ARCH=i386 AWK=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbawk CKSUM=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbcksum DB=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbdb EGREP=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbgrep\ -E HOST_SH=/bin/sh MAKE=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbmake MKTEMP=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbmktemp MTREE=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbmtree PAX=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbpax COMPRESS_PROGRAM=gzip GZIP=-n XZ_OPT=-9 TAR_SUFF=tgz PKG_CREATE=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbpkg_create SED=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbsed TSORT=/tmp/bracket/build/2020.07.03.11.03.42-i386/tools/bin/nbts o rt\ -q /bin/sh /tmp/bracket/build/2020.07.03.11.03.42-i386/src/distrib/sets/checkflist -L base -M /tmp/bracket/build/2020.07.03.11.03.42-i386/destdir/METALOG.sanitised === 1 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./var/db/dhcpcd = end of 1 extra files === *** [checkflist] Error code 1 nbmake[2]: stopped in /tmp/bracket/build/2020.07.03.11.03.42-i386/src/distrib/sets 1 error The following commits were made between the last successful build and the failed build: 2020.07.03.10.19.18 jmcneill src/sys/arch/arm/arm32/db_machdep.c,v 1.34 2020.07.03.10.19.18 jmcneill src/sys/arch/arm/include/arm32/db_machdep.h,v 1.10 2020.07.03.10.45.43 roy src/external/bsd/dhcpcd/dist/src/defs.h,v 1.1.1.45 2020.07.03.10.46.45 roy src/external/bsd/dhcpcd/dist/src/dhcpcd.c,v 1.41 2020.07.03.10.47.29 roy src/doc/3RDPARTY,v 1.1735 2020.07.03.10.47.29 roy src/doc/CHANGES,v 1.2708 2020.07.03.11.03.42 roy src/etc/mtree/NetBSD.dist.base,v 1.221 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.07.html#2020.07.03.11.03.42 !DSPAM:5eff331c222464894717810! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Repeated crash on 9.99.76 in audio
Twice today I have experienced a panic on my amd64 9.99.76 (built from yesterday's sources). In both cases, the display remains on wsdisplay vt04 - the X session. And in both cases, the crash was immediately following a switch in firefox tabs. The first time, I did not wait long enough for the crash dump to be completely written. Luckily, I waited longer for the second occurrence. Here's the backtrace, as recorded in the dmesg (retrived via crash(8)): (there are _hundreds_ of the following ''table is full'' message for at least 3 full seconds) [ 37928.6031590] file: table is full - increase kern.maxfiles or MAXFILES [ 37928.6031590] file: table is full - increase kern.maxfiles or MAXFILES [ 37928.6231664] file: table is full - increase kern.maxfiles or MAXFILES [ 37928.6231664] file: table is full - increase kern.maxfiles or MAXFILES [ 37928.6231664] panic: kernel diagnostic assertion "sc->sc_rbusy == false" failed: file "/build/netbsd-local/src_ro/sys/dev/audio/audio.c", line 5587 [ 37928.6231664] cpu1: Begin traceback... [ 37928.6231664] vpanic() at netbsd:vpanic+0x156 [ 37928.6231664] __x86_indirect_thunk_rax() at netbsd:__x86_indirect_thunk_rax [ 37928.6231664] audio_rmixer_start() at audio:audio_rmixer_start+0xe7 [ 37928.6231664] audio_open.isra.0() at audio:audio_open.isra.0+0x2ad [ 37928.6231664] audioopen() at audio:audioopen+0x18f [ 37928.6231664] spec_open() at netbsd:spec_open+0x176 [ 37928.6231664] VOP_OPEN() at netbsd:VOP_OPEN+0x3c [ 37928.6231664] vn_open() at netbsd:vn_open+0x130 [ 37928.6231664] do_open() at netbsd:do_open+0x119 [ 37928.6231664] do_sys_openat() at netbsd:do_sys_openat+0x74 [ 37928.6231664] sys_open() at netbsd:sys_open+0x24 [ 37928.6231664] syscall() at netbsd:syscall+0x23e [ 37928.6231664] --- syscall (number 5) --- [ 37928.6231664] netbsd:syscall+0x23e: [ 37928.6231664] cpu1: End traceback... Using gdb on the crash file, I get (gdb) bt #0 0x80223945 in cpu_reboot (howto=howto@entry=256, bootstr=bootstr@entry=0x0) at /build/netbsd-local/src_ro/sys/arch/amd64/amd64/machdep.c:713 #1 0x8060e5c5 in kern_reboot (howto=256, bootstr=bootstr@entry=0x0) at /build/netbsd-local/src_ro/sys/kern/kern_reboot.c:73 #2 0x8054de29 in db_reboot_cmd (addr=, have_addr=, count=, modif=) at /build/netbsd-local/src_ro/sys/ddb/db_command.c:1471 #3 0x8054e637 in db_command ( last_cmdp=last_cmdp@entry=0x8b892c18c6a8) at /build/netbsd-local/src_ro/sys/ddb/db_command.c:955 #4 0x8054e9ea in db_execute_commandlist ( cmdlist=0x80a2b5c0 "bt; reboot 0x100") at /build/netbsd-local/src_ro/sys/ddb/db_command.c:452 #5 db_command_loop () at /build/netbsd-local/src_ro/sys/ddb/db_command.c:604 #6 0x80552503 in db_trap (type=type@entry=1, code=code@entry=0) at /build/netbsd-local/src_ro/sys/ddb/db_trap.c:91 #7 0x80220b4f in kdb_trap (type=type@entry=1, code=code@entry=0, regs=regs@entry=0x8b892c18c960) at /build/netbsd-local/src_ro/sys/arch/amd64/amd64/db_interface.c:249 #8 0x80225c76 in trap (frame=0x8b892c18c960) at /build/netbsd-local/src_ro/sys/arch/amd64/amd64/trap.c:315 #9 0x8021ead3 in alltraps () #10 0x in ?? () (gdb) (I've previously encountered the maxfiles limitation, and had set it to 5120 (vs old default of 3,000-ish). I see that there is a new default of 2, but I forgot to remove it from /etc/sysctl.conf so it was being _reduced_ to 5120!) So, I'm going to run now with maxfiles left at the 20k default. HOWEVER, it seems to me that the system should not panic here! It feels like the audio driver is mishandling an error return from what- ever it is doing that requires a new file. I suspect that systems with less memory than I have will probably have a lower limit and are thus likely to hit this same error. Has anyone else ever seen this? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, 2 Dec 2020, Thomas Klausner wrote:
On Wed, Dec 02, 2020 at 11:28:41AM +0100, Thomas Klausner wrote:
The new default for the pkgsrc database (which contains information
about all installed packages) in pkgsrc-HEAD has changed from
/var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).
Since some people have trouble installing a new pkg_install from
pkgsrc (because it depends on cwrappers, which depends on pkg_install)
- the easiest way to get a new pkg_install from pkgsrc is this:
cd /usr/pkgsrc/pkgtools/pkg_install
make USE_CWRAPPERS=no install
That will build pkg_install without cwrappers.
I suggest replacing /usr/sbin/pkg_* with /usr/pkg/sbin/pkg_* after
this succeeds to avoid further problems.
(I'm one of the "somple haqve trouble installing..." mentioned above!)
Well, that's a bit of a problem for me. I'm building everything in
a chroot to a freshly-created sandbox (from sysutils/mksandbox) and
/usr is a read-only null-mount file-system. So I cannot copy the
pkgsrc images to the "real" system. (And I'm not sure I would want
to be able to affect the "real" system's /usr/bin/ from within the
chroot sandbox.)
++--+-------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, 2 Dec 2020, Thomas Klausner wrote:
On Wed, Dec 02, 2020 at 02:57:01PM -0800, Paul Goyette wrote:
On Wed, 2 Dec 2020, Thomas Klausner wrote:
On Wed, Dec 02, 2020 at 11:28:41AM +0100, Thomas Klausner wrote:
The new default for the pkgsrc database (which contains information
about all installed packages) in pkgsrc-HEAD has changed from
/var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).
Since some people have trouble installing a new pkg_install from
pkgsrc (because it depends on cwrappers, which depends on pkg_install)
- the easiest way to get a new pkg_install from pkgsrc is this:
cd /usr/pkgsrc/pkgtools/pkg_install
make USE_CWRAPPERS=no install
That will build pkg_install without cwrappers.
I suggest replacing /usr/sbin/pkg_* with /usr/pkg/sbin/pkg_* after
this succeeds to avoid further problems.
(I'm one of the "somple haqve trouble installing..." mentioned above!)
Well, that's a bit of a problem for me. I'm building everything in
a chroot to a freshly-created sandbox (from sysutils/mksandbox) and
/usr is a read-only null-mount file-system. So I cannot copy the
pkgsrc images to the "real" system. (And I'm not sure I would want
to be able to affect the "real" system's /usr/bin/ from within the
chroot sandbox.)
You can cp it outside the sandbox... and use pkg_install.conf if you
want to keep using the old database directory.
This is just getting too complicated. Too many manual steps, and too
many changes to too many long-established procedures.
It sounds to me like this was not very well thought out and not very
well tested (in sufficient environments) before the change was made.
FWIW, I also don't remember ever seeing any discussion of this change
being made on any non-pkgsrc lists. (If it was discusssed, and I
simply missed it, skip this paragraph!) Since you've changed defaults
withing programs in the base system, a discussion on tech-userlevel
would probably have been appropriate (in addition to any relevant
pkgsrc lists).
++--+-------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: [HEADS UP] pkgsrc default database directory changed
On Wed, 2 Dec 2020, Valery Ushakov wrote:
On Wed, Dec 02, 2020 at 11:28:41 +0100, Thomas Klausner wrote:
There is one potential pitfall: you'll have to make sure
${PREFIX}/sbin/pkg_* is used and not mixed with /usr/sbin/pkg_* (which
will default to the old location until -current and the branches are
updated).
So please make sure your admin user's PATH has ${PREFIX}/sbin before
/usr/sbin, or copy the new pkg_install tools from ${PREFIX}/sbin to
/usr/sbin.
NetBSD daily cron job uses full paths. They can be changed by adding
pkg_admin=/usr/pkg/sbin/pkg_admin
pkg_info=/usr/pkg/sbin/pkg_info
to /etc/pkgpath.conf
And Tobias Nygren replied:
> The new default for the pkgsrc database (which contains information
> about all installed packages) in pkgsrc-HEAD has changed from
> /var/db/pkg to ${PREFIX}/pkgdb (so usually /usr/pkg/pkgdb).
Since this is about changing a default, it should be mentioned in the
heads-up how to stay on the old path if migration is currently not
convenient. To do this one can add PKG_DBDIR=/var/db/pkg to mk.conf
before the new pkg_install is built.
If one adds tnn's suggested entry to /etc/mk.conf, is it also needed
to apply uwe's update to /etc/pkgpath.conf?
One additional series of questions:
* should anything be changed in postinstall(8) to at least check for
the "correct" location?
* should postinstall(8) attempt to fix it? (probably no)
* should postinstall(8) "obey" the suggested changes to mk.conf and/or
pkgpath.conf?
Finally, I looked, and my system doesn't have any file, anywhere
(other than in source trees) with the name ``pkg_install''. Am I
missing something? I've been running pkgsrc for ~forever without
any (apparent) issues.
++--+-------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Build failure for NetBSD-HEAD on amd64
I suspect that the fix for this would be to add a new entry in src/mtree/NetBSD.dist.tests for tests/lib/libossaudio/ On Fri, 11 Dec 2020, Paul Goyette wrote: With sources updated on 2020-12-12 at 01:29:10 UTC, I am getting the following build error: ... install ===> tests/lib/libossaudio # install /build/netbsd-compat/dest/amd64/usr/tests/lib/libossaudio/Atffile /build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-install -U -M /build/netbsd-compat/dest/amd64/METALOG -D /build/netbsd-compat/dest/amd64 -h sha256 -N /build/netbsd-compat/src_ro/etc -c -r -o root -g wheel -m 444 Atffile /build/netbsd-compat/dest/amd64/usr/tests/lib/libossaudio/Atffile x86_64--netbsd-install: /build/netbsd-compat/dest/amd64/usr/tests/lib/libossaudio/Atffile.inst.NSIKiN: mkstemp: No such file or directory *** [/build/netbsd-compat/dest/amd64/usr/tests/lib/libossaudio/Atffile] Error code 1 nbmake[7]: stopped in /build/netbsd-compat/src_ro/tests/lib/libossaudio 1 error ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Build failure for NetBSD-HEAD on amd64
With sources updated on 2020-12-12 at 01:29:10 UTC, I am getting the following build error: ... install ===> tests/lib/libossaudio # install /build/netbsd-compat/dest/amd64/usr/tests/lib/libossaudio/Atffile /build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-install -U -M /build/netbsd-compat/dest/amd64/METALOG -D /build/netbsd-compat/dest/amd64 -h sha256 -N /build/netbsd-compat/src_ro/etc -c -r -o root -g wheel -m 444 Atffile /build/netbsd-compat/dest/amd64/usr/tests/lib/libossaudio/Atffile x86_64--netbsd-install: /build/netbsd-compat/dest/amd64/usr/tests/lib/libossaudio/Atffile.inst.NSIKiN: mkstemp: No such file or directory *** [/build/netbsd-compat/dest/amd64/usr/tests/lib/libossaudio/Atffile] Error code 1 nbmake[7]: stopped in /build/netbsd-compat/src_ro/tests/lib/libossaudio 1 error ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Using wg(4) with a commerical VPN provider
On Wed, 11 Nov 2020, Jason Thorpe wrote:
On Nov 10, 2020, at 5:49 PM, Brad Spencer wrote:
--- sys/net/if_wg.c.DIST2020-10-26 10:36:30.391354264 -0400
+++ sys/net/if_wg.c 2020-10-30 19:13:46.910323221 -0400
@@ -98,8 +98,8 @@
#include
#include
-#ifdef INET6
#include
+#ifdef INET6
#include
#include
#include
@@ -1611,7 +1611,16 @@
wg_get_so_by_af(struct wg_softc *wg, const int af)
{
+#if defined(INET) && defined(INET6)
return (af == AF_INET) ? wg->wg_so4 : wg->wg_so6;
+#else
+#ifdef INET
+ return wg->wg_so4;
+#endif
+#ifdef INET6
+ return wg->wg_so6;
+#endif
+#endif
}
Seems ... not great to put #ifdefs like this in something that can be
build as a module?
Yeah - what he said! :)
++--+-------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: netbsd32_coredump
That should already be fixed. Can you update to HEAD? On Sat, 14 Nov 2020, Patrick Welche wrote: Just upgraded a pi zero w from 9.99.10 to 9.99.75/evbarm-earmv6hf i.e., 32 bit, and on boot with a standard RPI kernel and new dtb (but presumably old startelf) panic: kernel diagnostic assertion "!*hooked" failed: file "/usr/src/sys/kern/kern_module_hook.c", line 70 0x8097ae3c: netbsd:vpanic+0xc 0x8097ae54: netbsd:kern_assert+0x3c 0x8097ae84: netbsd:module_hook_set+0x98 0x8097aea4: netbsd:compat_netbsd32_coredump_modcmd+0xa0 0x8097af0c: netbsd:module_do_builtin+0x16c 0x8097af4c: netbsd:module_init_class+0x210 0x8097af9c: netbsd:main+0x38c 0x8097afac: netbsd:kernel_text+0x54 Cheers, Patrick !DSPAM:5fb01321213834049013268! ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
XEN help needed
Hello all you XEN experts! I've got a XEN3_DOMU virtual machine currently running NetBSD 8.1, and hosted on a commercial provider (www.prgmr.com). Since I'm running 8.1 I think that implies that I'm running in HVM mode? Anyway, the provider will soon be upgrading their host to a PVHVM-only environment. That means that I need to upgrade, to -current. So, a few questions. (I'm a really dummy when it comes to XEN, so please forgive me if the questions don't make sense! Where's my copy of O'Reilly's ``XEN For Dummies'' when I need it? :) ) 1. Since I'm switching to PVHVM, will there be any differences in the "visible" devices? Will I need to update my kernel config? Or will a -current XEN3_DOMU kernel work "out of the box"? 2. Will I be able to update only my kernel, and continue running my 8.1 userland? 3. Will I need to make any configuration changes to things in /etc ? I'm really reluctant to update my userland at this time unless it is absolutely necessary. Thanks in advance for any advice you can offer. ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 build failure
Working on it ... On Wed, 4 Nov 2020, NetBSD Test Fixture wrote: 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 2020.11.04.18.12.19. An extract from the build.sh output follows: --- dependall-sys --- In file included from /tmp/build/2020.11.04.18.12.19-i386/src/sys/kern/sys_ptrace_common.c:130: /tmp/build/2020.11.04.18.12.19-i386/src/sys/sys/ptrace.h:244:5: note: previous definition of 'ptrace_common_init' was here 244 | int ptrace_common_init(void); | ^~ /tmp/build/2020.11.04.18.12.19-i386/src/sys/kern/sys_ptrace_common.c:1585:1: error: redefinition of 'ptrace_common_fini' 1585 | ptrace_common_fini(void) | ^~ In file included from /tmp/build/2020.11.04.18.12.19-i386/src/sys/kern/sys_ptrace_common.c:130: /tmp/build/2020.11.04.18.12.19-i386/src/sys/sys/ptrace.h:245:5: note: previous definition of 'ptrace_common_fini' was here 245 | int ptrace_common_fini(void); | ^~ --- dependall-tests --- #create chacha/.depend rm -f .depend --- dependall-crypto/external --- --- ssh --- --- dependall-tests --- CC=/tmp/build/2020.11.04.18.12.19-i386/tools/bin/i486--netbsdelf-gcc /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbmkdep -s .o\ .ln\ .d -d -f .depend chacha_ref.d chacha_selftest.d chacha_sse2.d chacha_sse2_impl.d t_chacha.d --- dependall-crypto/external --- # link ssh/ssh /tmp/build/2020.11.04.18.12.19-i386/tools/bin/i486--netbsdelf-gcc --sysroot=/tmp/build/2020.11.04.18.12.19-i386/destdir -pie -shared-libgcc -Wl,--warn-shared-textrel -Wl,-z,relro -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect2.o mux.o auth.o gss-genr.o -Wl,-rpath-link,/tmp/build/2020.11.04.18.12.19-i386/destdir/lib -L=/lib -lgssapi -lheimntlm -lkrb5 -lcom_err -lhx509 -lcrypto -lasn1 -lwind -lheimbase -lcom_err -lroken -lsqlite3 -lm -lcrypt -lutil -lssh -lcrypto -lcrypt -lz --- dependall-tests --- --- dependall --- --- dependall-crypto --- /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbctfconvert -g -L VERSION bftest.o --- dependall-rump --- /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbctfconvert -g -L VERSION h_stresscli.o --- dependall-sys --- --- .gdbinit --- --- dependall-sys --- --- dependall-ipl --- /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbctfconvert -L VERSION ip_scan.o --- dependall-tests --- --- dependall-crypto --- --- h_bftest --- --- dependall-sys --- --- dependall-procfs --- --- procfs_note.d --- --- dependall-tests --- --- dependall-rump --- --- h_forkcli --- --- dependall-sys --- rm -f .gdbinit --- dependall-sys --- --- dependall-ptrace_common --- *** [sys_ptrace_common.o] Error code 1 --- dependall-tests --- --- dependall-crypto --- The following commits were made between the last successful build and the failed build: 2020.11.04.18.12.18 pgoyette src/sys/kern/sys_ptrace_common.c,v 1.90 2020.11.04.18.12.19 pgoyette src/sys/sys/ptrace.h,v 1.73 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.11.html#2020.11.04.18.12.19 !DSPAM:5fa2fd60115747723319370! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 build failure
Should be fixed now... On Wed, 4 Nov 2020, NetBSD Test Fixture wrote: 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 2020.11.04.18.12.19. An extract from the build.sh output follows: --- dependall-sys --- In file included from /tmp/build/2020.11.04.18.12.19-i386/src/sys/kern/sys_ptrace_common.c:130: /tmp/build/2020.11.04.18.12.19-i386/src/sys/sys/ptrace.h:244:5: note: previous definition of 'ptrace_common_init' was here 244 | int ptrace_common_init(void); | ^~ /tmp/build/2020.11.04.18.12.19-i386/src/sys/kern/sys_ptrace_common.c:1585:1: error: redefinition of 'ptrace_common_fini' 1585 | ptrace_common_fini(void) | ^~ In file included from /tmp/build/2020.11.04.18.12.19-i386/src/sys/kern/sys_ptrace_common.c:130: /tmp/build/2020.11.04.18.12.19-i386/src/sys/sys/ptrace.h:245:5: note: previous definition of 'ptrace_common_fini' was here 245 | int ptrace_common_fini(void); | ^~ --- dependall-tests --- #create chacha/.depend rm -f .depend --- dependall-crypto/external --- --- ssh --- --- dependall-tests --- CC=/tmp/build/2020.11.04.18.12.19-i386/tools/bin/i486--netbsdelf-gcc /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbmkdep -s .o\ .ln\ .d -d -f .depend chacha_ref.d chacha_selftest.d chacha_sse2.d chacha_sse2_impl.d t_chacha.d --- dependall-crypto/external --- # link ssh/ssh /tmp/build/2020.11.04.18.12.19-i386/tools/bin/i486--netbsdelf-gcc --sysroot=/tmp/build/2020.11.04.18.12.19-i386/destdir -pie -shared-libgcc -Wl,--warn-shared-textrel -Wl,-z,relro -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect2.o mux.o auth.o gss-genr.o -Wl,-rpath-link,/tmp/build/2020.11.04.18.12.19-i386/destdir/lib -L=/lib -lgssapi -lheimntlm -lkrb5 -lcom_err -lhx509 -lcrypto -lasn1 -lwind -lheimbase -lcom_err -lroken -lsqlite3 -lm -lcrypt -lutil -lssh -lcrypto -lcrypt -lz --- dependall-tests --- --- dependall --- --- dependall-crypto --- /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbctfconvert -g -L VERSION bftest.o --- dependall-rump --- /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbctfconvert -g -L VERSION h_stresscli.o --- dependall-sys --- --- .gdbinit --- --- dependall-sys --- --- dependall-ipl --- /tmp/build/2020.11.04.18.12.19-i386/tools/bin/nbctfconvert -L VERSION ip_scan.o --- dependall-tests --- --- dependall-crypto --- --- h_bftest --- --- dependall-sys --- --- dependall-procfs --- --- procfs_note.d --- --- dependall-tests --- --- dependall-rump --- --- h_forkcli --- --- dependall-sys --- rm -f .gdbinit --- dependall-sys --- --- dependall-ptrace_common --- *** [sys_ptrace_common.o] Error code 1 --- dependall-tests --- --- dependall-crypto --- The following commits were made between the last successful build and the failed build: 2020.11.04.18.12.18 pgoyette src/sys/kern/sys_ptrace_common.c,v 1.90 2020.11.04.18.12.19 pgoyette src/sys/sys/ptrace.h,v 1.73 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.11.html#2020.11.04.18.12.19 !DSPAM:5fa2fd60115747723319370! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Problem with ``build.sh install-image'' on amd64 (with various *DEBUG* options)
I'm trying to build an install-image from a release that was built with MKDEBUG=yes MKKDEBUG=yes MKDEBUGLIB=yes all enabled. I was not too surprised when nbmakefs complained that the file system required size of 1515634688 (1450 MB) exceeded the configured size of 1488977920 (1420 MB) - an increase of 30 MB. So I changed distrib/amd64/installimage/Makefile to change INSTIMAGEMB from 1550 to 1580 (an increase of 30 MB). Now, I'm getting an error from nbgpt which I don't know how to resolve: ... rm -f work.efi /build/netbsd-local/tools/x86_64/amd64/bin/nbmakefs -M 128m -m 128m -B 1234 -t msdos -o F=32,c=1 work.efi work.efidir Creating `work.efi' work.efi: 258078 sectors in 258078 FAT32 clusters (512 bytes/cluster) MBR type: 11 bps=512 spc=1 res=32 nft=2 mid=0xf0 spt=63 hds=255 hid=0 bsec=262144 bspf=2017 rdcl=2 infs=1 bkbs=2 Populating `work.efi' Image `work.efi' complete create GPT image... dd if=work.mbr of=work.gpt skip=$((3235840 - 2048)) count=2048 0+0 records in 0+0 records out 0 bytes transferred in 0.001 secs (0 bytes/sec) cat work.mbr.truncated work.efi imgroot.fs work.gpt > work.img /build/netbsd-local/tools/x86_64/amd64/bin/nbgpt work.img biosboot -i 2 -c /build/netbsd-local/obj/amd64/distrib/amd64/installimage/work/usr/mdec/gptmbr.bin nbgpt: work.img: No secondary GPT header; run recover *** Failed target: NetBSD-9.99.77-amd64-install.img Any clues on how to fix this? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Problem with ``build.sh install-image'' on amd64 (with various *DEBUG* options)
On Fri, 15 Jan 2021, Paul Goyette wrote: I'm trying to build an install-image from a release that was built with MKDEBUG=yes MKKDEBUG=yes MKDEBUGLIB=yes all enabled. Oh, I also have the KERNEL_DIR=yes option enabled. I was not too surprised when nbmakefs complained that the file system required size of 1515634688 (1450 MB) exceeded the configured size of 1488977920 (1420 MB) - an increase of 30 MB. So I changed distrib/amd64/installimage/Makefile to change INSTIMAGEMB from 1550 to 1580 (an increase of 30 MB). Now, I'm getting an error from nbgpt which I don't know how to resolve: ... rm -f work.efi /build/netbsd-local/tools/x86_64/amd64/bin/nbmakefs -M 128m -m 128m -B 1234 -t msdos -o F=32,c=1 work.efi work.efidir Creating `work.efi' work.efi: 258078 sectors in 258078 FAT32 clusters (512 bytes/cluster) MBR type: 11 bps=512 spc=1 res=32 nft=2 mid=0xf0 spt=63 hds=255 hid=0 bsec=262144 bspf=2017 rdcl=2 infs=1 bkbs=2 Populating `work.efi' Image `work.efi' complete create GPT image... dd if=work.mbr of=work.gpt skip=$((3235840 - 2048)) count=2048 0+0 records in 0+0 records out 0 bytes transferred in 0.001 secs (0 bytes/sec) cat work.mbr.truncated work.efi imgroot.fs work.gpt > work.img /build/netbsd-local/tools/x86_64/amd64/bin/nbgpt work.img biosboot -i 2 -c /build/netbsd-local/obj/amd64/distrib/amd64/installimage/work/usr/mdec/gptmbr.bin nbgpt: work.img: No secondary GPT header; run recover *** Failed target: NetBSD-9.99.77-amd64-install.img Any clues on how to fix this? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Problem with ``build.sh install-image'' on amd64 (with various *DEBUG* options)
This seems to have been pilot error on my part (failure to clean up properly after initial failure). On Fri, 15 Jan 2021, Paul Goyette wrote: On Fri, 15 Jan 2021, Paul Goyette wrote: I'm trying to build an install-image from a release that was built with MKDEBUG=yes MKKDEBUG=yes MKDEBUGLIB=yes all enabled. Oh, I also have the KERNEL_DIR=yes option enabled. I was not too surprised when nbmakefs complained that the file system required size of 1515634688 (1450 MB) exceeded the configured size of 1488977920 (1420 MB) - an increase of 30 MB. So I changed distrib/amd64/installimage/Makefile to change INSTIMAGEMB from 1550 to 1580 (an increase of 30 MB). Now, I'm getting an error from nbgpt which I don't know how to resolve: ... rm -f work.efi /build/netbsd-local/tools/x86_64/amd64/bin/nbmakefs -M 128m -m 128m -B 1234 -t msdos -o F=32,c=1 work.efi work.efidir Creating `work.efi' work.efi: 258078 sectors in 258078 FAT32 clusters (512 bytes/cluster) MBR type: 11 bps=512 spc=1 res=32 nft=2 mid=0xf0 spt=63 hds=255 hid=0 bsec=262144 bspf=2017 rdcl=2 infs=1 bkbs=2 Populating `work.efi' Image `work.efi' complete create GPT image... dd if=work.mbr of=work.gpt skip=$((3235840 - 2048)) count=2048 0+0 records in 0+0 records out 0 bytes transferred in 0.001 secs (0 bytes/sec) cat work.mbr.truncated work.efi imgroot.fs work.gpt > work.img /build/netbsd-local/tools/x86_64/amd64/bin/nbgpt work.img biosboot -i 2 -c /build/netbsd-local/obj/amd64/distrib/amd64/installimage/work/usr/mdec/gptmbr.bin nbgpt: work.img: No secondary GPT header; run recover *** Failed target: NetBSD-9.99.77-amd64-install.img Any clues on how to fix this? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ !DSPAM:6001b22218604175613795! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
crash in amd64 -current
With sources updated a few hours ago (2021-01-21 at 17:17:48 UTC) I am getting the following crash as soon as it tries to start syslogd: breakpoint() at breakpoint+0x5 vpanic() at vpanic+0x156 snprintf() at snprintf kqueue_check() at kqueue_check+0x183 kevent1() at kevent1+0x49f sys___kevent50() at sys___kevent50+0x33 syscall() at syscall+0x23e --- syscall (number 435) --- syscall+0x23e: Also, why the heck does savecore(8) complain when I use the -N option? # savecore -fN /netbsd.bad.gdb savecore: dumpdev /dev/console is tty; override kernel ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
