[TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

[TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

[Robertdkeys]

The particular webster wqesd4 I have looks like
about an '86 or so board, from chip dates, and
the main chip that is socketed is marked with
"ENGR-SAMPLE"...doh....  Maybe I do have a very
early board that won't run with a faster cpu.
The rom is a part no. 080469-01 REV 01, if that
means anything to anyone, as marked on its paper
label.  The later sigma board does not have the
problem.  Oh, well, if I have to run it with a
KA630 at slo-poke gait, so be it....(:+\\...

There are two diodes, one looks like an ordinary
silicon rectifier and one looks like a zener of
some sort, possibly, off pin 19 of the 74ls240
at position V2 on the board.  Those come off
the J6 pin 10 of 10, and are in parallel.

Thanks

Bob

[TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

[John Holden]

Early ROM revisions on the Webster MSCP controllers were too slow for the
KA650 and would often loose interrupts (amoungst other things). Signals such
as NPR and BR grants were polled from a pseudo microcode loop which took too
long.

The RS232 interface doesn't use standard receivers. Check for a 5 volt zener on
the input of an 74LS240 (from the 10 pin i/o connector) and add a schottky
in parallel (a 1N5818 would do) if one isn't there

[TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

[Norman Wilson]

If you can read this, the 4-port Wombat (Webster/Sigma ESDI controller)
in the KA650 system through which this mail must pass on its way out
is working fine, as it has since I installed it in that system a year
and a half ago.

According to my notes, I had no trouble communicating with the onboard
diagnostic monitor (with the board in another KA650 reserved for system
testing).  I used the monitor quite a bit, starting it many times,
first because it took me a long time to realize that the terminator
had been left installed backwards in one of the drives (so the drive
wasn't visible to the controller no matter what I did to the cables).
I don't think I tried the serial port on the back of the Wombat board;
instead I uttered the magic commands to load and run the Wombat communication
program on the VAX itself.  I'd expect this to be more timing-sensitive
than the hardware port.  In any case it worked fine.

Once the controller could see the disks (and I'd done some formatting
and some testing with the diagnostics), I tested the Wombat under my
oddball version of UNIX, and found what may be an MSCP implementation
botch.  A UNIBUS/QBUS MSCP storage port gets only one interrupt vector;
it is supposed to set one of two flags to indicate whether it is interrupting
because there were no command slots and it freed one, or because there
were no messages waiting to be read and it supplied one.  The Wombat
appeared often to be tardy in setting the `message waiting' flag; my
port driver often received an interrupt, checked the flags, found nothing
to do, and of course dismissed the interrupt without realizing that
the controller had in fact reported an I/O completion.  (And of course
if I halted the system and took a crash dump I found the flag set.
It took some real-time tracing to uncover the problem.)

It is easy to work around this--instead of relying on the flag, one
can go look at the message descriptors to see if there's a new message--
so that is what my driver now does.  I have a vague memory that the
original Ultrix MSCP driver, whence the current BSD one is probably
descended and the current Ultrix one more distantly, already did it
that way.  Silly me, I programmed from the protocol spec rather than
just blindly copying someone else's unexplained code ...

None of this explains why Bob Keys is having trouble, but it does
suggest to me that the Wombat firmware might have other subtle bugs
that are tickled by particular systems, perhaps even timing-dependent
problems.  (I haven't checked, but it could well be that the interrupt-
flag bug would be invisible to a KA630 because it took a little longer
to get to that part of the interrupt routine.)

I have two Wombat boards with slightly different firmware.  (One is
labelled RQD11-EC and its diagnostic monitor calls itself WOMBAT;
the other is branded by SpectraLogic, I forget what model it calls
itself, but the monitor calls itself SLEUTH.)  My notes don't say
whether they both displayed the interrupt botch.  I do know that
communications with the diagnostic monitor worked fine with both.
The RQD11-EC claimed to have firmware (or perhaps diagnostic monitor)
version 2.38.

Norman Wilson
Toronto ON

[TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

[Carl Lowenstein]

> From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
> To: tuhs at tuhs.org
> Subject: Re: [TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???
> Date: Thu, 12 Dec 02 23:29:58 PST
> 
> Robertdkeys at aol.com wrote:
> 
> > Is there an endemic problem with this style 4
> > port controller running too fast with a KA650
> > compared to a KA630 cpu?
> 
> I have no explanation for your problem, but it has nothing to do
> with speed.  Q-bus is Q-bus, and it follows Q-bus timing, which is
> completely independent of the VAX CPU timing.

Yes but there might be CPU spin-loop timing to run the serial
maintenance port from the ROM bootstrap code of the controller.
Not considered good form -- but such things happen.

Some early version of the Sigma RQD11 would work in an 11/73 but not
a KA630.  I no longer remember the exact symptoms, but I was glad that
at the time Sigma was only an 80-mile drive from here.

    carl
-- 
    carl lowenstein         marine physical lab     u.c. san diego
                                                 clowenst at ucsd.edu

[TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

[Robertdkeys]

I found out what the problem was.....(sheepishly
ducking...(:+\\...).  At 3 in the morning I had
a typeo in the config file that the old eyeballs
did not catch.  I had typed in the partitions
to allocate to root and swap, as opposed to just
the the disks.  It compiled fine, but when run,
it paniced and dumped itself all over the floor.
So much for myopic eyes programming at 3 in the
morning.....

(:+{{.....

Bob

[TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

[Michael Sokolov]

Robertdkeys at aol.com wrote:

> Is there an endemic problem with this style 4
> port controller running too fast with a KA650
> compared to a KA630 cpu?

I have no explanation for your problem, but it has nothing to do with speed.
Q-bus is Q-bus, and it follows Q-bus timing, which is completely independent of
the VAX CPU timing.

Is the new CPU board firmly seated? Nothing broken or disturbed in the
backplane when swapping the boards?

> Ultrix seems to handle it better than Tahoe.
> It might be speed in the hardware and slight
> differences in drivers?

Ultrix' MSCP code is vastly superior to anything we've ever had in BSD. I plan
to lift the MSCP/SCA framework from Ultrix wholesale in Quasijarus down the
line.

MS

[TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

[Robertdkeys]

I upgraded my MVII KA630 critters to MVIII KA650
critters.  The disk controllers in them are the
old Webster or Sigma WQESD/4 and SCD-RQD11/EC
(same boards).  When I upgraded the cpu/ram on
one of the machines, and tried to use the onboard
formatter rs232 port, the port gave crazy spaces
and backspaces continuously after the initial
boot signon msg into the controller formatter
prom.  Changing it to a DQ696 controller and the
problem went away.  On a second machine, with
KA650, it has a tendency to give uda controller
initialization errors about 50% of the time when
booting.

Is there an endemic problem with this style 4
port controller running too fast with a KA650
compared to a KA630 cpu?  It sure feels like
that.  It would be a bummer to have to use the
slower cpus on these machines....(:+{{.....

Anone else run into these kinds of problems?

Ultrix seems to handle it better than Tahoe.
It might be speed in the hardware and slight
differences in drivers?

Any suggestions or thoughts appreciated.

Thanks

Bob