Probs w. M3119 CXY08 MUX on VAX VMS 7.3

Johnny Billquist bqt at update.uu.se
Tue Aug 18 13:00:40 CDT 2015


On 2015-08-18 19:05, Jon Elson wrote:
> On 08/18/2015 10:48 AM, Holm Tiffe wrote:
>> Understand my quandary: I have changed not a single bit on the
>> hardware while cleaning and repairing it and besides that DHU11-DHV11
>> Switch the board was in the published factory setting!
> DEC went to this floating address/vector scheme back in the PDP-11 days,
> when they started building large systems like the 11/70 and using
> PDP-11's as the console for DECsystem 20's.  They'd put a huge number of
> I/O boards in such systems.  A choice of 3 pre-assigned CSR addresses
> and interrupt vectors just would not cut it in such systems.
> They had a utility you could run (at least on VAX) where you input the
> number of instances of each device, and it would print out a table of
> all the CSR and vectors to set them to.

The floating address space was pretty much there from the start for the 
Unibus, even before you had "large" systems. For most controllers, only 
the first one has a fixed address, and all others were assigned from the 
floating space. Makes sense, as it was just too costly to statically 
assign space in the I/O page for all possibly configurations you could 
imagine.

> So, the situation is that changing the number of one kind of board could
> alter the addresses of many OTHER boards!

Indeed.

> Most likely, some board was added or removed from the system before you
> got it, and it caused the vector to now be wrong.

The vector is usually not the first victim. The CSR address is, which 
cause all access to the controller to fail. But the vector often also 
move, causing the more obscure errors. However, most DEC OSes actually 
autodetected the vetor, and did not care about the actual floating 
assignment rules for the vectors.
The thing is, all you need is to trigger an interrupt on the device, and 
then notice at what vector it came in, and then you go with that. This 
only fails when several devices happen to use the same vector.

> In some cases, you had to force a device to be at a non-standard
> address, possibly because a 3rd party device could not be configured at
> the address the DEC enumeration scheme wanted to put it at.  This was
> pretty easy to do in later VMS systems.

Very easy to do in RSX-11M-PLUS as well. A simple one line command, 
which can be done on the running system.

> Unfortunately, this type of misconfiguration is fairly hard to detect
> with software.  Later devices (MSCP)  had an autoconfiguration scheme
> where the OS would assign the CSR and vector at boot time.

Well, half correct anyway.
The CSR is never autoassigned. It always is configured by switches or 
jumpers on the board. Some of the more modern controllers, like MSCP 
controllers, setup the vector through software.

CSR misconfigurations are pretty much impossible to fix, but most of the 
time easy to detect. If nothing is responding on the CSR address, the 
controller simple is not there.
Vector misonfigurations can either be handled fine by the OS, or cause 
spurious interrupts for another driver. A bit harder to detect 
sometimes. Depends on the driver. Some actually log unexpected interrupts.

	Johnny



More information about the cctalk mailing list