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).
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.