NetBSD
#31
(01-31-2020, 09:59 PM)johnwayner Wrote: 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. Smile
  Reply
#32
(02-01-2020, 04:41 PM)gillham Wrote: 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 Confused
  Reply
#33
(02-01-2020, 04:41 PM)gillham Wrote: 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.
  Reply
#34
(02-01-2020, 01:03 AM)Der Geist der Maschine Wrote: 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.
  Reply
#35
(02-07-2020, 04:09 PM)mrgtwentythree Wrote:
(02-01-2020, 01:03 AM)Der Geist der Maschine Wrote: 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...
  Reply
#36
(02-08-2020, 02:21 PM)Der Geist der Maschine Wrote:
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!
  Reply
#37
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.
  Reply
#38
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?
  Reply
#39
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.
  Reply
#40
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
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
Music NetBSD and USB "sound cards" KC9UDX 0 24 4 hours ago
Last Post: KC9UDX
Thumbs Up My NetBSD on Pinebook Pro journey KC9UDX 10 2,079 09-24-2020, 02:12 AM
Last Post: KC9UDX
  NetBSD and pinebook keyboard/trackpad firmware updater mrgtwentythree 1 896 01-07-2020, 09:20 AM
Last Post: Jeremiah Cornelius

Forum Jump:


Users browsing this thread: 1 Guest(s)