Re: Failures in x86 pmap
On Mon, Feb 24, 2020 at 09:14:09PM +, Andrew Doran wrote: > On Mon, Feb 24, 2020 at 01:22:15PM +, Patrick Welche wrote: > > > On Sun, Feb 23, 2020 at 06:59:50PM +, Andrew Doran wrote: > > > I think I found the problem, which has existed since ~8PM GMT yesterday. > > > Hopefully fixed by revision 1.17 of src/sys/arch/x86/x86/x86_tlb.c. > > > > With src from Mon Feb 24 13:18:07 GMT 2020 (so with v 1.17 of > > x86_tlb.c), I now see: > > > > (gdb) x/s panicstr > > 0x819535c0 : "kernel diagnostic assertion > > \"uvm_page_owner_locked_p(pg, true)\" failed: file > > \"/usr/src/sys/arch/x86/x86/pmap.c\", line 4041 " > > > > whenever logging into xdm with an nfs mounted /home. > > > > Booting with a kernel from last Monday gets me back to a working amd64 > > system. > > (Not sure if related, but see the magic characters "pmap.c") > > I missed a few changes. Just made a bunch of commits and nfs survives a > short fsx run for me so I'd say it should be fixed now. Yes thanks! (Just tried a new kernel and all OK) Cheers, Patrick
panic: _pmap_enter: cannot allocate L3 table (aarch64)
Hi, This has started happening quite often for me, but I don't see any recent MD change that could be related. Maybe recent UVM changes? panic: _pmap_enter: cannot allocate L3 table cpu12: Begin traceback... vpanic() at ffc0004ebe94 netbsd:vpanic+0x210 panic() at ffc0004ebc80 netbsd:panic+0x44 _pmap_enter() at ffc8bc74 netbsd:_pmap_enter+0xe44 pmap_kenter_pa() at ffc8ae14 netbsd:pmap_kenter_pa+0x4c uvm_pagermapin() at ffc000469bdc netbsd:uvm_pagermapin+0x1d8 uvm_swap_io() at ffc000472200 netbsd:uvm_swap_io+0x98 swapcluster_flush() at ffc00046b5dc netbsd:swapcluster_flush+0x74 uvm_pageout() at ffc00046acb0 netbsd:uvm_pageout+0x638 -Tobias
Re: ZFS on root - almost there
On 22/02/2020 19:22, Roy Marples wrote: https://wiki.netbsd.org/wiki/RootOnZFS/ Updated the wiki and the ramdisk - either the bootloader needs to load the modules via boot.cfg or the modules need to be built into the kernel. There's just no easy way to load the modules from the ramdisk without putting them inside the ramdisk and I think too many people would forget to re-build the ramdisk or put it against the wrong kernel. Also, I've updated the minimum required kernel to 9.99.48 as Taylor R Campbell has kindly fixed the problem of writing to the FFS boot device from the ZFS chroot :) Roy
Re: ZFS on root - almost there
On Tue, 25 Feb 2020 at 20:14, Roy Marples wrote: > > On 22/02/2020 19:22, Roy Marples wrote: > > https://wiki.netbsd.org/wiki/RootOnZFS/ > > Updated the wiki and the ramdisk - either the bootloader needs to load the > modules via boot.cfg or the modules need to be built into the kernel. I don't get it - with my present, still 9.99.47 setup, I am able to load modules: ... ➜ xci modstat tun NAME CLASSSOURCE FLAG REFSSIZE REQUIRES ➜ xci modload tun ➜ xci modstat tun NAME CLASSSOURCE FLAG REFSSIZE REQUIRES tundriver filesys -0 11 if_tun ➜ xci uname -a NetBSD nzfs 9.99.47 NetBSD 9.99.47 (GENERIC) #10: Sat Feb 22 14:18:50 GMT 2020 sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC amd64 ➜ xci df -k / Filesystem1K-blocks Used Avail %Cap Mounted on rpool/ROOT 238594722232129 21627343 9% / > > There's just no easy way to load the modules from the ramdisk without putting > them inside the ramdisk and I think too many people would forget to > re-build the ramdisk or put it against the wrong kernel. So is the option of loading them as per the above no longer available? > > Also, I've updated the minimum required kernel to 9.99.48 as Taylor R Campbell > has kindly fixed the problem of writing to the FFS boot device from the ZFS > chroot :) I'll try it later. > > Roy Thanks. --
Re: ZFS on root - almost there
On 25/02/2020 21:40, Chavdar Ivanov wrote: On Tue, 25 Feb 2020 at 20:14, Roy Marples wrote: On 22/02/2020 19:22, Roy Marples wrote: https://wiki.netbsd.org/wiki/RootOnZFS/ Updated the wiki and the ramdisk - either the bootloader needs to load the modules via boot.cfg or the modules need to be built into the kernel. I don't get it - with my present, still 9.99.47 setup, I am able to load modules: Because we can label a GPT parition "boot". However, that won't work for MBR based systems. It's also not very friendly if you have any other OS present who might for similar reasons have a parition named boot either. There's just no easy way to load the modules from the ramdisk without putting them inside the ramdisk and I think too many people would forget to re-build the ramdisk or put it against the wrong kernel. So is the option of loading them as per the above no longer available? No it's not. It is however available from the source history if you really want it. As a last metric, since reverting back to letting the bootloader load the modules, zpool is no longer panicing randomly. Or the randomness just hasn't struck yet! Roy
Re: ZFS on root - almost there
On Tue, 25 Feb 2020 at 21:51, Roy Marples wrote: > > On 25/02/2020 21:40, Chavdar Ivanov wrote: > > On Tue, 25 Feb 2020 at 20:14, Roy Marples wrote: > >> > >> On 22/02/2020 19:22, Roy Marples wrote: > >>> https://wiki.netbsd.org/wiki/RootOnZFS/ > >> > >> Updated the wiki and the ramdisk - either the bootloader needs to load the > >> modules via boot.cfg or the modules need to be built into the kernel. > > > > I don't get it - with my present, still 9.99.47 setup, I am able to > > load modules: > > Because we can label a GPT parition "boot". > However, that won't work for MBR based systems. > It's also not very friendly if you have any other OS present who might for > similar reasons have a parition named boot either. > > >> There's just no easy way to load the modules from the ramdisk without > >> putting > >> them inside the ramdisk and I think too many people would forget to > >> re-build the ramdisk or put it against the wrong kernel. > > > > So is the option of loading them as per the above no longer available? > > No it's not. > It is however available from the source history if you really want it. Trouble is, I do - for the moment - the tests on a VirtualBox VM and I'd like to have the vboxguest module loaded - otherwise X doesn't work very well in the case of a vm with efi enabled. The module is built elsewhere and I wonder how I could I add it... > > As a last metric, since reverting back to letting the bootloader load the > modules, zpool is no longer panicing randomly. Or the randomness just hasn't > struck yet! > > Roy --
daily CVS update output
Updating src tree: P src/bin/echo/echo.1 P src/distrib/common/zfsroot.rc P src/external/bsd/libarchive/dist/libarchive/archive_read.c P src/share/man/man4/uftdi.4 P src/sys/dev/pci/if_ixl.c P src/sys/dev/pckbport/synaptics.c P src/sys/kern/subr_autoconf.c P src/sys/rump/net/lib/libshmif/if_shmem.c P src/usr.sbin/postinstall/postinstall.in Updating xsrc tree: Killing core files: Updating release-7 src tree (netbsd-7): Updating release-7 xsrc tree (netbsd-7): Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.2 P sys/arch/arm/arm32/bus_dma.c P sys/arch/mips/adm5120/dev/ahci.c P sys/dev/usb/ehci.c P sys/dev/usb/ohci.c P sys/dev/usb/uhci.c P sys/external/bsd/dwc2/dwc2.c P sys/kern/uipc_socket.c Updating release-8 xsrc tree (netbsd-8): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 34829152 Feb 26 03:10 ls-lRA.gz
