I've had "Pentium" type machine for decades, starting with using NetBSD 0.9 on a 386 or 486 in 1997?, and now, trying out various processors and systems for beta testing 10.0.

Initially, one "hand-me-down" box seemed like an older, 32-bit processor, based on how MS-Windows viewed the details, complaining the OS version could not be updated beyond Windows 9 32 bit, or so. Thus my first pass with NetBSD was to install the i386 release, testing it for several weeks before the light dawned that this weak looking machine had more to offer if set up right. Motherboard has a 2014 date stamp and my research shows this board was designed for laptops then slipped into a largish case because marketing/.

Processor/kernel

[ 1.000000] NetBSD 10.0_BETA (GENERIC) #0: Mon Jan 23 16:02:49 UTC 2023

[ 1.000000] mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC

[ 1.000000] NetBSD 10.0_BETA (GENERIC) #0: Sun Feb 12 12:39:37 UTC 2023

[ 1.000000] mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC

/netbsd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for NetBSD 10.0, not stripped

[ 1.000004] cpu0: AMD A8-6410 APU with AMD Radeon R5 Graphics

[ 1.000004] cpu0: node 0, package 0, core 0, smt 0

[ 1.000004] cpu0: SVM disabled by the BIOS

[ 1.000004] cpu1 at mainbus0 apid 1

[ 1.000004] cpu1: AMD A8-6410 APU with AMD Radeon R5 Graphics

[ 1.000004] cpu1: node 0, package 0, core 1, smt 0

[ 1.000004] cpu2 at mainbus0 apid 2

[ 1.000004] cpu2: AMD A8-6410 APU with AMD Radeon R5 Graphics

[ 1.000004] cpu2: node 0, package 0, core 2, smt 0

[ 1.000004] cpu3 at mainbus0 apid 3

[ 1.000004] cpu3: AMD A8-6410 APU with AMD Radeon R5 Graphics

[ 1.000004] cpu3: node 0, package 0, core 3, smt 0

4-cores, N threads(?)

Two for the price of one

First win: the AMD64 beta ISO fits on a standard CD image footprint. Yay.

Next, big win: the machine has both VGA and DVI outputs, which may sound archaic with HDMI and higher resolutions available (more on the higher end AMD system later), but it turns out this little board contains 2 independent video outputs. With a couple adapters, I've got dual-HDMI screens and X Windows stretching in them.

Minor fault: the onboard ethernet adapter only runs at 100BT. On closer examination, there is an onboard mini-PCIE connector that could conceivably allow a Gigabit board in its place. Given the risk of breaking the installed board (which NetBSD works fine with), or installing a replacement board that might not work, I decided to go with an outboard USB ethernet dongle (more on that hardware also later).

Memory

Without changing the system (I guess there be BIOS mysteries here), going x86 kicked up the visible memory seen by NetBSD.

[ 1.000000] total memory = 2759 MB

[ 1.000000] avail memory = 2684 MB

[ 1.000000] total memory = 7863 MB

[ 1.000000] avail memory = 7581 MB

Also good news, there is an empty memory slot onboard. Now, to find chips that fit...

I wonder how old that CR2032 button battery is? Hmm.

Video

[ 4.877451] [drm] Radeon Display Connectors

[ 4.877451] [drm] Connector 0:

[ 4.877451] [drm] DVI-D-1

[ 4.888080] [drm] Connector 1:

[ 4.888080] [drm] VGA-1

[ 4.947445] radeondrmkmsfb0 at radeon0

[ 4.957450] [drm] Initialized radeon 2.50.0 20080528 for radeon0 on minor 0

[ 4.957450] radeondrmkmsfb0: framebuffer at 0xc0615000, size 1920x1080, depth 32, stride 7680

X Windows starts up just fine; the switch from twm to cwtm is still pleasant (one app installed twm and I quickly rewrote that xtartup script).

XSCreensaver works nicely; the range of hacks and their speed are always a system performance indicator, as well as hardware and software library depth. Two separate hacks running at the same time is pretty cool, maybe the first UNIX system I've had (and there have been many) bifurcating for me.

Oops:

$ file xscreensaver-get.core

xscreensaver-get.core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), NetBSD-style, from 'xscreensaver-get', pid=18023, uid=1000, gid=100, nlwps=1, lwp=18023 (signal 11/code 32767)

Network

