With OpenBSD 5.0 under KVM on ARPNetworks, all you have to do is “disable mpbios”, and it all seems to work. However, not without subtle problems.

First, I’ve noticed that if you have lots of disk activity, plus lots of output through ssh, then you get periodic networking stalls very easily, with “em0: watchdog timeout — resetting” appearing repeatedly (although, to be fair, the stall only lasts a couple of seconds, and your sessions resume without any noticeable ill effects).

For example, you can find the following in /var/log/messages after checking out all the 3 BSD systems from local CVS trees, locally:

Jan 21 19:51:39 grok /bsd: em0: watchdog timeout -- resetting
Jan 21 19:52:16 grok last message repeated 2 times
Jan 21 19:53:09 grok /bsd: em0: watchdog timeout -- resetting
Jan 21 19:58:32 grok /bsd: em0: watchdog timeout -- resetting

Then, now I’m running Java with {OpenGrok, indexing 3 source trees, and the run queue seems to be merely about 4, as you can see from the load average below. The regular non-mp /bsd. So, guess what, something is broken yet again, and `top` shows all zeros for all the CPU states, and `systat vmstat 1` doesn’t work, either, returning “> The alternate system clock has died!” after a couple of seconds, without updating any info at all whatsoever.

This is what `top -U opengrok -s1` shows, notice the 0.00% for all CPU times, as well as for the process 30390 itself. It shows “98.4% idle” on first iteration, but then goes back to 0.0% as below. (However, wallclock works just fine, without any abnormalities, and the system otherwise appears to run just fine, too.)

load averages:  3.80,  3.78,  3.92
36 processes:  1 running, 33 idle, 1 stopped, 1 on processor
CPU states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle
Memory: Real: 346M/581M act/tot Free: 402M Cache: 187M Swap: 32M/1012M

  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
30390 opengrok  59    0  543M  297M run       -       207:20  0.00% java
24752 opengrok  -6    0  924K 1668K sleep     piperd    0:15  0.00% ectags
32716 opengrok  -6    0  656K 1528K idle      piperd    0:10  0.00% ectags
11857 opengrok  -6    0  840K 1580K sleep     piperd    0:10  0.00% ectags
 2934 opengrok  18    0 1340K 2092K idle      pause     0:01  0.00% tcsh

So, doesn’t really look like this would be providing a reliable and dependable server solution without some extra hacking…