DIEHARD (RNG Tester)

There is a GPLed reimplementation called DieHarder that might be of interest.

The author of DiehardC has removed the code. Consequently, this port is not terribly useful.

Here's an OpenBSD port of George Marsaglia DIEHARD suite (mirror). The port is actually derived from a C version of the code called DiehardC. Anyhow, it compiles and apart from a single “0.0” vs “−0.0” mismatch, the resulting binary generates the expected output for the included test set (the output of mktest1). At least for now, it just compiles the binaries. “install” and “regress” targets could perhaps be useful. Here's a tarball: diehard-port.tgz (ports/math seemed like a good place for it).

Elan SC520 Timer (Soekris boxes)

Anyone wanting to use this in 3.3 should contact me first. Some Elan support was checked in to -current that conflicts with this diff. I have some stuff in my tree, but I haven't had time time clean it up.

I need to get a higher-resolution timer for my Soekris box, so I added some code that uses the GP2 and GP1 timers together as a 32-bit free-running counter. It's not all that interesting by itself, but it provides a simple framework for adding support for other things (e.g., the watchdog and toggling LEDs). Note also that the PIT timer runs at a non-standard frequency on many of these boxes. This can cause some problems (the normal microtime() will be a bit off as it has the standard PIT frequency hard-coded). See microtime.s in NetBSD for what looks like a simple solution (perhaps I will try that one day). Tarball with diff is here: elan2.tar.gz

Some things need to be added to the kernel config file, like so:
elan0 at pchb?
elan_timer0 at elan0

The config file I happen to use is here: GW and the resulting dmesg is here: GW.dmesg. It does include an option that enables a hack for my particular net4501 that has an incorrect crystal (“option SOEKRIS_X1_FREQUENCY=xxx”) as well as enabling the “timebase” stuff (see below). The ramdisk options need to come out unless you intend to use it as a ramdisk kernel...

If someone knows how the attach really should be done, please let me know. I just mucked with the config stuff (trying to pilfer from the isa code) until it worked.

Should anyone have an SC520 box and be interested in learning something about OpenBSD kernel device drivers, adding support for the watchdog or Soekris LED would probably be a good place to start (especially since chunks can—assuming a reasonable license—be stolen from existing NetBSD patches like the MMCR code by jasper -at- pointless.net.). I can probably be persuaded to provide some hand-holding.

PM/ACPI 3.579545MHz Timer Support for 760MP/MPX and 440BX/PIIX

It looks like most x86 boxes in the last few years have a free-running counter for use by ACPI. It has the advantage of being at a known, fixed frequency and (supposedly) not changing frequency like the TSC can. It is also reasonably quick to read (a single “inl()”). I wanted to test some stuff related to the SC520 timer code without rebooting my firewall box all the time, so I added support for this timer on some other boxes that do not bring my Internet connection down while debugging. I have only tested this on an Asus P2B and on a Tyan Tiger (the 760MP one), but it's really simple. Not much use by itself, but here's the code: pm2.tar.gz.

The following needs to be added to the kernel config:
amdpm*  at pci? dev ? function ?
piixpm* at pci? dev ? function ?

The “right” way to do this would be to add it through proper ACPI support, but until that is done, it's simple enough to add support for individual chipsets with a normal driver.

The amdpm driver has a kernel option that allows one to set the frequency to something other than 3.579545MHz (“option AMDPM_FREQUENCY=3579545”).

Sept. 25
Added a kernel option to set the average frequency for amdpm (in case ntpd is not an option for some reason). Crystals are sensitive to temperature, voltage, and they do age, but for a particular box, one can still try to pick something in the middle of that crystal/environment's range.

Timebase

In order to get something with which to test the SC520 counter code, I figured that what could be better than sticking it in one of the most critical parts of the system. Not having FreeBSD's rather complicated “timecounter” code, I cooked up something simple to take it's place (poor imitation, though it may be). Tarball is here: tb2.tar.gz.

The kernel config needs to see the following options:

option  HZ=100
option  COUNTER_TIMEBASE

The HZ is necessary to switch microtime to use the registered timer instead of the PIT.

The counters are all expanded to 64-bits, which is overkill for the system clock, but I need 'em for something else. The code could certainly use some optimization. (Can anyone say, “multiple 64-bit arithmetic ops in hardclock,” ten times quickly?)

Before I forget, microtime() seems to have some problems giving reasonable answers early in the system startup (independent of my patches). This may cause problems for things like amdpm's RNG rate calibration (untested, as I don't have an OpenBSD box with the MPX chipset).

