daily CVS update output
Updating src tree: P src/sys/arch/aarch64/include/cpufunc.h P src/sys/arch/alpha/include/pmap.h P src/sys/dev/pci/if_wm.c P src/sys/external/bsd/common/include/asm/barrier.h P src/sys/external/bsd/drm2/amdgpu/files.amdgpu P src/sys/external/bsd/drm2/dist/drm/drm_agpsupport.c P src/sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_ttm.c P src/sys/external/bsd/drm2/dist/drm/radeon/radeon_ttm.c P src/sys/external/bsd/drm2/dist/include/drm/drm_agpsupport.h P src/sys/external/bsd/drm2/drm/drm_agp_hook.c P src/sys/external/bsd/drm2/drm/drm_cache.c P src/sys/external/bsd/drm2/drm/drm_module.c P src/sys/external/bsd/drm2/drm/files.drmkms P src/sys/external/bsd/drm2/i915drm/files.i915drmkms P src/sys/external/bsd/drm2/include/drm/bus_dma_hacks.h P src/sys/external/bsd/drm2/linux/linux_pci.c P src/sys/external/bsd/drm2/nouveau/files.nouveau P src/sys/external/bsd/drm2/pci/drm_pci_busid.c P src/sys/external/bsd/drm2/pci/files.drmkms_pci P src/sys/external/bsd/drm2/radeon/files.radeon P src/sys/external/bsd/drm2/ttm/files.ttm P src/sys/external/bsd/drm2/ttm/ttm_bo_vm.c P src/sys/external/bsd/drm2/via/files.via P src/sys/external/bsd/drm2/vmwgfx/files.vmwgfx P src/sys/modules/drmkms/Makefile.inc Updating xsrc tree: P xsrc/external/mit/ctwm/dist/ctwm.1 Killing core files: Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 40857179 Jul 20 03:09 ls-lRA.gz
Re: build.sh -m evbarm -a earmv6hf release fails
fixed with src/sys/external/bsd/common/include/asm/barrier.h 1.18
Frank
On 07/19/22 21:43, Frank Kardel wrote:
to compile vchiq_arm.o with today's -current(2022-07-19)
/tmp//cc4Xs586.s: Assembler messages:
/tmp//cc4Xs586.s:1362: Error: selected processor does not support
`dsb' in ARM mode
/tmp//cc4Xs586.s:6689: Error: selected processor does not support
`dsb' in ARM mode
/tmp//cc4Xs586.s:6711: Error: selected processor does not support
`dsb' in ARM mode
--- vchiq_arm.o ---
*** Failed target: vchiq_arm.o
*** Failed commands:
${NORMAL_C}
=> @echo ' ' "compile RPI_INSTALL/vchiq_arm.o" && : echo
/usr/curbtools/bin/armv6--netbsdelf-eabihf-gcc -mfloat-abi=soft
-mapcs-frame -ffreestanding -fno-zero-initialized-in-bss
-fno-delete-null-pointer-checks -O2 -fstack-usage
-Wstack-usage=3584 -fno-strict-aliasing -fno-common -std=gnu99
-Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith
-Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition
-Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code
-Wno-pointer-sign -Wno-attributes -Wno-sign-compare -Walloca
-Wno-address-of-packed-member -march=armv6z -mtune=arm1176jzf-s
-mfpu=vfp --sysroot=/src/NetBSD/cur/BUILD.evbarm -I.
-I/src/NetBSD/cur/src/sys/external/bsd/libnv/dist
-I/src/NetBSD/cur/src/sys/external/bsd/acpica/dist
-I/src/NetBSD/cur/src/sys/../common/lib/libx86emu
-I/src/NetBSD/cur/src/sys/../common/lib/libc/misc
-I/src/NetBSD/cur/src/sys/../common/include
-I/src/NetBSD/cur/src/sys/arch -I/src/NetBSD/cur/src/sys -nostdinc
-DCOMPAT_UTILS -DARM_GENERIC_TODR -D__HAVE_CPU_COUNTER
-D__HAVE_CPU_UAREA_ALLOC_IDLELWP -D__HAVE_FAST_SOFTINTS
-D__HAVE_MM_MD_DIRECT_MAPPED_PHYS -DCOMPAT_44 -DDIAGNOSTIC
-D__HAVE_MM_MD_CACHE_ALIASING -DPLCONSOLE -D_KERNEL -D_KERNEL_OPT
-std=gnu99
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/quad
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/string
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/arch/arm/string
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/arch/arm/atomic
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/hash/sha3
-I/src/NetBSD/cur/src/sys/external/bsd
-I/src/NetBSD/cur/src/sys/external/bsd/common/include
-I/src/NetBSD/cur/src/sys/external/bsd/dwc2/dist
-I/src/NetBSD/cur/src/sys/external/bsd/libfdt/dist
-I/src/NetBSD/cur/src/sys/external/bsd/libnv/dist
-I/src/NetBSD/cur/src/sys/external/bsd/vchiq/dist
-I/src/NetBSD/cur/src/sys/external/bsd/common/include
-DVCOS_VERIFY_BKPTS=1 -DUSE_VCHIQ_ARM -D__VCCOREVER__=0x0400
-DVCHIQ_ENABLE_DEBUG=1 -DVCHIQ_LOG_DEFAULT=5 -c
/src/NetBSD/cur/src/sys/external/bsd/vchiq/dist/interface/vchiq_arm/vchiq_arm.c
-o vchiq_arm.o && /usr/curbtools/bin/armv6--netbsdelf-eabihf-gcc
-mfloat-abi=soft -mapcs-frame -ffreestanding
-fno-zero-initialized-in-bss -fno-delete-null-pointer-checks -O2
-fstack-usage -Wstack-usage=3584 -fno-strict-aliasing -fno-common
-std=gnu99 -Werror -Wall -Wno-main -Wno-format-zero-length
-Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes
-Wold-style-definition -Wswitch -Wshadow -Wcast-qual -Wwrite-strings
-Wno-unreachable-code -Wno-pointer-sign -Wno-attributes
-Wno-sign-compare -Walloca -Wno-address-of-packed-member -march=armv6z
-mtune=arm1176jzf-s -mfpu=vfp --sysroot=/src/NetBSD/cur/BUILD.evbarm
-I. -I/src/NetBSD/cur/src/sys/external/bsd/libnv/dist
-I/src/NetBSD/cur/src/sys/external/bsd/acpica/dist
-I/src/NetBSD/cur/src/sys/../common/lib/libx86emu
-I/src/NetBSD/cur/src/sys/../common/lib/libc/misc
-I/src/NetBSD/cur/src/sys/../common/include
-I/src/NetBSD/cur/src/sys/arch -I/src/NetBSD/cur/src/sys -nostdinc
-DCOMPAT_UTILS -DARM_GENERIC_TODR -D__HAVE_CPU_COUNTER
-D__HAVE_CPU_UAREA_ALLOC_IDLELWP -D__HAVE_FAST_SOFTINTS
-D__HAVE_MM_MD_DIRECT_MAPPED_PHYS -DCOMPAT_44 -DDIAGNOSTIC
-D__HAVE_MM_MD_CACHE_ALIASING -DPLCONSOLE -D_KERNEL -D_KERNEL_OPT
-std=gnu99
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/quad
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/string
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/arch/arm/string
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/arch/arm/atomic
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/hash/sha3
-I/src/NetBSD/cur/src/sys/external/bsd
-I/src/NetBSD/cur/src/sys/external/bsd/common/include
-I/src/NetBSD/cur/src/sys/external/bsd/dwc2/dist
-I/src/NetBSD/cur/src/sys/external/bsd/libfdt/dist
-I/src/NetBSD/cur/src/sys/external/bsd/libnv/dist
-I/src/NetBSD/cur/src/sys/external/bsd/vchiq/dist
-I/src/NetBSD/cur/src/sys/external/bsd/common/include
-DVCOS_VERIFY_BKPTS=1 -DUSE_VCHIQ_ARM -D__VCCOREVER__=0x0400
-DVCHIQ_ENABLE_DEBUG=1 -DVCHIQ_LOG_DEFAULT=5 -c
/src/NetBSD/cur/src/sys/external/bsd/vchiq/dist/interface/vchiq_arm/vchiq_arm.c
-o vchiq_arm.o && : echo /usr/curbtools/bin/nbctfconvert -g -L
VERSION vchiq_arm.o &&
build.sh -m evbarm -a earmv6hf release fails
to compile vchiq_arm.o with today's -current(2022-07-19)
/tmp//cc4Xs586.s: Assembler messages:
/tmp//cc4Xs586.s:1362: Error: selected processor does not support `dsb'
in ARM mode
/tmp//cc4Xs586.s:6689: Error: selected processor does not support `dsb'
in ARM mode
/tmp//cc4Xs586.s:6711: Error: selected processor does not support `dsb'
in ARM mode
--- vchiq_arm.o ---
*** Failed target: vchiq_arm.o
*** Failed commands:
${NORMAL_C}
=> @echo ' ' "compile RPI_INSTALL/vchiq_arm.o" && : echo
/usr/curbtools/bin/armv6--netbsdelf-eabihf-gcc -mfloat-abi=soft
-mapcs-frame -ffreestanding -fno-zero-initialized-in-bss
-fno-delete-null-pointer-checks -O2 -fstack-usage -Wstack-usage=3584
-fno-strict-aliasing -fno-common -std=gnu99 -Werror -Wall -Wno-main
-Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes
-Wstrict-prototypes -Wold-style-definition -Wswitch -Wshadow -Wcast-qual
-Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign -Wno-attributes
-Wno-sign-compare -Walloca -Wno-address-of-packed-member -march=armv6z
-mtune=arm1176jzf-s -mfpu=vfp --sysroot=/src/NetBSD/cur/BUILD.evbarm
-I. -I/src/NetBSD/cur/src/sys/external/bsd/libnv/dist
-I/src/NetBSD/cur/src/sys/external/bsd/acpica/dist
-I/src/NetBSD/cur/src/sys/../common/lib/libx86emu
-I/src/NetBSD/cur/src/sys/../common/lib/libc/misc
-I/src/NetBSD/cur/src/sys/../common/include
-I/src/NetBSD/cur/src/sys/arch -I/src/NetBSD/cur/src/sys -nostdinc
-DCOMPAT_UTILS -DARM_GENERIC_TODR -D__HAVE_CPU_COUNTER
-D__HAVE_CPU_UAREA_ALLOC_IDLELWP -D__HAVE_FAST_SOFTINTS
-D__HAVE_MM_MD_DIRECT_MAPPED_PHYS -DCOMPAT_44 -DDIAGNOSTIC
-D__HAVE_MM_MD_CACHE_ALIASING -DPLCONSOLE -D_KERNEL -D_KERNEL_OPT
-std=gnu99
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/quad
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/string
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/arch/arm/string
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/arch/arm/atomic
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/hash/sha3
-I/src/NetBSD/cur/src/sys/external/bsd
-I/src/NetBSD/cur/src/sys/external/bsd/common/include
-I/src/NetBSD/cur/src/sys/external/bsd/dwc2/dist
-I/src/NetBSD/cur/src/sys/external/bsd/libfdt/dist
-I/src/NetBSD/cur/src/sys/external/bsd/libnv/dist
-I/src/NetBSD/cur/src/sys/external/bsd/vchiq/dist
-I/src/NetBSD/cur/src/sys/external/bsd/common/include
-DVCOS_VERIFY_BKPTS=1 -DUSE_VCHIQ_ARM -D__VCCOREVER__=0x0400
-DVCHIQ_ENABLE_DEBUG=1 -DVCHIQ_LOG_DEFAULT=5 -c
/src/NetBSD/cur/src/sys/external/bsd/vchiq/dist/interface/vchiq_arm/vchiq_arm.c
-o vchiq_arm.o && /usr/curbtools/bin/armv6--netbsdelf-eabihf-gcc
-mfloat-abi=soft -mapcs-frame -ffreestanding
-fno-zero-initialized-in-bss -fno-delete-null-pointer-checks -O2
-fstack-usage -Wstack-usage=3584 -fno-strict-aliasing -fno-common
-std=gnu99 -Werror -Wall -Wno-main -Wno-format-zero-length
-Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes
-Wold-style-definition -Wswitch -Wshadow -Wcast-qual -Wwrite-strings
-Wno-unreachable-code -Wno-pointer-sign -Wno-attributes
-Wno-sign-compare -Walloca -Wno-address-of-packed-member -march=armv6z
-mtune=arm1176jzf-s -mfpu=vfp --sysroot=/src/NetBSD/cur/BUILD.evbarm
-I. -I/src/NetBSD/cur/src/sys/external/bsd/libnv/dist
-I/src/NetBSD/cur/src/sys/external/bsd/acpica/dist
-I/src/NetBSD/cur/src/sys/../common/lib/libx86emu
-I/src/NetBSD/cur/src/sys/../common/lib/libc/misc
-I/src/NetBSD/cur/src/sys/../common/include
-I/src/NetBSD/cur/src/sys/arch -I/src/NetBSD/cur/src/sys -nostdinc
-DCOMPAT_UTILS -DARM_GENERIC_TODR -D__HAVE_CPU_COUNTER
-D__HAVE_CPU_UAREA_ALLOC_IDLELWP -D__HAVE_FAST_SOFTINTS
-D__HAVE_MM_MD_DIRECT_MAPPED_PHYS -DCOMPAT_44 -DDIAGNOSTIC
-D__HAVE_MM_MD_CACHE_ALIASING -DPLCONSOLE -D_KERNEL -D_KERNEL_OPT
-std=gnu99
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/quad
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/string
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/arch/arm/string
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/arch/arm/atomic
-I/src/NetBSD/cur/src/sys/lib/libkern/../../../common/lib/libc/hash/sha3
-I/src/NetBSD/cur/src/sys/external/bsd
-I/src/NetBSD/cur/src/sys/external/bsd/common/include
-I/src/NetBSD/cur/src/sys/external/bsd/dwc2/dist
-I/src/NetBSD/cur/src/sys/external/bsd/libfdt/dist
-I/src/NetBSD/cur/src/sys/external/bsd/libnv/dist
-I/src/NetBSD/cur/src/sys/external/bsd/vchiq/dist
-I/src/NetBSD/cur/src/sys/external/bsd/common/include
-DVCOS_VERIFY_BKPTS=1 -DUSE_VCHIQ_ARM -D__VCCOREVER__=0x0400
-DVCHIQ_ENABLE_DEBUG=1 -DVCHIQ_LOG_DEFAULT=5 -c
/src/NetBSD/cur/src/sys/external/bsd/vchiq/dist/interface/vchiq_arm/vchiq_arm.c
-o vchiq_arm.o && : echo /usr/curbtools/bin/nbctfconvert -g -L VERSION
vchiq_arm.o && /usr/curbtools/bin/nbctfconvert -g -L VERSION vchiq_arm.o
*** [vchiq_arm.o] Error code 1
Anything I missed here?
Re: FYI: new X server in -current, among other X things
I wrote: > It looks like not all the functions are getting setup in the glamor > struct by load_glamor(), I'm guessing because those functions are > not exported by libglamoregl.so. > > Do we need to add more source files to this: > > src/external/mit/xorg/server/xorg-server/hw/xfree86/glamor_egl/Makefile Adding all of the glamor modules to libglamoregl.so makes it stop crashing for me.
Re: "zfs send" freezes system (was: Re: pgdaemon high CPU consumption)
Matthias Petermann writes: [snip] > Roundabout one week after removing the patch, my system with ZFS is > behaving "normally" for the most part and the freezes have disappeared. > What is the recommended way given the 10 branch? If it is not > foreseeable that the basic problem can be solved shortly, would it also > be an option to withdraw the patch in the sources to get at least a > stable behavior? (Not only) on the sidelines, I would still be > interested in whether this "zfs send" problem occurs in general, or > whether certain hardware requirements have a favorable effect on it. > > Kind regards > Matthias My personal experience with this problem is with Xen PV/PVH guests on my build system(s), but I think others have experienced it with physical systems. The only particular facts that I have observed are: a) If there is more memory given to the guest they last longer. That is the one with 8GB does not have as much trouble as the one with 4GB. b) reducing the number of vnodes makes helps keep the system up. I usually run 4096 to 16384 kern.maxvnodes. Without this the OS build system can do about 1.5 "build.sh release" runs before it hangs and with a reduction in vnodes it can get away with 4 to 6 before there are problems. c) Seen only once and on -currentish (most systems are 9.2), but a zfs receive into a compressed fileset hung after a while (in the usual manor that I observe) even with the mentioned patch reverted and a reduced maxvnodes. Receiving into a non-compressed fileset worked as expected. The above a, b and c was 100% reproduceable for me, just takes a while as a build release isn't quite.. the zfs receive thing happened much faster. Both of my build systems uses zfs send through a ssh pipe to a file on another system as a backup method and both have compressed filesets, but they are rarely received into and never sent from those. I have had no trouble zfs sending and receiving locally from a non-compressed fileset into a compressed one, which makes that one case a little strange. On a -currentish test system with zfs filesets for object artifacts and build artifacts if I didn't revert the mentioned patch to arc.c the system could not make it though a build of qemu from pkgsrc and maybe not even though unpacking the source for building (sorry, don't exactly remember how far it would get). -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: "zfs send" freezes system
I'd vote for backing out the patch unless someone(TM) can find the pgdaemon issue. Best regards, Frank On 07/19/22 08:46, Matthias Petermann wrote: Hello, On 13.07.22 12:30, Matthias Petermann wrote: I can now confirm that reverting the patch also solved my problem. Of course I first fell into the trap, because I had not considered that the ZFS code is loaded as a module and had only changed the kernel. As a result, it looked at first as if this would not help. Finally it did...I am now glad that I can use a zfs send again in this way. This previously led reproducibly to a crash, whereby I could not make backups. This is critical for me and I would like to support tests regarding this. In contrast to the PR, there are hardly any xcalls in my use case - however, my system only has 4 CPU cores, 2 of which are physical. Many greetings Matthias Roundabout one week after removing the patch, my system with ZFS is behaving "normally" for the most part and the freezes have disappeared. What is the recommended way given the 10 branch? If it is not foreseeable that the basic problem can be solved shortly, would it also be an option to withdraw the patch in the sources to get at least a stable behavior? (Not only) on the sidelines, I would still be interested in whether this "zfs send" problem occurs in general, or whether certain hardware requirements have a favorable effect on it. Kind regards Matthias
Re: FYI: new X server in -current, among other X things
matthew green wrote:
>
> with a normal build, you should at least be able to get
> a stack trace with function names, if not line numbers.
The last function name that I get is drmmode_init().
Comparing the updated source with the working version shows this:
{
#ifdef GLAMOR_HAS_GBM
ScreenPtr pScreen = xf86ScrnToScreen(pScrn);
+modesettingPtr ms = modesettingPTR(pScrn);
if (drmmode->glamor) {
-if (!glamor_init(pScreen, GLAMOR_USE_EGL_SCREEN)) {
+if (!ms->glamor.init(pScreen, GLAMOR_USE_EGL_SCREEN)) {
return FALSE;
}
#ifdef GBM_BO_WITH_MODIFIERS
-glamor_set_drawable_modifiers_func(pScreen, get_drawable_modifiers);
+ms->glamor.set_drawable_modifiers_func(pScreen,
get_drawable_modifiers);
#endif
}
#endif
It looks like not all the functions are getting setup in the glamor
struct by load_glamor(), I'm guessing because those functions are
not exported by libglamoregl.so.
Do we need to add more source files to this:
src/external/mit/xorg/server/xorg-server/hw/xfree86/glamor_egl/Makefile
"zfs send" freezes system (was: Re: pgdaemon high CPU consumption)
Hello, On 13.07.22 12:30, Matthias Petermann wrote: I can now confirm that reverting the patch also solved my problem. Of course I first fell into the trap, because I had not considered that the ZFS code is loaded as a module and had only changed the kernel. As a result, it looked at first as if this would not help. Finally it did...I am now glad that I can use a zfs send again in this way. This previously led reproducibly to a crash, whereby I could not make backups. This is critical for me and I would like to support tests regarding this. In contrast to the PR, there are hardly any xcalls in my use case - however, my system only has 4 CPU cores, 2 of which are physical. Many greetings Matthias Roundabout one week after removing the patch, my system with ZFS is behaving "normally" for the most part and the freezes have disappeared. What is the recommended way given the 10 branch? If it is not foreseeable that the basic problem can be solved shortly, would it also be an option to withdraw the patch in the sources to get at least a stable behavior? (Not only) on the sidelines, I would still be interested in whether this "zfs send" problem occurs in general, or whether certain hardware requirements have a favorable effect on it. Kind regards Matthias smime.p7s Description: S/MIME Cryptographic Signature
