Re: Panic on evbearm6
It might be interesting that the same panic happens when building go1.9 as well, although much later in the build sequence: bootstrap/cmd/link/internal/x86 bootstrap/cmd/link # Building go_bootstrap for host, netbsd/arm. runtime/internal/sys runtime/internal/atomic runtime encoding errors internal/cpu internal/race internal/syscall/windows/sysdll math/bits sync/atomic unicode unicode/utf16 unicode/utf8 math sync -- I was watching the screen when the panic took place, there was nothing other than the sudden appearance of the rainbow graphics of the RPI boot. On Mon, 5 Nov 2018 at 16:00, Michael van Elst wrote: > > ci4...@gmail.com (Chavdar Ivanov) writes: > > >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", > > Obviously a bug, but apparently a different one. > > -- > -- > Michael van Elst > Internet: mlel...@serpens.de > "A potential Snark may lurk in every tree." --
Re: Panic on evbearm6
ci4...@gmail.com (Chavdar Ivanov) writes: >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", Obviously a bug, but apparently a different one. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Panic on evbearm6
... 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 wrote: > > The above panic is repeatable. > On Mon, 5 Nov 2018 at 10:14, Chavdar Ivanov 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. > > > > > > > -- > --
Re: Panic on evbearm6
The above panic is repeatable. On Mon, 5 Nov 2018 at 10:14, Chavdar Ivanov 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. > > --
Re: Panic on evbearm6
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.
Re: Panic on evbearm6
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. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Panic on evbearm6
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. On Sun, 4 Nov 2018 at 12:51, Nick Hudson wrote: > > On 04/11/2018 12:09, Chavdar Ivanov wrote: > > I just got: > > -- > > > > Nov 4 11:50:40 rpi /netbsd: [ 91750.0747877] panic: kernel diagnostic > > assertion "(flags & (PR_WAITOK|PR_NOWAIT)) == PR_NOWAIT" failed: file > > "/home/sysbuild/src/sys/kern/subr_pool.c", line 864 > > Nov 4 11:50:40 rpi /netbsd: [ 91750.0747877] cpu0: Begin traceback... > > Nov 4 11:50:40 rpi /netbsd: [ 91750.0950326] 0x8b519d5c: > > netbsd:db_panic+0xc > > Nov 4 11:50:40 rpi /netbsd: [ 91750.0950326] 0x8b519d74: > > netbsd:vpanic+0x138 > > Nov 4 11:50:40 rpi /netbsd: [ 91750.0950326] 0x8b519d8c: > > netbsd:kern_assert+0x40 > > Nov 4 11:50:40 rpi /netbsd: [ 91750.1050626] 0x8b519de4: > > netbsd:pool_get+0x728 > > Nov 4 11:50:40 rpi /netbsd: [ 91750.1050626] 0x8b519e2c: > > netbsd:pool_cache_get_slow+0x1c0 > > Nov 4 11:50:40 rpi /netbsd: [ 91750.1156185] 0x8b519e74: > > netbsd:pool_cache_get_paddr+0x224 > > Nov 4 11:50:40 rpi /netbsd: [ 91750.1156185] 0x8b519f14: netbsd:fork1+0x9c > > Nov 4 11:50:40 rpi /netbsd: [ 91750.1156185] 0x8b519f34: > > netbsd:sys_fork+0x30 > > Nov 4 11:50:40 rpi /netbsd: [ 91750.1156185] 0x8b519fac: > > netbsd:syscall+0x188 > > Nov 4 11:50:40 rpi /netbsd: [ 91750.1356864] cpu0: End traceback... > > Nov 4 11:50:40 rpi /netbsd: > > Nov 4 11:50:40 rpi /netbsd: [ 91750.1356864] dump to dev 92,1 not possible > > Nov 4 11:50:40 rpi /netbsd: [ 91750.1448926] rebooting... > > -- > > > > It is on > > ~ uname -a > > NetBSD rpi 8.99.25 NetBSD 8.99.25 (RPI) #0: Fri Nov 2 20:48:27 GMT > > 2018 > > sysbuild@ymir:/home/sysbuild/evbearmv6hf-el/obj/home/sysbuild/src/sys/arch/evbarm/compile/RPI > > evbarm > > > > and happened while running 'make test' for python3.7.1, so perhaps not > > too big of a problem. > > > > Which RPI? How much memory? > > Nick --
Re: Panic on evbearm6
On 04/11/2018 12:09, Chavdar Ivanov wrote: I just got: -- Nov 4 11:50:40 rpi /netbsd: [ 91750.0747877] panic: kernel diagnostic assertion "(flags & (PR_WAITOK|PR_NOWAIT)) == PR_NOWAIT" failed: file "/home/sysbuild/src/sys/kern/subr_pool.c", line 864 Nov 4 11:50:40 rpi /netbsd: [ 91750.0747877] cpu0: Begin traceback... Nov 4 11:50:40 rpi /netbsd: [ 91750.0950326] 0x8b519d5c: netbsd:db_panic+0xc Nov 4 11:50:40 rpi /netbsd: [ 91750.0950326] 0x8b519d74: netbsd:vpanic+0x138 Nov 4 11:50:40 rpi /netbsd: [ 91750.0950326] 0x8b519d8c: netbsd:kern_assert+0x40 Nov 4 11:50:40 rpi /netbsd: [ 91750.1050626] 0x8b519de4: netbsd:pool_get+0x728 Nov 4 11:50:40 rpi /netbsd: [ 91750.1050626] 0x8b519e2c: netbsd:pool_cache_get_slow+0x1c0 Nov 4 11:50:40 rpi /netbsd: [ 91750.1156185] 0x8b519e74: netbsd:pool_cache_get_paddr+0x224 Nov 4 11:50:40 rpi /netbsd: [ 91750.1156185] 0x8b519f14: netbsd:fork1+0x9c Nov 4 11:50:40 rpi /netbsd: [ 91750.1156185] 0x8b519f34: netbsd:sys_fork+0x30 Nov 4 11:50:40 rpi /netbsd: [ 91750.1156185] 0x8b519fac: netbsd:syscall+0x188 Nov 4 11:50:40 rpi /netbsd: [ 91750.1356864] cpu0: End traceback... Nov 4 11:50:40 rpi /netbsd: Nov 4 11:50:40 rpi /netbsd: [ 91750.1356864] dump to dev 92,1 not possible Nov 4 11:50:40 rpi /netbsd: [ 91750.1448926] rebooting... -- It is on ~ uname -a NetBSD rpi 8.99.25 NetBSD 8.99.25 (RPI) #0: Fri Nov 2 20:48:27 GMT 2018 sysbuild@ymir:/home/sysbuild/evbearmv6hf-el/obj/home/sysbuild/src/sys/arch/evbarm/compile/RPI evbarm and happened while running 'make test' for python3.7.1, so perhaps not too big of a problem. Which RPI? How much memory? Nick
Re: Panic on evbearm6
ci4...@gmail.com (Chavdar Ivanov) writes: >I just got: >-- >Nov 4 11:50:40 rpi /netbsd: [ 91750.0747877] panic: kernel diagnostic >assertion "(flags & (PR_WAITOK|PR_NOWAIT)) == PR_NOWAIT" failed: file >"/home/sysbuild/src/sys/kern/subr_pool.c", line 864 >Nov 4 11:50:40 rpi /netbsd: [ 91750.0747877] cpu0: Begin traceback... >Nov 4 11:50:40 rpi /netbsd: [ 91750.0950326] 0x8b519d5c: netbsd:db_panic+0xc >Nov 4 11:50:40 rpi /netbsd: [ 91750.0950326] 0x8b519d74: netbsd:vpanic+0x138 >Nov 4 11:50:40 rpi /netbsd: [ 91750.0950326] 0x8b519d8c: >netbsd:kern_assert+0x40 >Nov 4 11:50:40 rpi /netbsd: [ 91750.1050626] 0x8b519de4: netbsd:pool_get+0x728 >Nov 4 11:50:40 rpi /netbsd: [ 91750.1050626] 0x8b519e2c: >netbsd:pool_cache_get_slow+0x1c0 >Nov 4 11:50:40 rpi /netbsd: [ 91750.1156185] 0x8b519e74: >netbsd:pool_cache_get_paddr+0x224 >Nov 4 11:50:40 rpi /netbsd: [ 91750.1156185] 0x8b519f14: netbsd:fork1+0x9c That's uvm_uarea_alloc() failing, which must not happen. The bug seems to be in uarea_poolpage_alloc() that may return NULL if PMAP_MAP_POOLPAGE fails, even when called with PR_WAITOK. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
