daily CVS update output
Updating src tree: P src/distrib/i386/installimage/Makefile P src/doc/TODO.smpnet P src/lib/libc/arch/hppa/SYS.h P src/lib/libc/arch/hppa/gen/__setjmp14.S P src/lib/libc/arch/hppa/gen/_setjmp.S P src/lib/libc/arch/hppa/gen/swapcontext.S P src/lib/libc/arch/hppa/string/bcmp.S P src/lib/libc/arch/hppa/string/bzero.S P src/lib/libc/arch/hppa/string/ffs.S P src/lib/libc/arch/hppa/string/strlcpy.S P src/lib/libc/arch/hppa/sys/__clone.S P src/lib/libc/arch/hppa/sys/__sigtramp2.S P src/lib/libc/arch/hppa/sys/__vfork14.S P src/lib/libc/arch/hppa/sys/brk.S P src/lib/libc/arch/hppa/sys/cerror.S P src/lib/libc/arch/hppa/sys/fork.S P src/lib/libc/arch/hppa/sys/getcontext.S P src/lib/libc/arch/hppa/sys/pipe.S P src/lib/libc/arch/hppa/sys/sbrk.S P src/lib/libc/compat/arch/hppa/sys/compat_Ovfork.S P src/lib/libc/compat/arch/hppa/sys/compat_sigpending.S P src/lib/libc/compat/arch/hppa/sys/compat_sigprocmask.S P src/lib/libc/compat/arch/hppa/sys/compat_sigreturn.S P src/lib/libc/compat/arch/hppa/sys/compat_sigsuspend.S P src/share/mk/bsd.own.mk P src/sys/arch/amd64/amd64/locore.S P src/sys/arch/amd64/stand/prekern/elf.c P src/sys/arch/amd64/stand/prekern/prekern.h P src/sys/arch/amiga/amiga/machdep.c P src/sys/arch/i386/i386/locore.S P src/sys/arch/x86/x86/pmap.c P src/sys/arch/xen/conf/files.xen P src/sys/arch/xen/conf/files.xen.pv P src/sys/arch/xen/x86/xen_intr.c P src/sys/arch/xen/xen/hypervisor.c P src/sys/arch/xen/xen/if_xennet_xenbus.c P src/sys/arch/xen/xen/privcmd.c P src/sys/arch/xen/xen/xbdback_xenbus.c P src/sys/arch/xen/xen/xenevt.c P src/sys/arch/xen/xen/xennetback_xenbus.c P src/sys/dev/pci/pci_map.c P src/sys/external/bsd/compiler_rt/dist/lib/builtins/clear_cache.c P src/sys/kern/kern_entropy.c P src/sys/kern/sys_futex.c P src/sys/kern/sys_lwp.c P src/sys/kern/uipc_mbuf.c P src/sys/net/if.c P src/sys/net/if.h P src/sys/sys/futex.h P src/sys/sys/param.h P src/tests/lib/libc/sys/t_ptrace_sigchld.c P src/tests/libexec/ld.elf_so/h_ifunc.c P src/tests/libexec/ld.elf_so/helper_ifunc_dso/h_helper_ifunc.c P src/usr.bin/make/str.c P src/usr.bin/make/unit-tests/sysv.exp P src/usr.bin/make/unit-tests/sysv.mk Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.3 U external/bsd/bind/dist/lib/isc/sha2.c Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): P crypto/external/bsd/netpgp/lib/verify/Makefile U crypto/external/bsd/netpgp/lib/verify/verify.map U doc/CHANGES-9.1 P sys/dev/scsipi/scsiconf.c P sys/dev/sun/disksubr.c P sys/external/bsd/compiler_rt/dist/lib/builtins/clear_cache.c P sys/kern/uipc_sem.c Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 37683531 May 6 03:10 ls-lRA.gz
Re: Panic: vrelel: bad ref count (9.99.54)
On Mon, May 04, 2020 at 03:54:57PM +0200, Leonardo Taccari wrote: > Hello Yorick and Andrew, > > Yorick Hardy writes: > > > > > [...] > > > > > > > > > > Crash version 9.99.55, image version 9.99.55. > > > > > crash: _kvm_kvatop(0) > > > > > Kernel compiled without options LOCKDEBUG. > > > > > System panicked: vrelel: bad ref count > > > > > Backtrace from time of crash is available. > > > > > crash> bt > > > > > _KERNEL_OPT_NAGR() at 0 > > > > > ?() at 7f7ff7ecf000 > > > > > sys_reboot() at sys_reboot > > > > > vpanic() at vpanic+0x181 > > > > > vtryrele() at vtryrele > > > > > vcache_dealloc() at vcache_dealloc > > > > > uvm_unmap_detach() at uvm_unmap_detach+0x76 > > > > > uvm_unmap1() at uvm_unmap1+0x4e > > > > > uvm_mremap() at uvm_mremap+0x36b > > > > > sys_mremap() at sys_mremap+0x68 > > > > > syscall() at syscall+0x227 > > > > > --- syscall (number 411) --- > > > > > 797459842e9a: > > > > > crash> > > > > > > > > The same just happened on 9.99.56 while fetching (POP) mail using > > > > mail/fdm. > > > > > > Could you file a PR please? If this panics again could you please run the > > > "dmesg" command in crash and find out what it printed about the vnode? > > > That > > > would be very useful. > > > > > > Thanks, > > > Andrew > > > > I will do so (... perhaps only this weekend). > > [...] > > I was able to reproduce it too with a yesterday evening NetBSD/amd64 > -current when using mail/fdm and I will try to prepare a minimal > reproducer using mail/fdm and file a PR if noone beat me. > > In the meantime here the information from dmesg: > > [ 6107.6380323] vnode 0xa95219747d40 flags 0x418 > [ 6107.6380323]tag VT_TMPFS(25) type VREG(1) mount 0xa951f6d89000 > typedata 0xa95255e32c90 > [ 6107.6380323]usecount 1 writecount 1 holdcount 0 > [ 6107.6380323]size 18000 writesize 18000 numoutput 0 > [ 6107.6380323]data 0xa952583304a0 lock 0xa95219747f00 > [ 6107.6380323]state LOADED key(0xa951f6d89000 8) a0 04 33 58 52 a9 > ff ff > [ 6107.6380323]lrulisthd 0x816b5ed0 > [ 6107.6380323]tag VT_TMPFS, tmpfs_node 0xa952583304a0, flags 0x0, > links 1 > [ 6107.6380323]mode 0600, owner 1000, group 0, size 98304 > [ 6107.6380323] panic: vrelel: bad ref count > [ 6107.6380323] cpu0: Begin traceback... > [ 6107.6380323] vpanic() at netbsd:vpanic+0x178 > [ 6107.6480364] vnpanic() at netbsd:vnpanic+0x49 > [ 6107.6480364] vrelel() at netbsd:vrelel+0x5b6 > [ 6107.6480364] uvm_unmap_detach() at netbsd:uvm_unmap_detach+0x8e > [ 6107.6480364] sys_munmap() at netbsd:sys_munmap+0x85 > [ 6107.6480364] syscall() at netbsd:syscall+0x2a0 > [ 6107.6480364] --- syscall (number 73) --- > [ 6107.6480364] 7c1e5d18414a: > [ 6107.6480364] cpu0: End traceback... > [ 6107.6480364] fatal breakpoint trap in supervisor mode > [ 6107.6480364] trap type 1 code 0 rip 0x802219fd cs 0x8 rflags 0x202 > cr2 0x7f7ff7ee5000 ilevel 0 rsp 0xc100c227ae20 > [ 6107.6480364] curlwp 0xa9521e1b1600 pid 20756.20756 lowest kstack > 0xc100c22772c0 > [ 6107.6480364] dumping to dev 0,1 (offset=276847, size=2062664): > [ 6107.6480364] dump > > If any possible further information is needed do not hesitate to > contact me! > > > Thanks! Thank you. I opened PR 55237 to track so I don't forget. Andrew
Re: KASLR kernel fails to boot
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
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. > > Chavdar > > -- > --
Re: i386 Xen integration breaks linking NET4501 kernel
On Mon, May 04, 2020 at 06:42:11PM -0500, John D. Baker wrote:
> A recent build of -current/i386 fails when trying to link a kernel built
> from the NET4501 config:
>
> [...]
> # link NET4501/netbsd
> /r0/build/current/tools/amd64/bin/i486--netbsdelf-ld -Map netbsd.map --cref
> -T netbsd.ldscript -Ttext c010 -e start -X -o netbsd
> ${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ} vers.o swapnetbsd.o
> /r0/build/current/tools/amd64/bin/i486--netbsdelf-ld: locore.o: in function
> `start_xenpvh':
> (.text+0x410): undefined reference to `hvm_start_paddr'
> /r0/build/current/tools/amd64/bin/i486--netbsdelf-ld: (.text+0x436):
> undefined reference to `HYPERVISOR_shared_info_pa'
Should be fixed now. Sorry for this
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
