For any MSCP disk, the proper way to find out how many sectors there are
is to ask the disk. The `unit online' command (which has to be used anyway,
to tell the controller to connect to the disk) reports the unit size in
sectors; the `get unit status' command reports the number of sectors per
track, tracks per group, and groups per cylinder. (The term `group' here
is MSCP-speak which I've never really understood; the idea seems to be that
groups are collections of cylinders that can be switched between with relatively
little time penalty, whereas switching between even adjacent cylinders is more
expensive.)
Beware, however, that modern disks usually don't have a fixed number of
sectors per track; the tracks furthest from the spindle have more sectors,
so that more of the disk surface can be used without too much density
variation. Such `zoned' disks weren't common (maybe they didn't even exist)
when the MSCP spec was first written; maybe the RA92 is new enough that it
has zones.
I've never been convinced that worrying in great detail about track and
cylinder sizes gains much performance anyway, but that's another story.
Hi,
I wonder, does anyone know for sure what is the user capacity of an RA92 in
blocks? I'm now updating disktab(5) and the driver tables in 4.3BSD-Quasijarus
to cover new RA disks, and I can't figure out the user capacity of RA92 in
blocks. For all other RA disks with no exceptions (all RA8x, all RA7x, and
RA90) the user capacity in blocks is exactly equal to the number of cylinders
multiplied by the number of heads multiplied by the number of sectors, i.e., no
funny reserved sectors or tracks or anything like that. Looking in the
disktab(5) from Ultrix V4.2 I see a perfect match between the geometry and the
partition sizes for all disks except RA92. The RA92 entry indicates 3279
cylinders, 13 heads, and 69 sectors per track, but partition c is listed as
2940951 blocks instead of 3279*13*69=2941263 blocks. Does anyone know for sure
whether the user capacity of an RA92 is 2940951 blocks, 2941263 blocks, or
something else altogether?
--
Michael Sokolov
Special Agent
International Free Computing Task Force
ARPA Internet SMTP mail: msokolov(a)meson.jpsystems.com
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id KAA17754
for pups-liszt; Sun, 5 Sep 1999 10:41:13 +1000 (EST)
Hi,
Having solved the RA72 problem and the KDA50 problem, I'm ready to attack the
next problem. :-( This time the TK50. I have a very odd problem with it. When I
first power up the VAX, everything works fine. I can read tapes, restore dumps,
etc. Then after some uptime (apparently something heat-related) it starts
behaving very oddly. Tapes with 512-byte records still read just fine, but
trying to read a tape with 10240-byte records (such as a UNIX filesystem dump
tape) results in the controller returning a hard error indication of "record
data truncated". This is so odd that I first thought it was a software problem,
but it isn't, because this happens identically under 4.3BSD-Quasijarus0 and
Ultrix V4.0, whose TMSCP drivers are completely different. The fact that the
problem occurs only after some uptime suggests some kind of overheat, which
would normally be a very low-level physical problem, but the record size
dependence suggests something high-level, more likely the controller than the
drive. This MicroVAX is still under the dealer's warranty (I just bought it on
Monday), so if this is a bad drive or controller, I can replace it, which which
of the two is it? Has anyone ever seen this problem before? Does anyone know
whether it is the drive or the controller that's bad? TIA.
--
Michael Sokolov
Special Agent
International Free Computing Task Force
ARPA Internet SMTP mail: msokolov(a)meson.jpsystems.com
P.S. The temperature in the machine room is 70F. Not the best for a machine
room, but the best you'd ever expect for an office, and I think the VAX has no
right to go on strike at 70F.
V7M was the DEC distribution of V7 (pre Ultrix days). Fred Canter did
most of the work, along with Jerry Brenner and Armando Stettner. It
supported non ID space machines, and some of the newer DEC hardware.
My manual lists it as working with :-
CPUS:- 11/23, 34, 44, 45/50/55, 60 and 70
Disks:- RL02, RK06, RK07, RM02/3, RP04/5
Tapes:- TU10, TE10, TU16, TE16, TS11
There was a strip down of V6 called Miniunix that would run on machines
without memory management, such at the 11/20, 05, 10 and 35/40 (without MMU
option). It required a full 56Kb machine, used the first 28Kb for the kernel
and swapped the last 28Kb for each process. Pipes worked by using a temporary
inode to store the data and swapping the processes. It was realllllllll slow.
The was also a similar version for 11/03's. I remember that there was an early
bug in that updates would always rewrite open inodes (last access time had
changed). You could physically wear out a floppy disk, since it was forever
rewriting the sector with the inode for the console terminal.
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id QAA00853
for pups-liszt; Thu, 2 Sep 1999 16:07:04 +1000 (EST)
>From Carl Lowenstein <cdl(a)mpl.ucsd.edu> Thu Sep 2 16:06:50 1999
Received: from mpl.ucsd.edu (chiton.ucsd.edu [192.135.238.128])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id QAA00845
for <pups(a)minnie.cs.adfa.edu.au>; Thu, 2 Sep 1999 16:06:56 +1000 (EST)
Received: (from cdl@localhost)
by mpl.ucsd.edu (8.8.8+Sun/8.8.8) id XAA06196
for pups(a)minnie.cs.adfa.edu.au; Wed, 1 Sep 1999 23:06:50 -0700 (PDT)
Date: Wed, 1 Sep 1999 23:06:50 -0700 (PDT)
From: Carl Lowenstein <cdl(a)mpl.ucsd.edu>
Message-Id: <199909020606.XAA06196(a)mpl.ucsd.edu>
To: pups(a)minnie.cs.adfa.edu.au
Subject: Re: V7M
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> Subject: Re: V7M
> cc: pups(a)minnie.cs.adfa.edu.au
> Date: Wed, 01 Sep 1999 16:44:29 -0700
> From: Kirk McKusick <mckusick(a)flamingo.mckusick.com>
>
> My recollection is that V7M stood for V7-mini. It was a
> striped down version of V7 that was designed to run on
> the very low-end PDP-11's (like the 11/20).
Well, actually the M was for Modified. Particularly modified to work
with some more DEC peripherals.
What ran on 11/20's was Mini-Unix, which was a stripped-down 6th
Edition. By the way I'm not sure that the PUPS archive has a Mini-Unix
tape. I have one, although it has not been read since the days when I
had an 11/20.
carl
carl lowenstein marine physical lab u.c. san diego
{decvax|ucbvax} !ucsd!mpl!cdl cdl(a)mpl.ucsd.edu
clowenstein(a)ucsd.edu
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id QAA00913
for pups-liszt; Thu, 2 Sep 1999 16:11:58 +1000 (EST)
>From Warren Toomey <wkt(a)cs.adfa.edu.au> Thu Sep 2 16:09:16 1999
Received: from henry.cs.adfa.edu.au (henry.cs.adfa.edu.au [131.236.21.158])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id QAA00907
for <pups(a)minnie.cs.adfa.edu.au>; Thu, 2 Sep 1999 16:11:51 +1000 (EST)
Received: (from wkt@localhost)
by henry.cs.adfa.edu.au (8.9.2/8.9.3) id QAA00770;
Thu, 2 Sep 1999 16:09:16 +1000 (EST)
From: Warren Toomey <wkt(a)cs.adfa.edu.au>
Message-Id: <199909020609.QAA00770(a)henry.cs.adfa.edu.au>
Subject: Re: V7M
In-Reply-To: <199909020606.XAA06196(a)mpl.ucsd.edu> from Carl Lowenstein at "Sep 1, 1999 11: 6:50 pm"
To: cdl(a)mpl.ucsd.edu (Carl Lowenstein)
Date: Thu, 2 Sep 1999 16:09:16 +1000 (EST)
Cc: pups(a)minnie.cs.adfa.edu.au
Reply-To: wkt(a)cs.adfa.edu.au
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
In article by Carl Lowenstein:
> Well, actually the M was for Modified. Particularly modified to work
> with some more DEC peripherals.
>
> What ran on 11/20's was Mini-Unix, which was a stripped-down 6th
> Edition. By the way I'm not sure that the PUPS archive has a Mini-Unix
> tape. I have one, although it has not been read since the days when I
> had an 11/20.
> carl
Yep, it's in Distributions/usdl/Mini-Unix. It's not in the research/
dir because it was not done in the labs, but elsewhere.
Cheers,
Warren
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id SAA00659
for pups-liszt; Thu, 2 Sep 1999 18:07:17 +1000 (EST)
>From Anders Magnusson <ragge(a)ludd.luth.se> Thu Sep 2 18:05:23 1999
Received: from zed.ludd.luth.se (zed.ludd.luth.se [130.240.16.33])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id SAA00643;
Thu, 2 Sep 1999 18:05:30 +1000 (EST)
Received: from father.ludd.luth.se (ragge(a)father.ludd.luth.se [130.240.16.18])
by zed.ludd.luth.se (8.8.5/8.8.5) with ESMTP id KAA22337;
Thu, 2 Sep 1999 10:05:25 +0200
From: Anders Magnusson <ragge(a)ludd.luth.se>
Received: (ragge@localhost) by father.ludd.luth.se (8.6.11/8.6.11) id KAA11504; Thu, 2 Sep 1999 10:05:24 +0200
Message-Id: <199909020805.KAA11504(a)father.ludd.luth.se>
Subject: Re: KDA50 woes
To: quasijarus(a)minnie.cs.adfa.edu.au
Date: Thu, 2 Sep 1999 10:05:23 +0200 (MET DST)
Cc: pups(a)minnie.cs.adfa.edu.au, quasijarus(a)minnie.cs.adfa.edu.au
In-Reply-To: <9909020115.AA00610(a)meson.jpsystems.com> from Michael Sokolov at "Sep 1, 99 08:15:23 pm"
X-Mailer: ELM [version 2.4ME+ PL15 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> Hi,
>
> I wonder, does anyone here know anything about the KDA50? I've solved my RA72
>
Well, something I think... :-)
[...]
>
> So my questions to the folks are: First, is my understanding of the situation
> correct? Second, what can be done about it? I guess as a temporary solution I
> can remove this problematic IPL autodetection code and hard-code the IPL of my
> KDA50, but what is it? Is the IPL set with switches on the KDA50 or how? And
> what do the KDA50 switches do in the first place? Does anyone know? TIA.
>
The IPL autodetect code has seemed to me as unneccessary. You know that
the KDA50 will always interrupt at spl5, so you can hard-code it in
the interrupt driver and nuke the autodetect code. The same with the
other drivers that can be on Qbus:
if (uh->uh_type == QBA)
spl5();
-- Ragge
Hi,
I wonder, does anyone here know anything about the KDA50? I've solved my RA72
problem (as it turns out, if there is no control panel connected, the drive
assumes normal operation, i.e., spin up, go on-line, enable port A, no write
protect, and the unit number between 0 and 7 is set by the switches on the
right side of the drive), but now I have a different problem: I can't get UNIX
(4.3BSD-Quasijarus of course) to recognize the KDA50, although it worked fine
on my Webster ESDI controller back in Ohio, and others have also reported
successfully booting it on different controllers. By inserting a few debugging
printouts in the uda driver, I have determined that it fails the udaprobe(). I
know very little about UDA50/KDA50 registers, so I may be wrong, but it looks
to me that the code is trying to do the following. It diddles the controller
registers to make it start the initialization. Then apparently it expects the
controller to interrupt and set some status bits in some register. However,
because of Q-bus's odd interrupt protocol and the need to determine the IPL of
the controller, the procedure is done non-trivially. First it does an spl6(),
disabling all interrupts except BR7 (which these controllers apparently don't
use). Then it does the register diddling and testing with these interrupts
disabled. It allows the CPU to field the interrupt only when the register bits
indicate that the operation has been performed and the interrupt has been
posted. Apparently the assumption is that the controller will post the
interrupt and then set the right bits in the right registers without waiting
for the CPU to field the interrupt. Also apparently the KDA50 is different and
doesn't set those bits until the interrupt is fielded, breaking this code.
So my questions to the folks are: First, is my understanding of the situation
correct? Second, what can be done about it? I guess as a temporary solution I
can remove this problematic IPL autodetection code and hard-code the IPL of my
KDA50, but what is it? Is the IPL set with switches on the KDA50 or how? And
what do the KDA50 switches do in the first place? Does anyone know? TIA.
--
Michael Sokolov
Special Agent
International Free Computing Task Force
ARPA Internet SMTP mail: msokolov(a)meson.jpsystems.com
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id PAA00399
for pups-liszt; Thu, 2 Sep 1999 15:09:20 +1000 (EST)
>From Kirk McKusick <mckusick(a)flamingo.McKusick.COM> Thu Sep 2 09:44:29 1999
Received: from knecht.sendmail.org (knecht.sendmail.org [209.31.233.160])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id PAA00395
for <pups(a)minnie.cs.adfa.edu.au>; Thu, 2 Sep 1999 15:09:13 +1000 (EST)
Received: from flamingo.McKusick.COM (root(a)flamingo.mckusick.com [209.31.233.178])
by knecht.sendmail.org (8.9.3/8.9.3) with ESMTP id RAA20755;
Wed, 1 Sep 1999 17:54:11 -0700 (PDT)
Received: from flamingo.McKusick.COM (mckusick(a)localhost.concentric.net [127.0.0.1])
by flamingo.McKusick.COM (8.9.3/8.9.0) with ESMTP id QAA29309;
Wed, 1 Sep 1999 16:44:35 -0700 (PDT)
Message-Id: <199909012344.QAA29309(a)flamingo.McKusick.COM>
To: wkt(a)cs.adfa.edu.au
Subject: Re: V7M
cc: pups(a)minnie.cs.adfa.edu.au
In-reply-to: Your message of "Mon, 09 Aug 1999 09:41:23 +1000."
<199908082341.JAA83043(a)henry.cs.adfa.edu.au>
Date: Wed, 01 Sep 1999 16:44:29 -0700
From: Kirk McKusick <mckusick(a)flamingo.McKusick.COM>
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
My recollection is that V7M stood for V7-mini. It was a
striped down version of V7 that was designed to run on
the very low-end PDP-11's (like the 11/20).
Kirk McKusick
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id PAA00533
for pups-liszt; Thu, 2 Sep 1999 15:27:01 +1000 (EST)
>From "Steven M. Schultz" <sms(a)moe.2bsd.com> Thu Sep 2 15:25:35 1999
Received: from moe.2bsd.com (0(a)MOE.2BSD.COM [206.139.202.200])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id PAA00528
for <pups(a)minnie.cs.adfa.edu.au>; Thu, 2 Sep 1999 15:26:54 +1000 (EST)
Received: (from sms@localhost)
by moe.2bsd.com (8.9.0/8.9.0) id WAA04996
for pups(a)minnie.cs.adfa.edu.au; Wed, 1 Sep 1999 22:25:35 -0700 (PDT)
Date: Wed, 1 Sep 1999 22:25:35 -0700 (PDT)
From: "Steven M. Schultz" <sms(a)moe.2bsd.com>
Message-Id: <199909020525.WAA04996(a)moe.2bsd.com>
To: pups(a)minnie.cs.adfa.edu.au
Subject: Re: V7M
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> From: Kirk McKusick <mckusick(a)flamingo.McKusick.COM>
>
> My recollection is that V7M stood for V7-mini. It was a
> striped down version of V7 that was designed to run on
> the very low-end PDP-11's (like the 11/20).
Hmmm, interesting. My memories dredge up the 'M' as meaning
"Modified". Don't recall it ever being touted as 11/20 capable
56kb, no MMU would be a wee bit too mini I'd think - was there ever
a V7 that could run without an MMU? If there was I've completely
forgotten about it.
Steven Schultz
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id PAA00770
for pups-liszt; Thu, 2 Sep 1999 15:59:45 +1000 (EST)
