Probs w. M3119 CXY08 MUX on VAX VMS 7.3
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
> So, the situation is that changing the number of one kind of board could
> alter the addresses of many OTHER boards!
> 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.
More information about the cctalk