The "net" in NetBSD implies internet operations should be simple and thorough. I've installed this OS enough times to know where interface are configured, how Network Time Protocol works best, and basic home mesh set up. Good news for this motherboard containing a supported ethernet board.

I was unsatisfied with the restricted 100BT connection and tried several alternatives for wired and wireless.

For wifi, I have one USB dongle that NetBSD is happy with, and others that either don't work at all, or have partial connectivity. I switched out one that as been running fine on an even older i386 server and it's been fine (the big test will be running wireless only, rather than dual connections).

Think Penguin sells open source hardware. Linux OS targeted, but sometimes NetBSD uses benefit from that communal spirit. Not always, though. Short version (more below): the wireless dongle didn't work for me on NetBSD, but the gigabit USB dongle did.

Built-in:

[ 1.055110] re0 at pci1 dev 0 function 0: RealTek 8100E/8101E/8102E/8102EL PCIe 10/100BaseTX (rev. 0x07)

[ 1.055110] re0: interrupting at msix1 vec 0

[ 1.055110] re0: RTL8106E (0x4480)

There appear to be antenna wires connected to the PCIE board, though NetBSD doesn't report any interface other than the wired one.

Built-out:

[ 2.727276] rgephy0 at axen0 phy 3: RTL8211E 1000BASE-T media interface

[ 2.777269] rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto

Mar 8 21:32:16 amd64 /netbsd: [ 771903.1443413] athn0 at uhub1 port 2

Mar 8 21:32:17 amd64 /netbsd: [ 771904.1242585] : Atheros AR9271

Mar 8 21:32:17 amd64 /netbsd: [ 771904.1242585] athn0: rev 1 (1T1R), ROM rev 15, address

Mar 8 21:47:22 amd64 dhcpcd[4518]: re0: carrier lost - roaming

Mar 8 21:47:22 amd64 dhcpcd[4518]: axen0: changing route to ...

interface rates:

ping times:

Arrows are before the ThinkPenguin AXEN0 interface was connected

Performance

For beta testing, I like to install familiar software, run benchmarks, and look for anomalies. The first oddity was the CPU temperature increase after switching from an i386 NetBSD beta build to the amd64.

On the left side, i386 running under 27 degrees Celsius average, with the amd64 on the right closer to 38 degrees. Inexplicable so far.

Byte Bench

Dhrystone 2 using register variables 6703557.1 lps (10.0 secs, 10 samples)

Double-Precision Whetstone 1321.6 MWIPS (10.0 secs, 10 samples)

Recursion Test--Tower of Hanoi 116108.7 lps (20.0 secs, 3 samples)

Dhrystone 2 using register variables 116700.0 6703557.1 574.4

Double-Precision Whetstone 55.0 1321.6 240.3

H Bench (or its close rival lmbench)

lmbench1.1 results for NetBSD ...

...

Process fork+exit: 1002.1667 microseconds

Process fork+execve: 2887.0000 microseconds

Process fork+/bin/sh -c: 6732.0000 microseconds

$ cat /usr/pkg/share/hbench/Results/netbsd10.0-x86_64/amd64/lat_syscall_getpid

0.2494

0.2534

0.2522

0.2526

0.2546

0.2584

0.2549

0.2530

0.2502

0.2486

NetBSD Unit Tests

There are test suites under /usr/tests on recent NetBSD systems, which I was unaware of until recently, so running these tests are as much for me to learn about the system architecture as it is to find errors o omissions. In a prior post, I reported more failures on architectures for as ARM than on i386 or amd64, which makes a little sense given their relative code base ages.

Fortunately, I managed a complete test run while this system was running the NetBSD i386 build, and have finished another round using the amd64 build. Interesting results in that a few failures are mutual while most of the very small set are from only one build.

Line counts for the test runs:

12101 testsuite-amd64.csv

11957 testsuite-i386.csv

Common (shared) failure(s), as extracted from the CSV output (timestamps omitted for clarity):

tc, sbin/envstat/t_envstat, zerotemp, failed, Test case was expecting a failure but none were raised
tp, sbin/envstat/t_envstat, failed

Failures seen only on i386:

tp include/t_paths failed
tp kernel/kqueue/t_empty failed
tp lib/libarchive/t_libarchive failed
tp lib/libc/kevent_nullmnt/t_nullmnt failed
tp lib/librumphijack/t_tcpip failed
tp net/net/t_bind failed
tp net/net/t_unix failed
tp net/altq/t_cbq failed
tp crypto/opencrypto/t_opencrypto failed

