On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote: > > From: <s_g...@telus.net> > > Date: Wed, 30 Jan 2019 23:11:00 -0800 > > > > I thought I would give openbsd arm64 a try and purchased an orangepi pc2. > > I followed the INSTALL directions and the install of the system went > > smoothly. > > I used the lan connection at 1000Mbps to load the system install packages. > > > > Simple things like top and df worked fine. Then I tried to add a package > > which resulted in the crash detailed below. > > Since the kernel on the miniroot seemed to download the installation > > packages I rebooted to the > > bsd.sp kernel and tested again with the same results. File systems had to be > > repaired and it looks like the pkg db was corrupted also. > > But the crash was very similar. See bsd.sp below. > > > > Has anyone have any experiences with the orangepi pc2? The documentation > > suggests that it is a targeted machine. > > > > I noticed that the boot complains about the dtb when booting from power up: > > > > Scanning mmc 0:1... > > Found EFI removable media binary efi/boot/bootaa64.efi > > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > > Scanning disks on usb... > > > > Is this because there is no longer a dtb on the dos partition after the > > install recreates the partition? > > > > > > > > bsd.mp crash > > > > oppcsobsd# pkg_add nano > > quirks-3.83 signed on 2019-01-17T20:44:02Z > > quirks-3.83: ok > > nano-3.2:libiconv-1.14p3: ok > > nano-3.2:gettext-0.19.8.1p3: ok > > > > > > > > panic: amap_pp_adjref: negative reference count > > Stopped at panic+0x148: TID PID UID PRFLAGS PFLAGS > > C > > PU COMMAND > > *447051 73332 0 0x1015 0 2K perl > > db_enter() at panic+0x144 > > panic() at uvm_unmap_detach+0x7c > > uvm_unmap_detach() at uvmspace_exec+0x1d0 > > uvmspace_exec() at sys_execve+0x5a8 > > sys_execve() at svc_handler+0x264 > > svc_handler() at do_el0_sync+0x1b0 > > do_el0_sync() at handle_el0_sync+0x74 > > https://www.openbsd.org/ddb.html describes the minimum info required in bug > > reports. Insufficient info makes it difficult to find and fix bugs. > > ddb{2}> > > ddb{2}> > > ddb{2}> > > ddb{2}> trace > > db_enter() at panic+0x144 > > panic() at uvm_unmap_detach+0x7c > > uvm_unmap_detach() at uvmspace_exec+0x1d0 > > uvmspace_exec() at sys_execve+0x5a8 > > sys_execve() at svc_handler+0x264 > > svc_handler() at do_el0_sync+0x1b0 > > do_el0_sync() at handle_el0_sync+0x74 > > handle_el0_sync() at 0x1859d328e0 > > address 0x7ffffdd418 is invalid > > --- trap --- > > I see the exact same error on my Orange Pi PC2. It is still unclear > to me if this issue is specific to that board or a generic issue with > the Allwinner H5 SoC. I've never seen the error on the Allwinner A64 > though. >
My NanoPi Neo2, which is H5 based as well, is also rather unstable.
