eMSCPation proclamation

Diagram from MSCP patent

Tonight's Retrochallenge 2012 diversion features some MSCP code I wrote a couple of weeks ago, but have only just committed to the NetBSD source tree.

MSCP, or Mass Storage Control Protocol was designed by Digital Equipment Corporation to provide high level but low overhead communication with storage devices.

It was used extensively on PDP-11 and early VAX, and even some DEC MIPS system. Later systems tended to drift across to the then available SCSI.

At some point before the netbsd-6 branch the MSCP driver started behaving oddly (cleanups related to kernel threads). Under the quite excellent simh-vax emulator it would report (and ignore) an additional phantom device on the bus, but on at least some real hardware it would end up in a decidedly unhappy state, with the machine unable to access any devices.

Not actually having any real MSCP hardware made this a little harder to debug, but thanks to the delightfully interconnected world in which we live someone was willing to test build kernels based on diffs from me to track down the issue and confirm the fix.

The issue turned out to be an interesting interaction between the mscp_attach() routine, which iterated through the units on the bus, sending an M_OP_GETUNITST+M_GUM_NEXTUNIT message to each, and mscp_dorsp() which processed interrupts (and returned messages) from the devices. When probing for devices M_GUM_NEXTUNIT provides a very handy ability to find the next active unit - so if you have unit ids 0 and 8 you can probe for 0 with M_GUM_NEXTUNIT and get 0 back, then probe for 1 with M_GUM_NEXTUNIT and get 8 back, without all that tedious mucking about in hyperspace, - ahem, or rather without having to probe the intermediate unit ids. Once you try probing past the last unit, it loops around. The mishandling of this final probe was what gave the phantom device and much unhappiness.

So, some simple changes, a tweak to better handle non-contiguous unit ids, and an opportunity to replace a couple of gotos with a for(;;) loop, and NetBSD/vax is happy again.

The next phase is to clean up the MSCP code further to permit attaching new devices while the system is running. Ragge (the vax portmaster) is going to play with that one, but it seemed best to get my changes in the tree so NetBSD-6.0 will be guaranteed to have working MSCP code :)

In other news since it was updated to NetBSD 6-BETA2 the Dreamcast has finished building bash & zsh and has *nearly* finished building simh. Why would I want to build a vax emulator on a Dreamcast which uses a VAX as an NFS server? Surely there could not be some strange and twisted plan afoot? We shall just have to see...