This code is also suggesting that kernels on the SC520 and on a PIII 600 may skip multiple clock interrupts every once in a while. This could, of course, just be brain-damage on the part of my timebase code. Then again that nasty abomination also known as the 8259 PIC is easy to confuse and/or some thing is simply blocking hardclock() for a long time. Using the work-around in FreeBSD's PIIX timer code (their mp clock code), the PIII complains much less frequently (three events in 24 hours). Using the TSC instead of the ACPI timer has eliminated the warning messages (after several days of testing now). The SC520 is still complaining regularly (anyone have any SC520 GP timer errata to share?).

Sept. 25
Changed the 64-bit division to a 64-bit multiply. I'm still running some tests with NTP to see if this stuff actually works. See the Sept. 25 comment for the routing grief section for a hint as to what cut the previous test short.
Oct. 18
hardclock() on the PIII box I was testing with also sometimes seems to miss (sometimes for over four seconds). When I get a chance to get back to it, the diagnostic/timing code I was working on should unveil the culprit.

Intel Pro/1000 Driver

A later version is now in -current (as of Sept. 25th).
Thanks nate@ (and jason@) for the effort.

A port of Intel's FreeBSD “em” driver for their Pro 1000 GigE NICs is here: em-openbsd2.tar.gz. I've been using it with both the desktop and dual-port server variants of the Pro/1000MT without incident since Aug 19th on two x86 boxes. It needs to be cleaned up a bit and converted to use the dmamap API. (Yes, it is still on my todo list.)

See Intel's README file for details on allegedly supported boards.

netstat

This patch is now in -current (as of Sept. 23).

The netstat command is broken when used to display routes with the “-A” option. Here's a patch that should help: netstat2.diff.gz. The Lite2 merge seems to have missed this change. I also added code to display all the radix tree flags (including the ones for masks—this is more important for OpenBSD than the other *BSDs since OpenBSD has the sometimes-corrupts-the-radix-tree RNF_IGNORE flag).

The output of “netstat -nrAf inet” now looks like this (instead of the garbage from trying to print radix_node structs as sockaddrs):
Routing tables

Internet:
Address    Destination        Gateway            Flags     Refs     Use    Mtu  Interface
0xd0cf7cc4         (32)       0xd0d4a718 :       0xd0d53218 <RA> mk =       0xd0c9d400 {(0), <A>, (0) }
0xd0d4a718         (33)       0xd0cf7cac :       0xd0d4a918 <A>
0xd0cf7cac       (root node) =>
0xd0d53000       default            192.168.201.1      UGS         0   170348      -   em0
      mask (0)  <A> mk =       0xd0c9d400 {(0), <A>, (0) }
0xd0d4a918         (63)       0xd0d4a900 :       0xd0d4a700 <A> mk =       0xd0c9d050 {(40), <NA>, leaf = 0xd0d4a900 (255) ffff ff }
0xd0d4a900       127/8              127.0.0.1          UGRS        0        0  33224   lo0
      mask (255) ffff ff  <NA> mk =       0xd0c9d050 {(40), <NA>, leaf = 0xd0d4a900 (255) ffff ff }
0xd0d4a700       127.0.0.1          127.0.0.1          UH          4      492  33224   lo0
0xd0d53218         (34)       0xd0d53118 :       0xd0d53618 <A>
0xd0d53118         (61)       0xd0d71018 :       0xd0d53100 <A> mk =       0xd0c9d000 {(56), <NA>, leaf = 0xd0d53200 (255) ffff ffff ff }
0xd0d71018         (62)       0xd0d52018 :       0xd1082818 <A>
0xd0d52018         (63)       0xd0d53200 :       0xd0d52000 <A>
0xd0d53200       192.168.201/24     link#1             UC          0        0      -   em0
      mask (255) ffff ffff ff  <NA> mk =       0xd0c9d000 {(56), <NA>, leaf = 0xd0d53200 (255) ffff ffff ff }
0xd0d52000       192.168.201.1      link#1             UHL         1        0      -   em0
0xd1082818         (63)       0xd1082800 :       0xd0d71000 <A>
0xd1082800       192.168.201.2      0:7:e9:1:df:71     UHL         1    68701      -   em0
0xd0d71000       192.168.201.3      0:7:e9:0:ad:30     UHL         4    67563      -   em0
0xd0d53100       192.168.201.4      127.0.0.1          UGHS        0        0  33224   lo0
0xd0d53618         (35)       0xd0d53600 :       0xd0cf7cdc <A>
0xd0d53600       224/4              127.0.0.1          URS         0        0  33224   lo0
      mask (255) ffff f0  <NA>
0xd0cf7cdc       (root node)

Sept. 23
Regenerated diff because of an unrelated route.c checkin to -current.