> From: msokolov(a)ivan.Harhan.ORG (Michael Sokolov)
> To: tuhs(a)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(a)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(a)ucsd.edu
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
Robertdkeys(a)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
Wolfgang Helbig wondered,
> While studying the V6 kernel, I search for some rules as when to raise
> the interrupt priority level (IPL). I came up with something like this:
> A kernel process needs to raise the IPL if a change of data must be atomic and might
> be accessed (not necessarily changed) by an IRS.
> In light of this rule, some raising of interrupts seem unnecessary:
> - In m40.s changes of the user space segmentation registers are bracketed by raising
> and lowering the IPL, although these registers are never accessed by an ISR.
> - Likewise, in m40.s, just before the trap routine checks the runrun flag and
> restores r0, r1 and the user stackpointer, it raises the IPL. I can't see what
> possibly should go wrong, if being interrupted while restoring the values.
It's quite possible that the code is unnecessarily cautious.
In general one does not want an interrupt while something
sensitive is in a half-changed state (for example, some of
the addressing registers changed, or a stack half-switched).
For example, the clock interrupt routine can inspect user
space (for display(), for example, though this is inactive
on the 11/40), and even change it (for profiling).
It does appear that other things (checking for
a direct-from user-mode interrupt) in the clock routine
already guard against these particular problems.
It's been a long time since I've looked at this, however.
Dennis
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
>From Warren:
>
> These file are now in the Unix Archive on minnie.tuhs.org in
> PDP-11/Boot_Images/2.11_on_Simh
>
> The mirror sites should pick them up soon.
>
Robertdkeys(a)aol.com wrote:
> I am wondering if
> a dd image of a working few start blocks on a
> disk could be copied over to a raw formatted
> disk from the tape copy, before the miniroot
> went on, as part of the boot/install process?
This should work.
> Michael, what are your thoughts on setting up
> the disks, reasonably?
Well, every time I need to do this, I do some history reenactment, as this is
how Quasijarus Project was originally bootstrapped. I first install Ultrix on
the VAX, then write a Tahoe/Quasijarus disk label to the boot disk (by
compiling disklabel under Ultrix), and then do the normal 4.3-QJ0a install, at
which point the standalone system sees the label and is happy.
MS
Robertdkeys(a)aol.com wrote:
> Great! Keep me in mind for any testing if you
> need it.
I currently don't need any testing that I can't do myself, but thanks anyway.
> I still am curious as to how many on the lists
> are actually running such critters, currently,
> on Quasijarus or on Ultrix.
Well, Harhan is still up as you can see, despite the incessant bills... Pretty
much all my work on Quasijarus since 4.3-QJ0a has been on operational issues,
i.e., issues that don't matter much for hobbyists but become important when you
use it operationally for your mission-critical computing. All my VAXen are
running current unreleased code. The Internet feed is WorldCom/UUNET with a
Quasijarus-based router. I wrote all the code for the latter, which will
hopefully appear in 4.3-QJ1.
I also have an MV3100 running Ultrix whose sole purpose is to interface an
Exabyte 8 mm SCSI tape drive to my cluster. Doing backups on TK50s is
prohibitively expensive. Some day I hope to find time to port 4.3-Quasijarus to
it.
> Did you arrive at any reasonable way to do the
> initial disklabels and boot blocks so one can
> install Quasijarus directly?
That was and still is planned for 4.3-QJ1. 4.3-QJ0a and 4.3-QJ0b "officially"
support bootstrap only on DEC RA disks. Two of my running MicroVAXen are
equipped with the latter (RA72s). I also run one with ESDI disks, as I have
equipped many MicroVAXen in the past. I bootstrap the latter via Ultrix (see my
other reply).
MS
That is what I do. After several failures, I
find that using first NetBSD-1.4.1 boot to both
label and install boot blocks, followed by second,
NetBSD-1.2 boot and edlabel to trim the labels
back to something akin to a Tahoe style label,
seems to be the only way that works reliably.
The label 1.4.1 writes is different from the
Tahoe label, in that it computes incorrect c
partition sizes. It does write something that
I think is bootblock related that seems to must
be there for Quasijarus to boot on my hardware.
I am not sure exactly what it is, but using just
the 1.2 edlabel does not seem to work reliably.
The 1.2 edlabel seems to write a correct c size
partition, though, after the 1.4.1 bits are put
on. I ought to dd off the binary bits and see
what is actually being written. But, the above
seems to work, for me, and got my crashed disks
back up a few minutes ago, after hours of prom
formatting....(:+{{..... Anyway, that is how I
get the machine up. If there is a better or
easier way, someone holler. I am wondering if
a dd image of a working few start blocks on a
disk could be copied over to a raw formatted
disk from the tape copy, before the miniroot
went on, as part of the boot/install process?
An undersized disk label with reasonably sized
a and b partitions and a small but installable
h partition (big enough for the usr tarball to
fit on) should allow a bootable system to be
installed. From that it could be set up on a
second disk with correctly sized labels. Or,
when the tape was written, a selection of disk
boot/label images could be set up and a correct
one written to the boot tape for the target disk
install. What other ways could this be done?
Michael, what are your thoughts on setting up
the disks, reasonably?
Thanks
Bob
Great! Keep me in mind for any testing if you
need it. I have 4 Qbus VAXentoyz that mostly
just sit and play, when the HD's stay up. Of
late ESDI drives have been giving me fits, but
maybe I can scrounge up a few more in the local
MooU surplus feeding frenzy diving pits. Maybe,
someday, some scsi mscp cards might float up
from the depths! (dream on.....(:+}}...)
I still am curious as to how many on the lists
are actually running such critters, currently,
on Quasijarus or on Ultrix. I mostly play with
mine, doing some roffing and TeXing, and porting
a few minor tidbits.
Did you arrive at any reasonable way to do the
initial disklabels and boot blocks so one can
install Quasijarus directly? The only clean way
I can do it is to use two other OS installs that
put enough bits there that Quasijarus is happy.
There ought to be an easier way.
Anyway, keep me posted as to when Quasijarus 0b
might become reality.
Thanks
Bob Keys