daily CVS update output
Updating src tree: P src/build.sh P src/distrib/sets/lists/dtb/ad.earmv7 P src/distrib/sets/lists/dtb/ad.earmv7hf P src/distrib/sets/lists/dtb/ad.earmv7hfeb P src/doc/TODO.smpnet P src/etc/etc.evbarm/Makefile.inc P src/external/cddl/osnet/dist/uts/common/dtrace/dtrace.c P src/libexec/ld.elf_so/arch/powerpc/ppc_reloc.c P src/sys/arch/aarch64/aarch64/cpufunc.c P src/sys/arch/aarch64/aarch64/cpuswitch.S P src/sys/arch/aarch64/aarch64/exec_machdep.c P src/sys/arch/aarch64/aarch64/genassym.cf P src/sys/arch/aarch64/aarch64/netbsd32_machdep.c P src/sys/arch/aarch64/aarch64/vectors.S P src/sys/arch/aarch64/aarch64/vm_machdep.c P src/sys/arch/aarch64/include/armreg.h P src/sys/arch/aarch64/include/machdep.h P src/sys/arch/aarch64/include/proc.h P src/sys/arch/amd64/stand/prekern/console.c P src/sys/arch/amd64/stand/prekern/pdir.h P src/sys/arch/amd64/stand/prekern/prekern.c P src/sys/arch/amd64/stand/prekern/prekern.h P src/sys/arch/amd64/stand/prekern/redef.h P src/sys/arch/amd64/stand/prekern/trap.S P src/sys/arch/arm/imx/files.imx51 cvs update: `src/sys/arch/arm/imx/files.imx6' is no longer in the repository P src/sys/arch/arm/imx/fdt/files.imx6 cvs update: `src/sys/arch/evbarm/conf/ARMADAXP_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/ARMADILLO-IOT-G3_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/BCM5301X_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/BCM56340_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/CUBOX-I' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/CUBOX-I_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/CUBOX_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/HUMMINGBOARD' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/IMX23_OLINUXINO_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/IMX6UL-STARTER' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/IMX6UL-STARTER_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/KOBO_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/MIRABOX_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/NETWALKER_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/NITROGEN6X' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/NITROGEN6X_INSTALL' is no longer in the repository P src/sys/arch/evbarm/conf/OMAP5EVM cvs update: `src/sys/arch/evbarm/conf/OMAP5EVM_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/PANDABOARD_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/PARALLELLA_INSTALL' is no longer in the repository P src/sys/arch/evbarm/conf/README.evbarm cvs update: `src/sys/arch/evbarm/conf/TOASTER' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/VIRT' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/ZEDBOARD_INSTALL' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/files.nitrogen6' is no longer in the repository P src/sys/arch/evbarm/conf/files.tsarm cvs update: `src/sys/arch/evbarm/conf/mk.imx6ul' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/mk.nitrogen6' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/std.imx6ul' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/std.nitrogen6' is no longer in the repository cvs update: `src/sys/arch/evbarm/conf/std.virt' is no longer in the repository cvs update: `src/sys/arch/evbarm/nitrogen6/nitrogen6_iomux.c' is no longer in the repository cvs update: `src/sys/arch/evbarm/nitrogen6/nitrogen6_machdep.c' is no longer in the repository cvs update: `src/sys/arch/evbarm/nitrogen6/nitrogen6_usb.c' is no longer in the repository cvs update: `src/sys/arch/evbarm/nitrogen6/platform.h' is no longer in the repository cvs update: `src/sys/arch/evbarm/tsarm/toastersensors.c' is no longer in the repository P src/sys/arch/mips/include/cpuregs.h P src/sys/arch/mips/mips/mips_machdep.c P src/sys/arch/vax/vax/pmap.c P src/sys/arch/x68k/dev/event.c P src/sys/arch/xen/x86/pintr.c P src/sys/compat/common/kern_sig_16.c P src/sys/compat/common/tty_43.c P src/sys/compat/linux/arch/arm/linux_ptrace.c P src/sys/compat/linux/arch/i386/linux_ptrace.c P src/sys/compat/linux/arch/powerpc/linux_ptrace.c P src/sys/compat/linux/common/linux_file.c P src/sys/compat/linux/common/linux_sched.c P src/sys/compat/linux/common/linux_signal.c P src/sys/compat/netbsd32/netbsd32_fs.c P src/sys/ddb/db_xxx.c P src/sys/dev/lockstat.c P src/sys/dev/midi.c P src/sys/dev/sequencer.c P src/sys/dev/audio/audio.c P src/sys/dev/isa/files.isa cvs update: `src/sys/dev/isa/toaster.c' is no longer in the repository cvs update: `src/sys/dev/isa/toasterlcd.c' is no longer in the repository P s
Re: build failure when optimizing
On Sat, 23 May 2020 22:25:55 +0200 os...@fessel.org wrote: > 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. You can build with MKCOMPAT=no to avoid this problem if you don't need 32-bit compatibility libs. -Tobias
Re: build failure when optimizing
Hej, > Am 23.05.2020 um 23:21 schrieb Paul Goyette : > > 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 Cool, thanks. seems like that was the default in netbsd 8.1 and earlier, looking at my old logs. Probably a „not-reading-all-release-notes“ error. Cheers Oskar smime.p7s Description: S/MIME cryptographic signature
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 | ++--+---+
build failure when optimizing
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 smime.p7s Description: S/MIME cryptographic signature
Re: github.com/NetBSD/src 5 days old?
On 23.05.2020 02:08, matthew sporleder wrote: > On Fri, May 22, 2020 at 5:57 PM Greg A. Woods wrote: >> >> At Thu, 21 May 2020 15:11:41 -0400, Andrew Cagney >> wrote: >> Subject: Re: github.com/NetBSD/src 5 days old? >>> >>> The details are all found here: >>> https://mail-index.netbsd.org/tech-repository/2020/02/17/msg000685.html >> >> That just says what might happen (and what could/should happen at the >> same time), not why (nor how the decision was arrived at). >> I've never found anything there explaining the actual rationale for Hg. >> >> -- > > Joerg is the one doing all of the work and he wants to land on hg. > > Every other "justification" or benchmark or whatever is pretty much a > lie. Especially now, five years later, when git has gotten better and > better at big repos. > NetBSD also got better with large git repos (thanks to the work of Andrew Doran). One year ago it took ages to commit something locally or to get "git status". Today it's usable. > Matt > > p.s. this whole thing reached a head (Core statement on version > control systems) in Jan 2015 > https://mail-index.netbsd.org/tech-repository/2015/01/04/msg000497.html > signature.asc Description: OpenPGP digital signature
Re: KASLR kernel fails to boot
No problem, thanks! Works now. On Sat, 23 May 2020 at 09:32, Maxime Villard wrote: > > Sorry about this, there was a file I forgot in my commit command line for a > change two weeks ago: > > https://mail-index.netbsd.org/source-changes/2020/05/23/msg117587.html > > The lack of call to elf_build_info() caused a sanity check in the prekern to > fail. > > Thanks for reporting > > > Le 22/05/2020 à 12:42, Chavdar Ivanov a écrit : > > After the latest updates to /usr/mdec/prekern, now I am getting > > > > FATAL > > elf sym lookup: symbol beyond table > > > > > > when I try to load the KASLR kernel. > > > > Chavdar > > > > On Tue, 5 May 2020 at 21:26, Chavdar Ivanov wrote: > >> > >> Ok, thanks. > >> > >> On Tue, 5 May 2020 at 20:21, Maxime Villard wrote: > >>> > >>> Le 05/05/2020 à 21:01, Chavdar Ivanov a écrit : > On Mon, 4 May 2020 at 21:21, Chavdar Ivanov wrote: > > > > Hi, > > > > netbsd-GENERIC_KASLR from yesterday fails to pass the prekern stage > > with a frightening message in red 'Page fault'. I've never seen this > > before, no idea if I can get any further info. > > > > This machine has been otherwise running KASLR kernel for some four > > months now without a problem; it is a VirtualBox guest. > > Same with just completed clean buid of 9.99.60. > > After "[+] Rel relocations applied" I get: > > ** Fault occurred ** > page fault > ** > > I switched th vm to the normal kernel, no problem otherwise. > >>> > >>> I know, this is because of the Xen section in the binary, which is not > >>> marked as allocatable. The prekern explicitly decides not to map the note > >>> but then proceeds to relocate its RELAs regardless, which causes a fatal > >>> page fault. > >>> > >>> Trivial to fix but I'm not sure which policy to choose, may take a few > >>> days. > >> > >> > >> > >> -- > >> > > > > > > --
Re: KASLR kernel fails to boot
Sorry about this, there was a file I forgot in my commit command line for a change two weeks ago: https://mail-index.netbsd.org/source-changes/2020/05/23/msg117587.html The lack of call to elf_build_info() caused a sanity check in the prekern to fail. Thanks for reporting Le 22/05/2020 à 12:42, Chavdar Ivanov a écrit : After the latest updates to /usr/mdec/prekern, now I am getting FATAL elf sym lookup: symbol beyond table when I try to load the KASLR kernel. Chavdar On Tue, 5 May 2020 at 21:26, Chavdar Ivanov wrote: Ok, thanks. On Tue, 5 May 2020 at 20:21, Maxime Villard wrote: Le 05/05/2020 à 21:01, Chavdar Ivanov a écrit : On Mon, 4 May 2020 at 21:21, Chavdar Ivanov wrote: Hi, netbsd-GENERIC_KASLR from yesterday fails to pass the prekern stage with a frightening message in red 'Page fault'. I've never seen this before, no idea if I can get any further info. This machine has been otherwise running KASLR kernel for some four months now without a problem; it is a VirtualBox guest. Same with just completed clean buid of 9.99.60. After "[+] Rel relocations applied" I get: ** Fault occurred ** page fault ** I switched th vm to the normal kernel, no problem otherwise. I know, this is because of the Xen section in the binary, which is not marked as allocatable. The prekern explicitly decides not to map the note but then proceeds to relocate its RELAs regardless, which causes a fatal page fault. Trivial to fix but I'm not sure which policy to choose, may take a few days. --
