Mark Kettenis(mark.kette...@xs4all.nl) on 2019.01.31 20:20:21 +0100: > > From: <s_g...@telus.net> > > Date: Thu, 31 Jan 2019 11:04:25 -0800 > > > > It seems to be related to network usage, although I cannot confirm that. > > Interesting... > > The crash always seems to involve perl as far as I can tell. I've > seen it crash in the daily job as well. That doesn't rule out there > is some network-related corrpution going on though.
Its not just perl. I could trigger it just by building a kernel. But perl triggers it much faster, to the point of making pkg_add russian roulette. > > As to the unstableness, I loaded Armbian, download, installed and > > ran xfce and Firefox, all without problems. > > > > Something else that I notice is that the boot sometimes fails and I > > have to power off and on again to get it going. > > I think I've seen that as well. Seems U-Boot/ATF doesn't properly > reset the SoC. I believe this is fixed in newer ATF versions. > > > Stops after this: > > > > U-Boot SPL 2019.01 (Jan 27 2019 - 23:00:53 -0700) > > DRAM: 1024 MiB > > Trying to boot from MMC1 > > > > I am going to experiment with different u-boots and dtbs. > > > > Should the dtb be put into the dos partition in the allwinner directory? > > Yes. > > > -----Original Message----- > > From: owner-...@openbsd.org <owner-...@openbsd.org> On Behalf Of Patrick > > Wildt > > Sent: January 31, 2019 7:11 AM > > To: Mark Kettenis <mark.kette...@xs4all.nl> > > Cc: s_g...@telus.net; arm@openbsd.org > > Subject: Re: crashes on orangepi pc2 > > > > 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. > > > > > > >