Failures seen only on amd64:

tp lib/libc/net/t_servent failed
tp net/if_wg/t_basic failed
tp usr.bin/cc/t_tsan_data_race failed
tp usr.bin/make/t_make failed
tp usr.sbin/tcpdump/t_tcpdump failed
tp fs/tmpfs/t_vnode_leak failed

Apologies if this semi-manual error search missed any useful test results.

[ 1.055087] amdtemp0 at amdnb_misc0: AMD CPU Temperature Sensors (Family16h)

[ 1.055123] amdtemp0 at amdnb_misc0: AMD CPU Temperature Sensors (Family16h)

i386:

<so>amdtemp0 = 39.250 =~ 39</so>

<so>Skipping non-existent coretemp0</so>

<so>Skipping non-existent acpitz0</so>

<failed>Test case was expecting a failure but none were raised</failed>

amd64:

<so>amdtemp0 = 45.125 =~ 45</so>

<so>Skipping non-existent coretemp0</so>

<so>Skipping non-existent acpitz0</so>

<failed>Test case was expecting a failure but none were raised</failed>

I presume the root cause for this hardware might be similar to the other 686?

[ 1.000004] cpu0: AMD A8-6410 APU with AMD Radeon R5 Graphics

$ /sbin/dmesg | /usr/bin/grep -i temp

[ 1.055087] amdtemp0 at amdnb_misc0: AMD CPU Temperature Sensors (Family16h)

[ 1.055123] amdtemp0 at amdnb_misc0: AMD CPU Temperature Sensors (Family16h)

$ /usr/sbin/envstat

Current CritMax WarnMax WarnMin CritMin Unit

[amdtemp0]

cpu0 temperature: 39.375 degC

On an AtomPC i386, envstat was fine:

tc, sbin/envstat/t_envstat, zerotemp, passed

<so>Skipping non-existent amdtemp0</so>

<so>coretemp0 = 58.000 =~ 58</so>

<so>acpitz0 = 127.000 =~ 127</so>

$ /sbin/dmesg | /usr/bin/grep -i temp

[ 1.010406] coretemp0 at cpu0: thermal sensor, 1 C resolution, Tjmax=100

$ /usr/sbin/envstat

Current CritMax WarnMax WarnMin CritMin Unit

[acpitz0]

temperature: 52.000 127.000 degC

[acpitz1]

temperature: 51.000 127.000 degC

[coretemp0]

cpu0 temperature: 53.000 degC

Think Penguin

Their wifi dongle has only worked on a small number of OSes I've tried, though I had hoped it would 'just work.' Part number: TPE-N150USB.

The gigabit dongles have been fine so far, and no losses on a temperamental Pi 02W. Though it has gone offline once (no dump). TPE-1000NET3

Mar 19 00:00:00 aa syslogd[974]: restart

Mar 19 12:31:31 aa syslogd[806]: restart

Mar 19 12:31:31 aa /netbsd: [ 1.0000000] NetBSD 10.0_BETA (GENERIC) #0: Fri Jan 13 19:15:32 UTC 2023

Mar 19 12:31:31 aa /netbsd: [ 1.0000000] mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/GENERIC

Mar 19 12:31:31 aa /netbsd: [ 1.0000000] total memory = 448 MB

Mar 19 12:31:31 aa /netbsd: [ 1.0000000] avail memory = 422 MB

The Other 686

Alas, my idea to install NetBSD on a homebrew AMD board hasn't worked yet due to video card matching and budget. FreeBSD skirted the "bad" board by least common denominator rules which kicked in vanilla VGA X/console window to at least boot. I had 9.x running and decided for the time being not to keep swapping out hardware to have yet another NetBSD 10 beta testbed.

There are a few programs that I haven't got working to my satisfaction on the 6-core/12-thread machine, thus I'm using the NetBSD "laptop in a biggish box" as the main X display and putting databases or apps not needing video interaction on FreeBSD.

One program that really snaps with faster hardware is ocrmypdf; transactions that were taking a minute on an ARM processor kick over in 10 seconds now.

[ 1.000003] cpu0: AMD Ryzen 5 5600X 6-Core Processor

[ 1.005359] amdzentemp0 at amdsmn0: AMD CPU Temperature Sensors (Family19h)

[ 1.005359] amdzentemp0: autoconfiguration error: unable to register with sysmon (error=22)

Crumbs from the spork

Monday, March 20, 2023

32/64-Bit and NetBSD 10 BETA