NetBSD

[gillham]

I spoke too soon.  I'm seeing the checksum errors as well.  Hopefully someone answers on the mailing list.

Any kind of heavy use at I get these errors and it typical will lock up. Occasionally a kernel panic. (which sounds like Der Geist got also)
I'll see if ddb is useful on the main display or if I need to enable my serial console.

Nevertheless I am back to using my USB Ethernet or tp-link wifi adapter.

I setup a beefy VM to cross-compile pkgsrc (MATE in particular) but it blew up quickly. I do have a Raspberry Pi I should be able to setup with NetBSD and leave it building 24x7.

I'm hoping Jared will build more packages (the current ones on his site are just enough to run mate-terminal on X, but not all of mate) especially with that fancy 16 core SolidRun box.

[Der Geist der Maschine]

Any kind of heavy use at I get these errors and it typical will lock up.  Occasionally a kernel panic.  (which sounds like Der Geist got also)
I'll see if ddb is useful on the main display or if I need to enable my serial console.

The crashing kernel was kind enough to save a stack trace in dmesg. On the following boot, it was available in the then old dmesg.

I don't recall the precise stack trace but it originated in something like idle_thread or so. The kernel crashed not under load but while doing nothing

[ab1jx]

Any kind of heavy use at I get these errors and it typical will lock up.  Occasionally a kernel panic.  (which sounds like Der Geist got also)
I'll see if ddb is useful on the main display or if I need to enable my serial console.

Sounds a little like CPU scheduling, it should be in "performance" mode. My Odroid N2 did something like that compiling something big and that was the fix. It has to do with how the work is divided among the CPU cores.

[mrgtwentythree]

After an uptime of roughly 30 min, the kernel crashed with a stack trace while I was in step 6.

Jared' NetBSD 9 image does no provide wifi support and so I'm running NetBSD-current. Apparently, it's extremely unstable.

do you happen to have the stack trace?  mine has been working pretty well though i've had one hang while running X and i had no serial console handy to check why so there's still something(s) problematic.

netbsd 9.0 is coming out soon enough that we probably won't get wifi working there, but should for netbsd 9.1.

[Der Geist der Maschine]

After an uptime of roughly 30 min, the kernel crashed with a stack trace while I was in step 6.

Jared' NetBSD 9 image does no provide wifi support and so I'm running NetBSD-current. Apparently, it's extremely unstable.

do you happen to have the stack trace?

J

Code:

Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] curcpu=0, spl=4 curspl=7
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] onproc=0xffff0000f7d46080 => l_stat=7 l_flag=20000201 l_cpu=0
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] curlwp=0xffff0000f7d21580 => l_stat=1 l_flag=00000200 l_cpu=0
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] pinned=0xffff0000f7d21100 => l_stat=7 l_flag=00000200 l_cpu=0
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] panic: softint screwup
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] cpu0: Begin traceback...
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] trace fp ffffffc060e5fbe0
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e5fc00 vpanic() at ffffffc0004a9f30 netbsd:vpanic+0x160
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e5fc70 panic() at ffffffc0004aa024 netbsd:panic+0x44
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e5fd40 softint_dispatch() at ffffffc000478924 netbsd:softint_dispatch+0x5c4
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e57c30 cpu_switchto_softint() at ffffffc000084548 netbsd:cpu_switchto_softint+0x68
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e57c80 splx() at ffffffc0000040fc netbsd:splx+0xbc
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e57cb0 callout_softclock() at ffffffc000486984 netbsd:callout_softclock+0x36c
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e57d40 softint_dispatch() at ffffffc00047845c netbsd:softint_dispatch+0xfc
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e37cc0 cpu_switchto_softint() at ffffffc000084548 netbsd:cpu_switchto_softint+0x68
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e37df8 cpu_idle() at ffffffc0000854d8 netbsd:cpu_idle+0x58
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e37e40 idle_loop() at ffffffc0004512d4 netbsd:idle_loop+0x174
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] cpu0: End traceback...

[mrgtwentythree]

Code:

Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] curcpu=0, spl=4 curspl=7
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] onproc=0xffff0000f7d46080 => l_stat=7 l_flag=20000201 l_cpu=0
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] curlwp=0xffff0000f7d21580 => l_stat=1 l_flag=00000200 l_cpu=0
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] pinned=0xffff0000f7d21100 => l_stat=7 l_flag=00000200 l_cpu=0
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] panic: softint screwup
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] cpu0: Begin traceback...
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] trace fp ffffffc060e5fbe0
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e5fc00 vpanic() at ffffffc0004a9f30 netbsd:vpanic+0x160
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e5fc70 panic() at ffffffc0004aa024 netbsd:panic+0x44
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e5fd40 softint_dispatch() at ffffffc000478924 netbsd:softint_dispatch+0x5c4
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e57c30 cpu_switchto_softint() at ffffffc000084548 netbsd:cpu_switchto_softint+0x68
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e57c80 splx() at ffffffc0000040fc netbsd:splx+0xbc
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e57cb0 callout_softclock() at ffffffc000486984 netbsd:callout_softclock+0x36c
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e57d40 softint_dispatch() at ffffffc00047845c netbsd:softint_dispatch+0xfc
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e37cc0 cpu_switchto_softint() at ffffffc000084548 netbsd:cpu_switchto_softint+0x68
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e37df8 cpu_idle() at ffffffc0000854d8 netbsd:cpu_idle+0x58
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] fp ffffffc060e37e40 idle_loop() at ffffffc0004512d4 netbsd:idle_loop+0x174
Jan 31 01:02:04 arm64 /netbsd: [ 1701.3548937] cpu0: End traceback...

OK, i think this specific problem has been fixed.  -current was unstable a bit recently, but that seems to have largely been resolved (there are 1 or 2 new issues i recall without fixes, but most are fine now.)
can you try a newer -current image from armbsd?  thanks!

[mrgtwentythree]

i have commited an updated u-boot-pinebook-pro package to pkgsrc.  it resolves reboot problems i've had on both ANSI and ISO models.

make sure you have u-boot-pinebook-pro-2020.01.rc5nb4 version.

i have noticed that bwfm(4) is not stable yet, and spews checksum errors and then the system hangs.  i've started looking into why this may be.

[wdt]

Am I right that the image from http://www.armbsd.org/arm/
has no support for internal wifi?
Did I see somewhere that rt5390 (usb dongle) will work?

[mrgtwentythree]

the internal wifi is not yet available for the netbsd 9 based images on armbsd.com, that hopefully will come soon (i've submitted pullups for it). however, it's not 100% stable yet - it worked for me for a while, while jmcneill@netbsd said he had regularly hangs. now i'm in a different location (and different AP), mine seems to hang sometimes, usually with the rx path getting "checksum error". i think that this point it's out of sync with the data coming from the host, and gets confused and locks the system up. i'm investigating the driver to see if i can figure out why.

rt5390 appears to be supported by run(4). i've never used that one so i can't confirm it works, i'm mostly using urtwn(4) based fobs.

[wdt]

it finds run0 OK,, but,
I thought I knew how to set up wpa_supplicant,, guess not
Maybe, running foreground, with -dd something about
pkt-filter, 6 lines in
sysinst didn't do any better