... and happens also with go 1.10 in the following stage: --- ===> Building for go110-1.10.4nb2 cd /usr/pkgsrc/lang/go110/work/go/src && env GOROOT_BOOTSTRAP=/usr/pkg/go14 GOROOT_FINAL=/usr/pkg/go110 GOARM=6 /usr/pkg/bin/bash ./make.bash Building Go cmd/dist using /usr/pkg/go14. Building Go toolchain1 using /usr/pkg/go14. Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1. -----
I will try to rebuild go14 just in case. On Mon, 5 Nov 2018 at 10:54, Chavdar Ivanov <ci4...@gmail.com> wrote: > > The above panic is repeatable. > On Mon, 5 Nov 2018 at 10:14, Chavdar Ivanov <ci4...@gmail.com> wrote: > > > > > > > > On 11/04/18 17:03, Michael van Elst wrote: > > > ci4...@gmail.com (Chavdar Ivanov) writes: > > > > > >> This was on the original RPI Zero, 512MB RAM (dmesg shows for some > > >> reason total 448MB, avail 434MB). As I said, it was running > > >> python3.7.1 tests at the time, so it may have been overloaded. It has > > >> only the default 256MB ld0b partition for swap. > > > It's overloaded, but it shouldn't panic then. The reason is a bug > > > in the pool page implementation. > > > > > And there is another one on the same system from tonight: > > --- > > > > panic: kernel diagnostic assertion "(armreg_fpexc_read() & VFP_FPEXC_EN) > > == 0" failed: file "/home/sysbuild/src/sys/arch/arm/vfp/vfp_init.c", > > line 526 > > cpu0: Begin traceback... > > 0x8580de1c: netbsd:db_panic+0xc > > 0x8580de34: netbsd:vpanic+0x138 > > 0x8580de4c: netbsd:kern_assert+0x40 > > 0x8580de8c: netbsd:vfp_state_load+0x140 > > 0x8580deec: netbsd:pcu_load+0x1e8 > > 0x8580df3c: netbsd:vfp_handler+0x50 > > 0x8580dfac: netbsd:undefinedinstruction+0x1a0 > > ---- > > > > It was apparently while building lang/go111; go14 was already built (as > > it starts from there). > > > > No core dump again. > > > > > > > -- > ---- -- ----
