In the late 1970s and the 1980s, the best choice for high-performance, high-capacity storage was so-called SMD disks.
The SMD interface was only normalized as ANSI X3.91M-1982 in, well, 1982, after five years of work, and was later revised in 1987; this revision can be found on Bitsavers.
Although other storage technologies appeared during the 1980s, such as ESDI (standardized in 1984) or SCSI (standardized in 1986), the highest capacity disks were all using the SMD interface.
SMD disks were first using 11" platters, later 8"; and with a nominal speed of 3600 rpm, thus 60 rotations per second (although Fujitsu later deviated from the norm and had a few drives spinning even faster, at 3961rpm), it took a noticeable amount of power to spin these disks up (and a smaller one to keep them spinning, which one would notice when receiving the bill from the electricity company).
These disks would also, of course, weigh as much as a dead donkey, if not two. While 8" models could be carried carefully by one person, moving 11" disks around usually required the use of some form of carriage.
SCSI standard documents (click for a larger picture).
It was thus no surprise that Sun Microsystems would ship its high-end servers and workstations with SMD disks, using Xylogics controllers.
Xylogics 451 Multibus controller board, in the middle, plugged into a
Multibus-to-VME converter at the bottom (click for a larger picture).
Similarly to ESDI but unlike SCSI and more modern storage interfaces, the SMD
interface has separate command and data cables.
Depending on the controller, the
command cable is either routed through all disks, daisy-chained, or
there is one dedicated command cable per disk, directly connected to the
controller.
The data cables are independent and always directly connect the
controller to a disk.
Note the 451 can drive four disks, but the Sun flavour only routes the
command cable (in the center) and two of the four data cables,
thus only allowing two disks to be used.
Sun's connector choice also splits the command into two smaller cables.
By the time these systems made their way to hobbyist's basements, high-capacity SCSI drives had appeared; I remember using a 2GB Micropolis 1924 5"1/4 SCSI disk on my Sun-3/260, in the early 2000s; to the best of my knowledge, the largest SMD disk drive capacity ever was about 1.25GB, less than two thirds of that SCSI disk capacity.
When I started working on OpenBSD/sun3, in the year 2000, I did not have any SMD drives anyway, and could not test the Xylogics drivers.
This changed in the summer of 2001. I had stumbled upon a decommissioned Sun-4/260 cabinet in a corner of a room somewhere the previous summer, next to a SMD disk cabinet of matching form factor. After recognizing the machine for what it was, I inquired of its state, and it took me one full year to convince the right persons to let me park my car close to that room and move both enclosures to its trunk.
What's in a Sun-4/260, you may ask. The 4/200 series were the first SPARC systems sold by Sun; depending on the actual size of the VME enclosure, they were either the 4/260, in a large 12-slot deskside cabinet on wheels, or the rackable 4/280 which would fill half a 19" rack, allowing for 16 VME slots in this configuration.
The motherboard was however the same, a large (9U) square board with a 16.67MHz SPARC processor and its Floating-Point Unit. It sported two serial ports, a combined keyboard and mouse port for a Sun Type 3 keyboard, a monochrome high-resolution (1600x1200) frame buffer, and an Ethernet interface.
Sun-4/200 board (click for a larger picture).
Note the
ZIF
sockets for the CPU chips on the left.
But no on-board memory. Memory was installed as VME boards which also communicated with the CPU board on Sun's private "P2" bus to speed up memory access and not have to share bus bandwidth with the rest of the VME bus. Up to four memory boards could be installed, and since they came in 8, 16 or 32MB flavours, this allowed for up to 128MB of physical memory.
Storage controllers would also be added as VME boards. Most systems had at least a SCSI controller, in slot 7, to handle the internal drive bay - either the very limited homemade "Sun-2" sc controller, unable to correctly handle parity signals and requiring it to be disabled on all connected devices, or a slightly better, NCR5380-based "Sun-3" si controller, with no such limitation.
Usually, another controller was added in slot 8: either another SCSI controller with an external connector, to be able to, well, connect external SCSI devices, or an SMD controller (sometimes even two).
Higher-end Xylogics 7053 VME (9U) controller board (click for a larger picture).
This controller can drive four disks, but uses different connectors on the
backplate, than the Xylogics 451, hence require different cables (which
I unfortunately don't have).
Model 7053 also exists as a smaller (6U) VME board, for use with other VME
systems, such as older
Silicon Graphics
systems or
Motorola's.
In this smaller size, it is known as model 753, and uses shielded
high-density connectors (for which I don't have the appropriate cables either)
instead of
Sub-D.
All the subtle differences between the various VME slots in the chassis led to Sun writing a specific manual on the preferred location to put every board and how to configure the VME backplane jumpers for proper interrupt delivery, called cardcage slot assigment and backplane configuration procedures (link to Bitsavers). This, in its heyday, grew over 100 pages of tables and footnotes.
The abovementioned manual (click for a larger picture).
When I setup that machine at home, the selftests reported one of the memory boards as defective. This might have been one of the reasons this machine had been removed from service (that, and maybe also the electricity bill and limited horsepower). But, as it had been fitted with four 16MB memory boards, I could remove it and still work with 48MB.
Of the two SMD disks in the storage cabinet, both with a raw (non-formatted) capacity of about 368MB but a formatted capacity of only 280MB, only one appeared to be working.
After getting rid of the faulty memory board, and moving another two of them to my Sun-3/260 which was more important to me at that time, I could finally setup the machine.
Date: Sun, 15 Jul 2001 05:05:25 +0000
From: Miod Vallat
To: dmesg@openbsd.org
Subject: sun 4/260
Wow, I added SMD and scsi disks to the diskless 4/260. Still slow as
hell, but I don't care, I have a reputation to preserve.
Kernel is SUN4 from 07/13/2001 with my dmesg fix that mickey commited
later.
Miod
OpenBSD 2.9-current (SUN4) #2: Sun Jul 15 04:32:56 GMT 2001
root@tekumel:/src/current/src/sys/arch/sparc/compile/SUN4
real mem = 16752640
avail mem = 13221888
using 102 buffers containing 835584 bytes of memory
bootpath: /vmes0/xyc0/xy@0,0
mainbus0 (root): SUN-4/200 series
cpu0 at mainbus0: MB86900/1A or L64801 @ 16.670 MHz, MB86910 or WTL1164/5 FPU
cpu0: 128K byte write-back, 16 bytes/line, sw flush cache enabled
obio0 at mainbus0
oclock0 at obio0 addr 0xf3000000 delay constant 6
eeprom0 at obio0 addr 0xf2000000
memreg0 at obio0 addr 0xf4000000
zs0 at obio0 addr 0xf1000000 pri 12, softpri 6
zs0a: console i/o
zs1 at obio0 addr 0xf0000000 pri 12, softpri 6
bwtwo0 at obio0 addr 0xfd000000: bwtwo, 1152 x 900
bwtwo0: attached to /dev/fb
ie0 at obio0 addr 0xf6000000 pri 6 address 08:00:20:00:c8:78, type onboard
vmel0 at mainbus0
vmes0 at mainbus0
xyc0 at vmes0 addr 0xffffee40 vec 0x48 pri 3: Xylogics 450/451
xy0 at xyc0 drive 0: ready (drive type 1)
xy0: <CDC EMD 9720 cyl 1147 alt 2 hd 10 sec 48>, pcyl 1149
xy0: 268MB, 1147 cyl, 10 head, 48 sec, 512 bytes/sec
xy1 at xyc0 drive 1: off-line
si0 at vmes0 addr 0xff200000 vec 0x40 pri 3
si0: options=1<DMA>
scsibus0 at si0: 8 targets
sd0 at scsibus0 targ 0 lun 0: <EMULEX, MD21/S2 ESDI, A00> SCSI0 0/direct fixed
sd0: 312MB, 1224 cyl, 15 head, 34 sec, 512 bytes/sec, 640500 sec total
sd1 at scsibus0 targ 0 lun 1: <EMULEX, MD21/S2 ESDI, A00> SCSI0 0/direct fixed
sd1: drive offline
st0 at scsibus0 targ 4 lun 0: <, , > SCSI1 1/sequential removable
st0: rogue, drive empty
led0 at mainbus0
root on xy0a
rootdev=0x300 rrootdev=0x900 rawdev=0x902
ie0: TDR detected an open 9472 clocks away
Given the limited horsepower of that machine, and the noise of the huge chassis fans when powered on, I did not use it very often. Only when I needed to test something on that particular motherboard would I power it up again, upgrade to the latest OpenBSD version, and test a new kernel which had been compiled on another machine. Tests which needed a ``sun4'' class machine would usually be performed on my Sun-4/330 running at 25MHz, which would also draw less power, and for which I had bought a memory expansion board to reach a comfortable 80MB (32MB onboard in 8x4MB SIMMs, and a VME expansion board with 48x1MB SIMMs).
The abovementioned memory board with its 48 SIMMs (click for a larger picture).
Unfortunately, it doesn't accept 4MB SIMMs.
Since the Sun-4/200 and Sun-4/100 motherboards are special, compared to the other SPARC systems, in that they use an Intersil EEPROM chip as non-volatile memory (as found on Sun-3 systems) unlike all other SPARC systems which use the infamous Mostek battery-backed SRAM chip, I could also test such kernel changes on a once again less power hungry Sun-4/110, to confirm there were no regressions with the Intersil driver.
So, apart from some time working on the VME cg2 frame buffer as part of the sparc console overhaul work, this machine would only get a chance to run for a few hours about every two years.
At some point, its onboard Ethernet interface broke, no longer able to receive or transmit anything; there was no obvious damage on the motherboard from visual inspection, and the Ethernet fuse was not blown, so this was likely one of the soldered IC misbehaving, either the Intel 82586 Ethernet controller, or (more likely) some related signal converter, such as the Manchester encoder.
This crippled limited the usefulness of the machine for a few years,
until I managed to get a lot of VME boards saved from going to the recycling bin
by Peter Eriksson in Sweden in 2011, which fellow OpenBSD developer
Johan M:son Lindman arranged to pick up and ship to my place;
part of the lot were two
Intel
82586-based Ethernet boards (Sun part number 501-1153). This allowed my 4/260
to be able to communicate over the network again.
Intel Multibus Ethernet board, plugged into a Multibus-to-VME converter (click
for a larger picture).
After relocating to Orgerus in autumn 2010 I did not use that machine at all, except for confirming the newly added Ethernet board would work and allow the machine to be whole again. But in early january 2015, I convinced myself to give the machine a try again, if only to confirm that, despite its canonical age (over 25 years old at this point), it was still alive.
Not only did the system still boot, but I also had been connecting one of the SMD data cables incorrectly since the day I had gotten that machine. With the cables connected correctly, the second SMD drive, which I thought had been dead, was reported as working now:
xyc0 at vmes0 addr 0xffffee40 vec 0x48 pri 3: Xylogics 450/451 xy0 at xyc0 drive 0: ready (drive type 1) xy0: <CDC EMD 9720 cyl 1147 alt 2 hd 10 sec 48>, pcyl 1149 xy0: 268MB, 1147 cyl, 10 head, 48 sec, 512 bytes/sec xy1 at xyc0 drive 1: ready (drive type 3) xy1: <Fujitsu-M2333 cyl 821 alt 2 hd 10 sec 67>, pcyl 823 xy1: 268MB, 821 cyl, 10 head, 67 sec, 512 bytes/sec
This unexpected improvement got me in the mood to tinker a bit longer with the system and reinstall it, as I had now twice as much disk space. But after I did, the machine would no longer boot.
And it took me quite a while to figure out why.
The PROM monitor would correctly load the first stage boot block binary, written to the first 8KB of the disk partition. That first stage boot block, being limited in size, only has enough smarts to be able to load the second stage boot block from an embedded list of disk sectors (well, block numbers) and transfer control to it; the second stage boot block, having no such dire size limitation, is able to understand filesystems and load the kernel file regardless of its name and where it lies in the filesystem.
Attempting to read the sectors containing the second stage boot block would now fail with a cryptic "xy: error A" message, which did not match any possible output from the boot blocks, and was thus coming from the PROM monitor itself.
Of course, that was nothing netbooting and reinstalling the older boot blocks couldn't recover, or so I thought.
But, oddly enough, attempting to reinstall the older version of the boot blocks did not help, and I was greeted with the same error message at the next attempt to boot from disk.
There are no easy debugging capabilities in the old PROM monitor so, in order to narrow the point where a PROM call would cause this error message, the first step was to add some extra code to the first stage bootloader, in order to know up to which point it went before triggering that error.
However, due to its size limit, one can not easily do printf-debugging with detailed messages because doing so would overflow the 8KB area.
So I temporarily added extra, but terse, output to the first stage boot block, shrinking other messages to a single letter to compensate: I could then gather that it ran up to the first disk I/O operation. Removing these extra messages and adding extra code in the disk I/O routine showed that the read operation had asked the PROM to read a 16KB chunk of the disk at an apparently valid sector number, and that operation had failed.
Yet nothing had changed in my setup!
Or had it?
By reinstalling the machine, I had created new, fresh, filesystems on the disks. The first stage boot loader code, when put at the beginning of the disk by the installboot program, would have its contents modified to embed a valid list of the filesystem blocks to load, to fetch the second stage boot loader. The size of each of these blocks would be, well, the filesystem block size, also written to the first stage boot loader image.
When I had first installed OpenBSD on that machine, the default block size for filesystems was 8KB. This was changed to 16KB in july 2003, following a similar change in FreeBSD.
That would explain why the first stage boot loader was trying to read 16KB, instead of 8KB before. But this did not explain why the operation failed. That was, however, a good hint.
It turns out that the PROM monitor has its own size limit for I/O operations, and that limit had a surprising value of 8216 bytes (thus slightly more than 8KB, or 8192 bytes). Furthermore, it is nice enough to advertise that value in one of its public (and documented) data structures. So all I had to do was clamp the size of the I/O requests done by the boot loader code to that limit, and have it perform as many shorter reads as needed to read the complete data instead of assuming a single I/O request would always be enough.
This easy fix allowed me to have working boot blocks again on that machine.
Unfortunately, the joy of being able to use two SMD disks did not last. The first one quickly started growing bad sectors, and thus causing I/O errors.
On modern disks, bad sector handling (unless there are too many of them) is performed automatically behind our back, by the on-disk controller itself: it has a list of spare sectors to use for that purpose, and when bad sectors get found, I/O to them is redirected to one of the spares sectors. When there are no longer any spare sectors available, the controller doesn't have a choice but to report the error, and you should start planning a disk replacement.
SMD disks also have a provision for this, but it's the responsability of the software driver to load the list of bad sectors and their relocated position at initialization time, and manage (append to) it when new bad sectors are detected.
That code path in the Xylogics controller drivers had only been lightly tested, if at all, and, well, it caused a lot of trouble and extra error messages, as reported in a mail to a few fellow developers at that time:
Date: Sun, 11 Jan 2015 19:44:22 +0000 From: Miod Vallat To: David Gwynne, Matthew Dempsky Subject: bufq, disksort, SMD disks, the universe, and everything So, as you might have guessed from my recent commits, I've been tinkering with my Sun 4/260 system with SMD disks again. I have finally found that annoying boot blocks bug which would cause booting the miniroot in xy0b to work, but booting the installed system from xy0a to fail with the PROM printing ``xy: error A". [...] However, when I installed onto xy0a (lazy man's setup: only `a' and `b' partitions), I got a lot of ``new'' I/O errors (by ``new'', I mean that I did not experience them the last time I installed onto this disk, which unfortunately was in january 2009, 5 years ago, with xy.c r1.41.) The disk being: xyc0 at vmes0 addr 0xffffee40 vec 0x48 pri 3: Xylogics 450/451 xy0 at xyc0 drive 0: ready (drive type 1) xy0: <CDC EMD 9720 cyl 1147 alt 2 hd 10 sec 48>, pcyl 1217 xy0: 268MB, 1147 cyl, 10 head, 48 sec, 512 bytes/sec and the label being: # disklabel xy0 # /dev/rxy0c: type: SMD disk: label: CDC EMD 9720 cyl duid: 51d31bad235f6a87 flags: vendor bytes/sector: 512 sectors/track: 48 tracks/cylinder: 10 sectors/cylinder: 480 cylinders: 1147 total sectors: 550560 boundstart: 0 boundend: 550560 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] a: 491520 0 4.2BSD 2048 16384 1 # /mnt b: 59040 491520 swap c: 550560 0 unused # ... one would expect that the valid disk sectors go from C/S/H 0/0/0 to 1146/48/9. Note that I am using C/S/H instead of C/H/S because this is how xy(4) reports its error at the moment (fixing this is on my list now). So anyway, during install, which is supposed to only touch xy0a and never use swap until MAKEDEV time, I got a lot of errors: xy0a: write 1147/46/0: Illegal head xy0a: write 1147/45/9: Illegal head xy0a: write 1147/45/8: Illegal head xy0a: write 1147/45/7: Illegal head xy0a: write 1147/45/6: Illegal head xy0a: write 1147/45/2: Illegal head xy0a: write 1147/45/4: Illegal head xy0a: write 1147/45/3: Illegal head xy0a: write 1147/44/5: Illegal head xy0a: write 1147/44/6: Illegal head xy0a: write 1147/44/4: Illegal head xy0a: write 1147/44/0: Illegal head xy0a: write 1147/47/9: Illegal head xy0a: write 1147/47/8: Illegal head xy0a: write 1147/47/7: Illegal head xy0a: write 140/6/7: Header not found [still trying, new error=Header not found] xy0a: write 140/6/7: Header not found [still trying, new error=Header not found] xy0a: write 140/6/7: Header not found [still trying, new error=Header not found] xy0a: write 140/6/7: Header not found [still trying, new error=Header not found] xy0a: write 140/6/7: Header not found xy0a: write 1147/47/5: Illegal head xy0a: write 1147/47/1: Illegal head xy0a: write 1147/47/0: Illegal head xy0a: write 1147/46/8: Illegal head xy0a: write 1147/46/6: Illegal head xy0a: read 1147/45/4: Illegal head xy0a: read 1147/45/4: Illegal head xy0a: read 1147/45/4: Illegal head xy0a: read 1147/45/4: Illegal head xy0a: read 1147/45/4: Illegal head xy0a: read 1147/45/4: Illegal head xy0a: read 1147/45/4: Illegal head xy0a: read 1147/45/4: Illegal head xy0a: read 1147/45/4: Illegal head xy0a: read 1147/45/4: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/45/9: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head xy0a: write 1147/43/9: Illegal head xy0a: write 1147/43/8: Illegal head xy0a: write 1147/43/7: Illegal head While 140/6/7 is likely a newborn bad sector, all the other messages refer to bogus disk positions. Note however, that it reports ``Illegal head'', not ``Illegal cylinder address''. So it might be the case that the last cylinder does not support all the heads, and that our naive computation of the disk space as `#cylinders * #heads * #sectors' is wrong, but that's a topic for another day. What worries me is that, while installing onto xy0a which is only spanning about 85% of the disk, I see I/O errors referring to the very end of the disk. Which in turn, makes me believe that the changes to xy.c after 1.41 - which I promised I would test, and am only finally testing now, after getting an extra Ethernet board as the onboard Ethernet is no longer working - introduce regressions in the way geometry of the actual I/O is computed, but only in corner cases (since many binaries have been installed correctly), such as, during boot: openssl: generating isakmpd/iked RSA key... xy0a: read 1147/45/9: Illegal head failed. xy0a: read 1147/46/0: Illegal head xy0a: read 1147/46/0: Illegal head cp: /etc/iked/private/local.key: Input/output error xy0a: read 1147/46/0: Illegal head chmod: /etc/iked/private/local.key: Input/output error xy0a: read 1147/46/0: Illegal head cp: /etc/iked/local.pub: Input/output error I will try to dissect the xy.c changes in order to figure out what goes wrong. But if you guys have ideas of debug stuff to enable or things to check, I'd love to hear about them. You have to understand that I want to be able to brag I am booting a 1988 sparc machine off an SMD disk, in 2015. So getting rid of SMD support is not an option yet (-;
After some investigation, I found the couple of bugs which had caused these nonsensical disk addresses. They had been present in the code since the very beginning, and were slowly approaching 20 years of age.
Date: Mon, 12 Jan 2015 17:08:48 +0000 From: Miod Vallat To: David Gwynne, Matthew Dempsky Subject: Re: bufq, disksort, SMD disks, the universe, and everything Nevermind, it turns out this is a 19 years old bug (from day one) in the xy driver. Fix coming soon.
So I fixed them mercilessly anyway.
A more subtle bug was still lying in that area and caused slow filesystem corruption, eventually leading to kernel panics. It was fixed two days later.
And while I was working in that area, I implemented the necessary ioctl handlers to allow automatic partitioning with disklabel -A on SMD disks.
This did not go unnoticed.
<mlarkin> miod: "As a result, this makes disklabel -A now work on SMD disks."
<mlarkin> im not sure i want to ask if you still have these
<dlg> he does
<dlg> the best thing is my bufq changes to those drivers didnt break them
<dlg> they were already broken and he's fixing 19yo bugs in them
<tedu> i was amused to learn there are not-scsi sun4 disks
<deraadt> so those drives are about 100x the weight of a laptop drive, and if
you are lucky they can fit one src tree.
(That last comment hits hard nowadays [2026]: the OpenBSD src tree is currently weighting-in at an obese 1.8GB, including 400MB of llvm code and 550MB of Linux DRM code.)
Even with the bad sector handling code fixed, I was worried about the increase in bad sectors. Now, one old rule of handling SMD disks is that, if you ever physically move them, it is strongly advised to reformat them, because the heads alignment might have changed sligthly during transport (unlike washing machines, SMD disks usually can not be put in "stow" mode for transportation).
Yet I had never done any of this since I got the hardware, despite relocating a few times.
There is no low-level format program for SMD disks in OpenBSD (or NetBSD for that matter), so I booted good old SunOS 4.1 to run its format program, and did a low-level format of both SMD disks (which took more than one hour per disk).
Unfortunately, even after a low-level format, the CDC 9720 disk would grow more and more bad sectors, and simply become unreliable.
After relocating again late 2016, and trying yet another low-level format in the hope it might help, I had to concede defeat and retire that disk in april 2017.
At that time, I had shared a disassembly of that disk on a social network (the one using a blue bird as its logo), but this is now long lost; some of these pictures can be found below to appease your legitimate curiosity.
The disk enclosure, with a centimeter rule for scale (click for a larger
picture).
Close-up on the label (click for a larger picture).
368MB is the raw capacity, not the formatted (thus usable) capacity, from which
the filesystem overhead also needs to be subtracted.
``Configuration log'' sheet taped to the enclosure, showing it was built in
spring 1988 (click for a larger picture).
Disk open (click for a larger picture).
Note the orange colour of the disk platters; by the early 1990s, all
disk platters were now gray.
Heads assembly (with ruler for scale) (click for a larger picture).
Another view of the heads (click for a larger picture).
Bottom of the disk chassis with the heads removed (click for a larger picture).
That brown plastic part is a brake: under the chassis, there is a small
electronics board with a large capacitor and a spring which keeps the brake
away from the rotating axle. When power to the disk gets cut, the capacitor
slowly discharges and, a few seconds later, the electromagnet keeping the spring
compressed is no longer enabled, the spring is let loose and releases the brake
which quickly slows the rotating spindle (which would otherwise, due
to inertia, take minutes to stop spinning).
If you want to know more about that disk, its operation manual can be found on Bitsavers. On page 3-2 (pdf page 51), a graph of the current usage over time shows that, in order to spin up the disk, it may need (briefly) up to 6 amps.
After these fixes and the loss of one disk, I did not tinker much with that machine.
There is, however, one project left to work on: port the SunOS Ciprico Rimfire driver to BSD.
Ciprico used to produce high-performance disk and tape controllers. Their SMD controller, called ``Rimfire'', would be significantly faster than the Xylogics controller (thanks to 512KB of cache memory on the controller itself and generous use of read-ahead to fill it), and Ciprico published the source code of the drivers for their hardware (for once, this source code can not be found on Bitsavers, but instead on Peter Koch's Sun-3 Zoo downloads page).
SunOS 4 being very close to 4.2BSD, apart from IOMMU handling for DMA transfers (called ``DVMA'' on Sun-4 systems), should make the driver relatively easy to port.
I could not try this for a long time, because I did not have the appropriate cables for the Ciprico board I had obtained a long time ago (it uses different back-panel connectors than the Xylogics board). I eventually realized, many years later, that the physical connectors on the Rimfire 3224 were identical to those on the Multibus Xylogics 451, and that I could reuse Sun's intermediate connector cables found between the 451 itself and the VME backplate. (Similarly, the Rimfire 3223 has identical connectors to the Xylogics 7053.)
Ciprico Rimfire 3224 board, supporting up to four SMD drives (click for a
larger picture).
Another useful feature of the Rimfire is that models 3223 and 3224 (such as mine) can be jumpered in Xylogics 451 compatibility mode, in which case it will behave as if it were a genuine Xylogics device, until the driver takes over (this is the JSUN jumper on the bottom-left corner of the board in the picture above, jumpered with a yellow cap). This allows booting off a Rimfire-connected disk, even though the Sun PROM doesn't support this controller.
When you are replacing an SMD controller with a different model, it is strongly advised to reformat all the drives connected to the new controller. This is something I've read in all SMD controller manuals, therefore I suppose there are some controller-dependent features in every disk format, which prevents reading a disk with a different controller (let alone write to it).
After installing the Rimfire in place of the Xylogics in my system, I was indeed no longer able to boot from it. Booting SunOS from an SCSI disk also showed that the disk was unreadable. I fired the format utility and ran yet another low-level format, and the disk was usable again.
Technical note you may safely ignore! (click to expand or collapse)
Unlike more modern storage interfaces such as SCSI, SMD does not define a way for a controller to query a device for its physical geometry.
The Ciprico Rimfire supports an ``Interrogate Disk'' command to retrieve its geometry, but it does so by issueing seek commands, increasing the cylinder head and sector number values until the disk reports an error, which is anything but slow (although the cylinder number is increased by 128 as a first step narrowing its maximum value), and is documented to fail on disks with 1024 cylinders or more, because it does not try cylinder values beyond 1024, as the first revision of the SMD standard only allowed 10 bits for cylinder numbers, thus a limit of 1024 cylinders (so it wouldn't have worked on the CDC 9720 disk and its 1147 cylinders).
Because of this limitation, the first thing the system does, after formatting an SMD drive, is to write the geometry in its first sector (as it is always possible to request access to the first sector, using cylinder #0, head #0, and sector #0, without knowing how many cylinders, heads and sectors there really are).
Of course, the format program needs to know the geometry of the disk it will be operating on, and will only let you choose from a short list of SMD drives being sold at the time the format program was written, which parameters are well known.
Under SunOS, these parameters were found in a text file in /etc/format.dat, but one may choose to pass a different file to format. Here is the list of known SMD drives:
#
# This is the list of supported disks for the Xylogics 450/451 controller.
#
disk_type = "Fujitsu-M2312K" \
: ctlr = XY450 : fmt_time = 4 \
: ncyl = 587 : acyl = 2 : pcyl = 589 : nhead = 7 : nsect = 32 \
: rpm = 3600 : bpt = 20480 : bps = 621 : drive_type = 1
disk_type = "Fujitsu-M2284/M2322" \
: ctlr = XY450 : fmt_time = 4 \
: ncyl = 821 : acyl = 2 : pcyl = 823 : nhead = 10 : nsect = 32 \
: rpm = 3600 : bpt = 20480 : bps = 621 : drive_type = 2
disk_type = "Fujitsu-M2351 Eagle" \
: ctlr = XY450 : fmt_time = 4 \
: ncyl = 840 : acyl = 2 : pcyl = 842 : nhead = 20 : nsect = 46 \
: rpm = 3961 : bpt = 28160 : bps = 595 : drive_type = 0
disk_type = "Fujitsu-M2333" \
: ctlr = XY450 : fmt_time = 4 \
: ncyl = 821 : acyl = 2 : pcyl = 823 : nhead = 10 : nsect = 67 \
: rpm = 3600 : bpt = 40960 : bps = 600 : drive_type = 3
disk_type = "Fujitsu-M2361 Eagle" \
: ctlr = XY450 : fmt_time = 4 \
: ncyl = 840 : acyl = 2 : pcyl = 842 : nhead = 20 : nsect = 67 \
: rpm = 3600 : bpt = 40960 : bps = 600 : drive_type = 3
disk_type = "CDC EMD 9720" \
: ctlr = XY450 : fmt_time = 4 \
: ncyl = 1147 : acyl = 2 : pcyl = 1217 : nhead = 10 : nsect = 48 \
: rpm = 3600 : bpt = 30240 : bps = 613 : drive_type = 1
disk_type = "Hitachi DK815-10" \
: ctlr = XY450 : fmt_time = 4 \
: ncyl = 1735 : acyl = 2 : pcyl = 1737 : nhead = 15 : nsect = 67 \
: rpm = 3600 : bpt = 40960 : bps = 600 : drive_type = 1
disk_type = "NEC D2363" \
: ctlr = XY450 : fmt_time = 4 \
: ncyl = 964 : acyl = 2 : pcyl = 1024 : nhead = 27 : nsect = 67 \
: rpm = 3600 : bpt = 40960 : bps = 600 : drive_type = 2
#
# This is the list of supported disks for the Xylogics 7053 controller.
#
disk_type = "Fujitsu-M2351 Eagle" \
: ctlr = XD7053 \
: ncyl = 840 : acyl = 2 : pcyl = 842 : nhead = 20 : nsect = 46 \
: rpm = 3961 : bpt = 28160 : bps = 595
disk_type = "Fujitsu-M2333" \
: ctlr = XD7053 \
: ncyl = 821 : acyl = 2 : pcyl = 823 : nhead = 10 : nsect = 67 \
: rpm = 3600 : bpt = 40960 : bps = 600
disk_type = "Fujitsu-M2361 Eagle" \
: ctlr = XD7053 \
: ncyl = 840 : acyl = 2 : pcyl = 842 : nhead = 20 : nsect = 67 \
: rpm = 3600 : bpt = 40960 : bps = 600
disk_type = "CDC EMD 9720" \
: ctlr = XD7053 \
: ncyl = 1147 : acyl = 2 : pcyl = 1217 : nhead = 10 : nsect = 48 \
: rpm = 3600 : bpt = 30240 : bps = 613
disk_type = "Hitachi DK815-10" \
: ctlr = XD7053 \
: ncyl = 1735 : acyl = 2 : pcyl = 1737 : nhead = 15 : nsect = 67 \
: rpm = 3600 : bpt = 40960 : bps = 600
disk_type = "NEC D2363" \
: ctlr = XD7053 \
: ncyl = 964 : acyl = 2 : pcyl = 1024 : nhead = 27 : nsect = 67 \
: rpm = 3600 : bpt = 40960 : bps = 600
disk_type = "Fujitsu-M2372K" \
: ctlr = XD7053 \
: ncyl = 743 : acyl = 2 : pcyl = 745 : nhead = 27 : nsect = 67 \
: rpm = 3600 : bpt = 40960 : bps = 600
disk_type = "CDC 9720-850" \
: ctlr = XD7053 \
: ncyl = 1358 : acyl = 2 : pcyl = 1360 : nhead = 15 : nsect = 66 \
: rpm = 3600 : bpt = 41088 : bps = 610
I welcome CDC 9720-850 (Sabre-V) disk donations, in order to check if they can work on a Xylogics 451 controller and settle this question for good. I'll do that for free - it's for the greater good of mankind!
The next step was to boot the OpenBSD installer and reinstall. Unfortunately for me, while the Rimfire in Xylogics compatibility mode seems to work nicely in SunOS (but with the Xylogics driver removed from the kernel configuration), it causes the OpenBSD driver to spin during the driver initialization.
I guess the Xylogics emulation is only good enough to work with the PROM, in polling mode. The BSD driver is likely waiting for a particular bit in a control register to change value, and this does not happen with the Rimfire.
So I need to dig into the Xylogics driver initialization sequence and figure out where it gets stuck and why. And maybe start working on porting the Ciprico driver earlier than expected, if there is no chance to get the Xylogics driver to work.
But at this point, there isn't probably anyone left with a working Ciprico Rimfire but me, so this can wait until winter. Or the next winter. Or the one after...