daily CVS update output
Updating src tree: U src/distrib/sets/sort-list P src/distrib/sets/lists/comp/mi P src/distrib/sets/lists/modules/md.hppa P src/distrib/sets/lists/tests/mi P src/distrib/sets/lists/text/mi P src/distrib/sets/lists/xserver/md.evbmips P src/sys/arch/alpha/alpha/clock.c P src/sys/arch/alpha/alpha/dec_2100_a50.c P src/sys/arch/alpha/alpha/dec_2100_a500.c P src/sys/arch/alpha/alpha/dec_6600.c P src/sys/arch/alpha/alpha/dec_kn20aa.c P src/sys/arch/alpha/alpha/dec_kn8ae.c P src/sys/arch/alpha/alpha/locore.s P src/sys/arch/alpha/alpha/machdep.c P src/sys/arch/alpha/alpha/multiproc.s P src/sys/arch/alpha/alpha/patch.c P src/sys/arch/alpha/alpha/prom.c P src/sys/arch/alpha/conf/GENERIC P src/sys/arch/alpha/conf/GENERIC.MP P src/sys/arch/alpha/conf/INSTALL cvs update: `src/sys/arch/alpha/conf/RAWHIDE' is no longer in the repository P src/sys/arch/alpha/include/asm.h P src/sys/arch/alpha/include/cpu.h P src/sys/arch/alpha/include/types.h P src/sys/arch/mips/include/proc.h P src/sys/arch/pmax/pmax/machdep.c P src/sys/arch/x86/include/specialreg.h P src/sys/dev/nvmm/nvmm.c P src/sys/dev/nvmm/x86/nvmm_x86.c P src/sys/dev/nvmm/x86/nvmm_x86_svm.c P src/sys/dev/nvmm/x86/nvmm_x86_vmx.c P src/sys/miscfs/genfs/genfs_rename.c P src/sys/ufs/lfs/lfs_vnops.c P src/sys/ufs/lfs/ulfs_lookup.c P src/sys/ufs/ufs/ufs_lookup.c P src/sys/ufs/ufs/ufs_vnops.c P src/tests/fs/vfs/t_renamerace.c P src/usr.bin/make/cond.c P src/usr.bin/make/for.c P src/usr.bin/make/lst.c P src/usr.bin/make/lst.h P src/usr.bin/make/parse.c P src/usr.bin/make/var.c P src/usr.bin/make/unit-tests/Makefile P src/usr.bin/make/unit-tests/archive.exp P src/usr.bin/make/unit-tests/archive.mk P src/usr.bin/make/unit-tests/cond-func-empty.mk cvs update: `src/usr.bin/make/unit-tests/hash.exp' is no longer in the repository cvs update: `src/usr.bin/make/unit-tests/hash.mk' is no longer in the repository P src/usr.bin/make/unit-tests/varmod-hash.mk U src/usr.bin/make/unit-tests/varname-makefile.exp U src/usr.bin/make/unit-tests/varname-makefile.mk Updating xsrc tree: Killing core files: Updating tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting...pax: Unable to access src/gnu (No such file or directory) pax: WARNING! These file names were not selected: src/gnu done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc: collecting... replacing... done Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.3 P sys/dev/pci/ixgbe/if_bypass.c P sys/dev/pci/ixgbe/ixgbe.c P sys/dev/pci/ixgbe/ixgbe_82598.c P sys/dev/pci/ixgbe/ixgbe_82599.c P sys/dev/pci/ixgbe/ixgbe_common.c P sys/dev/pci/ixgbe/ixgbe_phy.c P sys/dev/pci/ixgbe/ixgbe_type.h P sys/dev/pci/ixgbe/ixgbe_x550.c P sys/netinet/tcp_input.c Updating release-8 xsrc tree (netbsd-8): Updating release-8 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting...pax: Unable to access src/gnu (No such file or directory) pax: WARNING! These file names were not selected: src/gnu done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting...
Re: Status of COMPAT_LINUX and Linux emulation?
On Fri, 4 Sep 2020 at 22:39, Thomas Klausner wrote: > > On Wed, Sep 02, 2020 at 11:41:41PM +0200, Jaromír Doleček wrote: > > COMPAT_LINUX works as well as always, and will continue working the > > same. Presence in GENERIC does not change how reliable it is now or in > > future. There are no plans to remove the actual code, the option as > > well as the kernel module will continue working. > > I just tried (on 9.99.72/amd64): > > # sysctl -w kern.module.verbose = 1 > # modload compat_linux > modload: compat_linux: No such file or directory > > In /var/log/messages I found: > > DEBUG: module: Loading module from > /stand/amd64/9.99.72/modules/compat_linux/compat_linux.kmod > kobj_sym_lookup, 908: [%M/...t_linux/compat_linux.kmod]: linker error: local > symbol @0 undefined > DEBUG: module: Cannot load kernel object `compat_linux' error=2 > > The kernel is a GENERIC + SCTP + font change, the module is from a > 'build.sh'. Do I need to create the modules specifically for my > slightly modified kernel? If yes, what's the easiest way? FWIF, on unmodified GENERIC, I get: # modstat compat_linux NAME CLASSSOURCE FLAG REFSSIZE REQUIRES # modload compat_linux # modstat compat_linux NAME CLASSSOURCE FLAG REFSSIZE REQUIRES compat_linux exec filesys -0 52392 compat_ossaudio,sysv_ipc,compat_util,compat_50,compat_43,exec_elf64 # uname -a NetBSD ymir 9.99.72 NetBSD 9.99.72 (GENERIC) #9: Wed Sep 2 17:47:42 BST 2020 sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC amd64 # /usr/pkg/emul/linux/bin/sh sh-4.2# The module was built with the system. > > Thomas Chavdar --
Re: Status of COMPAT_LINUX and Linux emulation?
On Wed, Sep 02, 2020 at 11:41:41PM +0200, Jaromír Doleček wrote: > COMPAT_LINUX works as well as always, and will continue working the > same. Presence in GENERIC does not change how reliable it is now or in > future. There are no plans to remove the actual code, the option as > well as the kernel module will continue working. I just tried (on 9.99.72/amd64): # sysctl -w kern.module.verbose = 1 # modload compat_linux modload: compat_linux: No such file or directory In /var/log/messages I found: DEBUG: module: Loading module from /stand/amd64/9.99.72/modules/compat_linux/compat_linux.kmod kobj_sym_lookup, 908: [%M/...t_linux/compat_linux.kmod]: linker error: local symbol @0 undefined DEBUG: module: Cannot load kernel object `compat_linux' error=2 The kernel is a GENERIC + SCTP + font change, the module is from a 'build.sh'. Do I need to create the modules specifically for my slightly modified kernel? If yes, what's the easiest way? Thomas
Unable to send packets with ixg(4) driver and NetBSD-9_stable
hello. I'm trying to get a 10G interface working on a NetBSD-9.0_stable/amd64 machine. I'm able to receive packets on this interface, but appear to be unable to send packets, though the driver doesn't report any errors. Is this a known issue? Version and driver details below. This is with Netbsd-9 CVS sources as of 09/03/2020. Ideas on how to go about troubleshooting this would be greatly appreciated. -thanks -Brian NetBSD 9.0_STABLE (GENERIC) #0: Fri Sep 4 09:06:40 PDT 2020 buh...@nat-1.via.net:/usr/local/netbsd/obj-64/sys/arch/amd64/compile/GENERIC total memory = 32759 MB avail memory = 31784 MB . . . ixg0 at pci4 dev 0 function 0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 4.0.1-k ixg0: device 82599EB ixg0: ETrackID 86c5 ixg0: for TX/RX, interrupting at msix2 vec 0, bound queue 0 to cpu 0 ixg0: for TX/RX, interrupting at msix2 vec 1, bound queue 1 to cpu 1 ixg0: for TX/RX, interrupting at msix2 vec 2, bound queue 2 to cpu 2 ixg0: for TX/RX, interrupting at msix2 vec 3, bound queue 3 to cpu 3 ixg0: for TX/RX, interrupting at msix2 vec 4, bound queue 4 to cpu 4 ixg0: for TX/RX, interrupting at msix2 vec 5, bound queue 5 to cpu 5 ixg0: for TX/RX, interrupting at msix2 vec 6, bound queue 6 to cpu 6 ixg0: for TX/RX, interrupting at msix2 vec 7, bound queue 7 to cpu 7 ixg0: for TX/RX, interrupting at msix2 vec 8, bound queue 8 to cpu 8 ixg0: for TX/RX, interrupting at msix2 vec 9, bound queue 9 to cpu 9 ixg0: for TX/RX, interrupting at msix2 vec 10, bound queue 10 to cpu 10 ixg0: for TX/RX, interrupting at msix2 vec 11, bound queue 11 to cpu 11 ixg0: for TX/RX, interrupting at msix2 vec 12, bound queue 12 to cpu 12 ixg0: for TX/RX, interrupting at msix2 vec 13, bound queue 13 to cpu 13 ixg0: for TX/RX, interrupting at msix2 vec 14, bound queue 14 to cpu 14 ixg0: for TX/RX, interrupting at msix2 vec 15, bound queue 15 to cpu 15 ixg0: for link, interrupting at msix2 vec 16, affinity to cpu 0 ixg0: Using MSI-X interrupts with 17 vectors ixg0: Ethernet address a0:36:9f:66:47:24 ixg0: PCI Express Bus: Speed 5.0GT/s Width x8 ixg0: feature cap 0x1780 ixg0: feature ena 0x400 ixg1 at pci4 dev 0 function 1: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 4.0.1-k ixg1: device 82599EB WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules. ixg1: ETrackID 86c5 ixg1: for TX/RX, interrupting at msix3 vec 0, bound queue 0 to cpu 0 ixg1: for TX/RX, interrupting at msix3 vec 1, bound queue 1 to cpu 1 ixg1: for TX/RX, interrupting at msix3 vec 2, bound queue 2 to cpu 2 ixg1: for TX/RX, interrupting at msix3 vec 3, bound queue 3 to cpu 3 ixg1: for TX/RX, interrupting at msix3 vec 4, bound queue 4 to cpu 4 ixg1: for TX/RX, interrupting at msix3 vec 5, bound queue 5 to cpu 5 ixg1: for TX/RX, interrupting at msix3 vec 6, bound queue 6 to cpu 6 ixg1: for TX/RX, interrupting at msix3 vec 7, bound queue 7 to cpu 7 ixg1: for TX/RX, interrupting at msix3 vec 8, bound queue 8 to cpu 8 ixg1: for TX/RX, interrupting at msix3 vec 9, bound queue 9 to cpu 9 ixg1: for TX/RX, interrupting at msix3 vec 10, bound queue 10 to cpu 10 ixg1: for TX/RX, interrupting at msix3 vec 11, bound queue 11 to cpu 11 ixg1: for TX/RX, interrupting at msix3 vec 12, bound queue 12 to cpu 12 ixg1: for TX/RX, interrupting at msix3 vec 13, bound queue 13 to cpu 13 ixg1: for TX/RX, interrupting at msix3 vec 14, bound queue 14 to cpu 14 ixg1: for TX/RX, interrupting at msix3 vec 15, bound queue 15 to cpu 15 ixg1: for link, interrupting at msix3 vec 16, affinity to cpu 0 ixg1: Using MSI-X interrupts with 17 vectors ixg1: Ethernet address a0:36:9f:66:47:26 WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules. ixg1: PCI Express Bus: Speed 5.0GT/s Width x8 ixg1: feature cap 0x1780 ixg1: feature ena 0x400
Re: hang while updating pkg_rolling-replace libvdpau
Hi Chavdar, Chavdar Ivanov wrote: (If you do find a bug in pkg_rr, of which there are many, please do report it. But it is confusing to people to conflate what broke with the program that merely chose the sequence.) In this case I don't think it is anything to do with pkg_rolling-replace; I've reported a few of these hangs, which happen to happen during pkg_rolling-replace, but involve most often cmake, but other programs as well. Apparently there are similarities in the traces, perhaps pointing to the thread model and execution. In all these occasions the process in question continued to a successful conclusion after attaching and then detaching with gdb. I think you are right. I then tried manually updating some packages with "make replace"... and I got a hang also when building glib2. So pkg_rolling-replacing is just on top and has nothing to do with it. The place and file where the hang occours is consistent. In my case, libvdpau is not using cmake! you can see on the command line CMAKE=false It is involving make, python and meson: 9344 pts/5 T0:00.11 /usr/bin/make _MAKE OPSYS OS_VERSION LOWER_OPSYS _PKGSRCDIR PKGTOOLS_VERSION _CC _PATH_ORIG _PKGSRC_BARRIER ALLOW_VULNERABLE_PACKAGES replace 10978 pts/5 T0:00.16 make replace 18674 pts/5 O+ 0:00.01 ps -a 19416 pts/5 T0:00.52 /usr/pkg/bin/python3.7 /usr/pkg/bin/meson --prefix /usr/pkg --libdir lib --mandir man --sysconfdir /usr/pkg/etc --buildtype=plain -Degdir=/usr/pkg/share/examples 20711 pts/5 S0:00.01 -sh 20839 pts/5 T0:00.00 /bin/sh -c set -e;\t\t\t\t\t if test -n "" && /usr/sbin/pkg_info -K /var/db/pkg -qe libvdpau-1.4; then echo ===\\> "Skipping installation of already handled pa Riccardo
Re: hang while updating pkg_rolling-replace libvdpau
Hi David,
David Shao wrote:
Examine recently posted
kern/55641: Recent changes to random/entropy "pkgsrc devel brick" an
Intel Ivy Bridge system, with workaround
It mentions a workaround, but what does it mean to:
dd if=/dev/urandom of=/dev/random bs=32 count=1
sysctl -w kern.entropy.consolidate=1
copy some data from one random generator to another one? Before doing so
I want to know it is fine :)
Try Ctrl-C after the hang. Is there at the bottom of the trace a call
to a random number function?
no, see below.
Do you have something like an Intel Ivy Bridge system?
No, it is an older CPU, it should be a Penryn:
[ 1.03] cpu0 at mainbus0 apid 0
[ 1.03] cpu0: Use lfence to serialize rdtsc
[ 1.03] cpu0: Intel(R) Core(TM)2 Duo CPU T6670 @ 2.20GHz,
id 0x1067a
[ 1.03] cpu0: node 0, package 0, core 0, smt 0
[ 1.03] cpu1 at mainbus0 apid 1
[ 1.03] cpu1: Intel(R) Core(TM)2 Duo CPU T6670 @ 2.20GHz,
id 0x1067a
[ 1.03] cpu1: node 0, package 0, core 1, smt 0
Are you getting some warning message on boot about entropy?
Yes, I see two warnings:
disc$ dmesg | grep entro
[ 1.00] entropy: no seed from bootloader
[ 40596.326165] entropy: WARNING: extracting entropy too early
If I hit ctrl-c I see something inside meson and python and the last is
a random function. So there is probably some similarity.
sudo make replace
^CTraceback (most recent call last):
File "/usr/pkg/bin/meson", line 11, in
load_entry_point('meson==0.55.1', 'console_scripts', 'meson')()
File
"/usr/pkg/lib/python3.7/site-packages/pkg_resources/__init__.py", line
489, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File
"/usr/pkg/lib/python3.7/site-packages/pkg_resources/__init__.py", line
2852, in load_entry_point
return ep.load()
File
"/usr/pkg/lib/python3.7/site-packages/pkg_resources/__init__.py", line
2443, in load
return self.resolve()
File
"/usr/pkg/lib/python3.7/site-packages/pkg_resources/__init__.py", line
2449, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/usr/pkg/lib/python3.7/site-packages/mesonbuild/mesonmain.py",
line 25, in
from . import mconf, mdist, minit, minstall, mintro, msetup, mtest,
rewriter, msubprojects, munstable_coredata, mcompile
File "/usr/pkg/lib/python3.7/site-packages/mesonbuild/minstall.py",
line 22, in
from .mtest import rebuild_all
File "/usr/pkg/lib/python3.7/site-packages/mesonbuild/mtest.py", line
26, in
import multiprocessing
File "/usr/pkg/lib/python3.7/multiprocessing/__init__.py", line 16,
in
from . import context
File "/usr/pkg/lib/python3.7/multiprocessing/context.py", line 5, in
from . import process
File "/usr/pkg/lib/python3.7/multiprocessing/process.py", line 363,
in
_current_process = _MainProcess()
File "/usr/pkg/lib/python3.7/multiprocessing/process.py", line 347,
in __init__
self._config = {'authkey': AuthenticationString(os.urandom(32)),
KeyboardInterrupt
re: crash(8) build failure for playstation2
"John D. Baker" writes: > Since mips-ee/R5900 support returned to GCC, I've made a point to build > distribution and sets for playstation2. Recent changes to crash(8) > and/or mips MD sources causes building crash(8) to fail with: this should be fixed now. thanks for pointing it out. .mrg.
