Re: DECstation 5000/200 timekeeping

>> This really looks to me as though the clock interrupt is low enough
>> priority to get locked out by SCSI, serial, and/or Ethernet
>> interrupts; it reminds me of running NetBSD/mac68k, years ago.
> Hmm, that's an r4400 or somesuch, isn't it?

Doh!  I should have quoted.

DECstation 5000/200 (3MAX)
total memory = 32768 KB
avail memory = 28272 KB
timecounter: Timecounters tick every 3.906 msec
mainbus0 (root)
cpu0 at mainbus0: MIPS R3000 CPU (0x220) Rev. 2.0 with MIPS R3010 FPC Rev. 2.0
cpu0: 64KB/4B direct-mapped Instruction cache, 64 TLB entries
cpu0: 64KB/4B direct-mapped write-through Data cache
tc0 at mainbus0: 25 MHz clock
ibus0 at tc0 slot 7 offset 0x0
mcclock0 at ibus0 addr 0x1fe80000: mc146818 or compatible
dz0 at ibus0 addr 0x1fe00000: DC-7085, 4 lines
lkkbd0 at dz0 line 0
wskbd0 at lkkbd0 mux 1
vsms0 at dz0 line 1
wsmouse0 at vsms0 mux 0
le0 at tc0 slot 6 offset 0x0: address 08:00:2b:1b:b7:5f
le0: 32 receive buffers, 8 transmit buffers
asc0 at tc0 slot 5 offset 0x0: NCR53C94, 25MHz, SCSI ID 7
scsibus0 at asc0: 8 targets, 8 luns per target
timecounter: Timecounter "clockinterrupt" frequency 256 Hz quality 0
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 1 lun 0: <SEAGATE, ST373307LC, 0003> disk fixed
sd0: 69809 MB, 49855 cyl, 4 head, 716 sec, 512 bytes/sect x 142969680 sectors
sd0: sync (200.00ns offset 15), 8-bit (5.000MB/s) transfers, tagged queueing
boot device: sd0
root on sd0a dumps on sd0b
root file system type: ffs

R3000, is that also MIPS3?  I'm having trouble figuring out how that
works.  sys/arch/pmax/conf/std.pmax says "machine pmax mips".
sys/arch/mips/conf/files.mips has a bunch of files which are
conditional on things like mips1, mips3, mips32, mips64, but I have so
far failed to figure out where any of those are defined.  Looking at
the kernel build's list of .o files, I can deduce some things about
what's defined, but not where those definitions come from.

I clearly need to study config(1) more.

The above matches with kern.clockrate and kern.timecounter:

kern.clockrate: tick = 3906, tickadj = 15, hz = 256, profhz = 256, stathz = 256

kern.timecounter.choice = clockinterrupt(q=0, f=256 Hz) dummy(q=-1000000, f=1000000 Hz)
kern.timecounter.hardware = clockinterrupt
kern.timecounter.timestepwarnings = 0

> Looking at the code, one difference between powerpc's clock.c and
> mips' mips3_clockintr.c is that the powerpc code calls hardclock()
> for every missed tick, while the mips code calls it once per
> interrupt.

That's fine if the clock interrupt is high enogh priority and the rest
of the kernel doesn't block it too much.  I guess that must not be
true.

But I'm not sure how relevant it is, because there is no
mips3_clockintr.o in the kernel build directory; the only references to
mips3_clockintr in files* files I see are arch-specific ones for algor,
cobalt, evbmips, and sgimips - no pmax.

Looking at the .o files, the only references to hardclock are
kern_clock.o (the definition) and dec_3max.o.  Looking at dec_3max.c,
it's called from dec_3max_intr(), which itself is presumably called via
platform.iointr because the only reference to it is

	platform.iointr = dec_3max_intr;

In any case, sounds as though this isn't a known hardware misfeature
like the mac68k priority weirdness (where serial line interrupts were
hardwired to higher priority than clock interrupts, IIRC), so I'll just
treat it as a debugging problem.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B