[pups] 2.11BSD system

[pups] 2.11BSD system

[Edward Brocklesby]

Hi all,

The public access 2.11BSD system is finally back up, at styx.leguin.org.uk.  
You might find your account has been deleted, in which case just create a new 
one..

(for anyone who didn't see my original mail, styx is a public access 2.11bsd 
system on a pdp-11/70 that anyone can create an account on via telnet).

	-larne-

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id VAA36260
	for pups-liszt; Tue, 17 Apr 2001 21:59:39 +1000 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)
Received: from mx2.informatik.uni-tuebingen.de (mx2.Informatik.Uni-Tuebingen.De [134.2.12.9])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id VAA36256
	for <pups at minnie.cs.adfa.edu.au>; Tue, 17 Apr 2001 21:59:33 +1000 (EST)
	(envelope-from leypold at informatik.uni-tuebingen.de)
Received: from neuromancer.informatik.uni-tuebingen.de (neuromancer [134.2.12.58])
	by mx2.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id E41FE1062; Tue, 17 Apr 2001 13:51:13 +0200 (MST)
Received: (from leypold at localhost)
	by neuromancer.informatik.uni-tuebingen.de (8.9.3/8.8.7) id LAA21885;
	Tue, 17 Apr 2001 11:51:14 GMT
Date: Tue, 17 Apr 2001 11:51:14 GMT
Message-Id: <200104171151.LAA21885 at neuromancer.informatik.uni-tuebingen.de>
X-Authentication-Warning: neuromancer.informatik.uni-tuebingen.de: leypold set sender to leypold at informatik.uni-tuebingen.de using -f
From: Markus E Leypold <leypold@informatik.uni-tuebingen.de>
To: helbig at Informatik.BA-Stuttgart.DE
Cc: pups at minnie.cs.adfa.edu.au
In-reply-to: <200104151708.f3FH8WS05058 at RVC1.Informatik.BA-Stuttgart.DE>
	(message from Wolfgang Helbig on Sun, 15 Apr 2001 19:08:32 +0200
	(CEST))
Subject: Re: [pups] V6 and Supnik-simulator
References:  <200104151708.f3FH8WS05058 at RVC1.Informatik.BA-Stuttgart.DE>
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk


 > Delivered-To: leypold at informatik.uni-tuebingen.de
 > Date: Sun, 15 Apr 2001 19:08:32 +0200 (CEST)
 > From: Wolfgang Helbig <helbig at Informatik.BA-Stuttgart.DE>
 > Sender: owner-pups at minnie.cs.adfa.edu.au
 > 
 > Hi,
 > 
 > If the following  README sounds interesting to you, maybe we can
 > arrange to put a tar ball of it onto minnie?
 > 
 > I also prepared postscript files of the V6-documentation.
 > Anyone interested?


Yes, me in example :-). I wonder wether you could give them to dmr to be
placed just at the side of the v7 docs, or wether you could put it
into the archive?

Regards -- Markus

 > 
 > Wolfgang
 > 
 > First README:
 > UNIX V6 on the Supnik simulator:
 > --------------------------------
 > This directory contains tape files for the Supnik simulator and
 > accompaning README files, which I produced when preparing an OS
 > course at the Berufsakademie. Further it contains C-sources of two
 > commands (enblock.c/deblock.c). These commands prepare a tapefile for the
 > simulator (enblock) and produce a plain file from a simulator
 > tapefile (deblock).
 > 
 > The Supnik simulator can be obtained from:
 > 	ftp://minnie.cs.adfa.edu.au/pub/PDP-11/Sims/Supnik_2.3/sources/
 > I used the sim_2.3d.tar.gz tar ball.
 > 
 > This directory contains a *.README and *.enb files with the following
 > basenames:
 > 
 > ctable: A bug in the input table for the C-compiler code generator is fixed.
 > ctime:	Some y2k related changes to V6.
 > dcheck: Bug fix and enhancement of dcheck. 
 > dist:	The V6 distribution tape: dist.README explains how to install
 > 	and setup UNIX-V6 with the simulator. The file dist.enb is missing
 > 	for copyright and space reasons, you have to prepare it yourself.
 > 	(see enb.README). 
 > dotdot: Kernel enhancement: If in a root directoy of a mounted filesystem,
 > 	let ".." mean the parent of the mount point, not the root directory.
 > enb:	Conventions and usage of .enb files. Explains how to
 > 	prepare tape files for the Supnik simulator and tells you
 > 	how to prepare the V6 distribution tape.
 > ludiv:	Derivation of a double word unsigned division algorithm, which is used
 > 	in ctime. (no corresponding .enb)
 > man:	The man command, which was missing from the distribution, and some
 > 	changes to make V6-nroff output readable on an xterm.
 > 
 > So enb.README and dist.README are the next files you should read.
 > 
 > If you have questions or find bugs or whatever, mail to
 > 	helbig at informatik.ba-stuttgart.de
 > 
 > Last but not least I thankfully acknowledge the work of the people
 > who talked SCO into offering the ancient-UNIX source license, who collected
 > the old distribution tapes and run the PUPS Archive. And of course I thank
 > Bob Supnik for this great simulator!
 > 
 > Second README:
 > This directory contains some documentation as found on the UNIX V6
 > Distribution tape. The files were converted to postscript with
 > groff and the usage of the V6 ms-macro package. (See the print
 > shell script)
 > 
 > Assembler:				as.ps		(*)
 > Beginners Guide:			beg.ps		(*)
 > C-Language Reference:			c.ps		(***)
 > C-Tutorial:				ctut.ps		(**)
 > ED-Tutorial:				ed.ps		(*)
 > Summary of UNIX:			hel.ps		(*)
 > Description of the C-IO-Library:	iolib.ps	()
 > Description of the kernel IO/Subsystem:	iosys.ps	(**)
 > Some thought about security:		secur.ps	(*)
 > Instruction how to install V6 from tape:start.ps	(***)
 > Table of Contents of the Online Manual	toc.ps		(**)
 > Overview of UNIX (ACM-paper)		unix.ps		(***)
 > YACC - yet another compiler compiler	yacc.ps		()
 > 
 > The more stars the more useful for the OS course. Two or more stars
 > indicate high recommended!
 > 
 > >From the V7-distribution I included "A tour through the UNIX-C-Compiler"
 > (ctour.ps), which describes the internal workings of the said
 > compiler. The format and meaning of /usr/sources/c/table.s is
 > particular interesting reading if you want to learn about how a
 > compiler generates machine code.
 > 
 > The shell script "print" can be used to format the *.ps files.
 > (on a contemporary UNIX system with groff)
 > 
 > The file tmac.s contains V6-ms macros, which are used by some of
 > the doc files.
 > 
 > Some of the V6 doc files needed to be adopted to groff to render
 > acceptable output. But the 25 year old troff sources were amazingly
 > compatible with groff.
 > 

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id WAA36286
	for pups-liszt; Tue, 17 Apr 2001 22:02:15 +1000 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)
Received: from mx2.informatik.uni-tuebingen.de (mx2.Informatik.Uni-Tuebingen.De [134.2.12.9])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id WAA36282
	for <pups at minnie.cs.adfa.edu.au>; Tue, 17 Apr 2001 22:02:12 +1000 (EST)
	(envelope-from leypold at informatik.uni-tuebingen.de)
Received: from neuromancer.informatik.uni-tuebingen.de (neuromancer [134.2.12.58])
	by mx2.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 569111062; Tue, 17 Apr 2001 13:53:23 +0200 (MST)
Received: (from leypold at localhost)
	by neuromancer.informatik.uni-tuebingen.de (8.9.3/8.8.7) id LAA21888;
	Tue, 17 Apr 2001 11:53:23 GMT
Date: Tue, 17 Apr 2001 11:53:23 GMT
Message-Id: <200104171153.LAA21888 at neuromancer.informatik.uni-tuebingen.de>
X-Authentication-Warning: neuromancer.informatik.uni-tuebingen.de: leypold set sender to leypold at informatik.uni-tuebingen.de using -f
From: Markus E Leypold <leypold@informatik.uni-tuebingen.de>
To: iking at microsoft.com
Cc: helbig at Informatik.BA-Stuttgart.DE, kwellsch at tampabay.rr.com,
        pups at minnie.cs.adfa.edu.au
In-reply-to: 
	<8D25F244B8274141B5D313CA4823F39C0235D23D at red-msg-06.redmond.corp.microsoft.com>
	(iking at microsoft.com)
Subject: Re: [pups] Ken_Welsch_v6 and Dennis_v6
References:  <8D25F244B8274141B5D313CA4823F39C0235D23D at red-msg-06.redmond.corp.microsoft.com>
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

 > Delivered-To: leypold at informatik.uni-tuebingen.de
 > Content-Class: urn:content-classes:message
 > Date: Mon, 16 Apr 2001 08:34:09 -0700
 > Thread-Topic: [pups] Ken_Welsch_v6 and Dennis_v6
 > Thread-Index: AcDFGASz18jwJYwtTZmjFncUfGcq0gBccMBw
 > From: "Ian King" <iking at microsoft.com>
 > Cc: <pups at minnie.cs.adfa.edu.au>
 > Sender: owner-pups at minnie.cs.adfa.edu.au
 > 
 > All, 
 > 
 > Yes, I saw the "rights" declaration (with a non-zero switch register) on
 > a real machine (PDP-11/34a with programmer's panel), when I booted Ken's
 > v6 distribution in single-user mode (there is a specific value you enter
 > into the register, 173030, as documented in bproc.8; does anyone know
 > why this value was used?).  
 > 
 > I'm not sure why, but I was never able to get Dennis' distribution to
 > boot in the emulator; as a result, I didn't take the time to copy it


As far as I remember I had the same problem. The bootsector I think is
simply empty (god knows why). I took the bs from another disk -- and
everything was fine.

Regards -- Markus


 > over to an RK05 (using Warren's excellent tools) to boot on the 11/34.  
 > 

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id CAA37877
	for pups-liszt; Wed, 18 Apr 2001 02:15:20 +1000 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)
Received: from klamath.leguin.org.uk (pc62-oxf1.cable.ntl.com [62.254.132.62])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id CAA37873
	for <pups at minnie.cs.adfa.edu.au>; Wed, 18 Apr 2001 02:15:15 +1000 (EST)
	(envelope-from ejb at leguin.org.uk)
Received: from klamath.leguin.org.uk (klamath [127.0.0.1])
	by klamath.leguin.org.uk (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id QAA22914
	for <pups at minnie.adfa.edu.au>; Tue, 17 Apr 2001 16:06:35 GMT
X-Authentication-Warning: klamath.leguin.org.uk: Host klamath [127.0.0.1] claimed to be klamath.leguin.org.uk
Content-Type: text/plain;
  charset="iso-8859-1"
From: Edward Brocklesby <ejb@leguin.org.uk>
Organization: Leguin Network Services
To: pups at minnie.cs.adfa.edu.au
Subject: [pups] very strange problems with 2.11BSD tcp/ip stack
Date: Tue, 17 Apr 2001 16:06:34 +0000
X-Mailer: KMail [version 1.2]
MIME-Version: 1.0
Message-Id: <0104171606340L.00508 at klamath.leguin.org.uk>
Content-Transfer-Encoding: 8bit
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

hi,

I've been using the 2.11BSD tcp/ip stack fine for weeks, but now, just when 
we move it to a new host, its been very flaky.. I'm not sure if it's a 
problem with the configuration of the emulator host system, or the TCP stack 
itself.

the problem seems to be with packets arriving and being processed out of 
order.. I get this from a ping:
PING 62.242.39.162 (62.242.39.162): 56 data bytes
64 bytes from 62.242.39.162: icmp_seq=2 ttl=255 time=14.427 ms
64 bytes from 62.242.39.162: icmp_seq=3 ttl=255 time=24.571 ms
64 bytes from 62.242.39.162: icmp_seq=0 ttl=255 time=3194.977 ms
64 bytes from 62.242.39.162: icmp_seq=1 ttl=255 time=2207.308 ms
64 bytes from 62.242.39.162: icmp_seq=12 ttl=255 time=14.602 ms
64 bytes from 62.242.39.162: icmp_seq=13 ttl=255 time=24.598 ms
64 bytes from 62.242.39.162: icmp_seq=14 ttl=255 time=14.612 ms
64 bytes from 62.242.39.162: icmp_seq=15 ttl=255 time=24.571 ms
64 bytes from 62.242.39.162: icmp_seq=16 ttl=255 time=14.614 ms
64 bytes from 62.242.39.162: icmp_seq=4 ttl=255 time=12156.845 ms
64 bytes from 62.242.39.162: icmp_seq=5 ttl=255 time=11166.777 ms
64 bytes from 62.242.39.162: icmp_seq=6 ttl=255 time=10176.688 ms
64 bytes from 62.242.39.162: icmp_seq=7 ttl=255 time=9186.604 ms
64 bytes from 62.242.39.162: icmp_seq=8 ttl=255 time=8197.344 ms
64 bytes from 62.242.39.162: icmp_seq=9 ttl=255 time=7206.744 ms
64 bytes from 62.242.39.162: icmp_seq=10 ttl=255 time=6216.641 ms
64 bytes from 62.242.39.162: icmp_seq=11 ttl=255 time=5226.532 ms

but the box i'm pinging from is the host system where the emulator is 
located.. so there isn't any possible network problem. 

The configuration is, tap0 has the IP 62.242.39.161 on the host, and the 
pdp-11 has 62.242.39.162, with netmask 0xfffffff8.  Nothing else special has 
been done on either side.

on the host, we have this:

freeze% ifconfig xl0
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 195.249.6.94 netmask 0xfffffff8 broadcast 195.249.6.95
        inet6 fe80::260:97ff:fe7d:74ac%xl0 prefixlen 64 scopeid 0x1
        ether 00:60:97:7d:74:ac
        media: 100baseTX <full-duplex> status: active
        supported media: autoselect 100baseTX <full-duplex> 100baseTX 
10baseT/UTP <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
freeze% ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1532
        inet6 fe80::260:97ff:fe7d:74ac%tap0 prefixlen 64 scopeid 0xb
        inet 62.242.39.161 netmask 0xfffffffc broadcast 62.242.39.163
        ether 00:bd:e7:e0:cc:00
        Opened by PID 31257
freeze% netstat -rn
Routing tables
 
Internet:
Destination        Gateway            Flags     Refs     Use     Netif Expire
default            195.249.6.90       UGSc        2     8355      xl0
62.242.39.160/30   link#11            UC          0        0     tap0 =>
127.0.0.1          127.0.0.1          UH          2    15389      lo0
195.249.6.88/29    link#1             UC          0        0      xl0 =>


and on the pdp-11:

styx% ifconfig qe0
qe0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 62.242.39.162 netmask fffffffc broadcast 62.242.39.163
styx% netstat -rn
Routing tables
Destination      Gateway            Flags     Refs     Use  Interface
127.0.0.1        127.0.0.1          UH          0        0  lo0
62.242.39.162    127.0.0.1          UH          0        0  lo0
default          62.242.39.161      UG          1     3551  qe0
62.242.39.160    62.242.39.162      U           1      321  qe0

If someone could shed some light on this problem, it'd be much appreciated..

	-larne-

[pups] 2.11BSD system

[Cyrille Lefevre]

Edward Brocklesby <ejb at leguin.org.uk> writes:

> The public access 2.11BSD system is finally back up, at styx.leguin.org.uk.  
> You might find your account has been deleted, in which case just create a new 
> one..

works well :)

please, could you open access to /usr/src since many files are 640 ?

something like chmod -R o+r /usr/src and maybe
find /usr/src -type d -print | xargs chmod o+x

thanks in advance.

Cyrille.
--
home: mailto:clefevre at poboxes.com   UNIX is user-friendly; it's just particular
work: mailto:Cyrille.Lefevre at edf.fr   about who it chooses to be friends with.

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id QAA50563
	for pups-liszt; Thu, 19 Apr 2001 16:07:32 +1000 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)
Received: from klamath.leguin.org.uk (pc62-oxf1.cable.ntl.com [62.254.132.62])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id QAA50559
	for <pups at minnie.cs.adfa.edu.au>; Thu, 19 Apr 2001 16:07:28 +1000 (EST)
	(envelope-from ejb at leguin.org.uk)
Received: from klamath.leguin.org.uk (klamath [127.0.0.1])
	by klamath.leguin.org.uk (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id GAA08869;
	Thu, 19 Apr 2001 06:58:50 +0100
X-Authentication-Warning: klamath.leguin.org.uk: Host klamath [127.0.0.1] claimed to be klamath.leguin.org.uk
Content-Type: text/plain;
  charset="iso-8859-1"
From: Edward Brocklesby <ejb@leguin.org.uk>
Organization: Leguin Network Services
To: Cyrille Lefevre <clefevre at poboxes.com>,
        Cyrille Lefevre <clefevre-lists at noos.fr>
Subject: Re: [pups] 2.11BSD system
Date: Thu, 19 Apr 2001 06:58:49 +0100
X-Mailer: KMail [version 1.2]
Cc: pups at minnie.cs.adfa.edu.au
References: <0104170114250J.00508 at klamath.leguin.org.uk> <bspto9av.fsf at gits.dyndns.org>
In-Reply-To: <bspto9av.fsf at gits.dyndns.org>
MIME-Version: 1.0
Message-Id: <01041906584901.00527 at klamath.leguin.org.uk>
Content-Transfer-Encoding: 8bit
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

On Thursday 19 April 2001  4:30 am, Cyrille Lefevre wrote:
> please, could you open access to /usr/src since many files are 640 ?

well.. i can't do that without violating SCO's license.  however, i am 
working on a program to add people to the src group once they have indicated 
they agree to the license.

	-larne-

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id WAA52655
	for pups-liszt; Thu, 19 Apr 2001 22:06:22 +1000 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)
Received: from mail.noos.fr (descartes.noos.net [212.198.2.74])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id WAA52651
	for <pups at minnie.cs.adfa.edu.au>; Thu, 19 Apr 2001 22:06:18 +1000 (EST)
	(envelope-from root at gits.dyndns.org)
Received: (qmail 10441927 invoked by uid 0); 19 Apr 2001 11:57:47 -0000
Received: from d165.dhcp212-198-231.noos.fr (HELO gits.dyndns.org) ([212.198.231.165]) (envelope-sender <root at gits.dyndns.org>)
          by descartes.noos.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP
          for <pups at minnie.cs.adfa.edu.au>; 19 Apr 2001 11:57:47 -0000
Received: (from root at localhost)
	by gits.dyndns.org (8.11.3/8.11.3) id f3JBvgq85414;
	Thu, 19 Apr 2001 13:57:42 +0200 (CEST)
	(envelope-from root)
From: Cyrille Lefevre <root@gits.dyndns.org>
Message-Id: <200104191157.f3JBvgq85414 at gits.dyndns.org>
Subject: Re: [pups] 2.11BSD system
In-Reply-To: <01041906584901.00527 at klamath.leguin.org.uk> "from Edward Brocklesby
 at Apr 19, 2001 06:58:49 am"
To: Edward Brocklesby <ejb at leguin.org.uk>
Date: Thu, 19 Apr 2001 13:57:42 +0200 (CEST)
CC: pups at minnie.cs.adfa.edu.au
Reply-To: clefevre at poboxes.com
Organization: ACME
X-Face: V|+c;4!|B?E%BE^{E6);aI.[<<r#uCVjK"~Ke!@0vxS/.,wki/c|uVnNV!BA-_gY2sfoGc3
	f{#/$PT>97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7 at +30g0YD0*^^3jgyShN7o?a]C
	la*Zv'5NA,=963bM%J^o]C
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

Edward Brocklesby wrote:
> On Thursday 19 April 2001  4:30 am, Cyrille Lefevre wrote:
> > please, could you open access to /usr/src since many files are 640 ?
> 
> well.. i can't do that without violating SCO's license.  however, i am 
> working on a program to add people to the src group once they have indicated 
> they agree to the license.

oh! I see. forgot about that.

see you.

Cyrille.
--
home: mailto:clefevre at poboxes.com   UNIX is user-friendly; it's just particular
work: mailto:Cyrille.Lefevre at edf.fr   about who it chooses to be friends with. 

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id AAA53529
	for pups-liszt; Fri, 20 Apr 2001 00:42:00 +1000 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)
Received: from nose.cs.utoronto.ca (nose.cs.utoronto.ca [128.100.27.218])
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id AAA53525
	for <pups at minnie.cs.adfa.edu.au>; Fri, 20 Apr 2001 00:41:54 +1000 (EST)
	(envelope-from norman at nose.cs.utoronto.ca)
Message-Id: <200104191441.AAA53525 at minnie.cs.adfa.edu.au>
Subject: [pups] Sigma RQD11s, ESDI, and other naughty words
From: norman@nose.cs.utoronto.ca (Norman Wilson)
To: pups at minnie.cs.adfa.edu.au
Date: Thu, 19 Apr 2001 10:32:52 -0400
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

A couple of weeks ago, I asked if anyone had any suggestions to help
me convince a Sigma RQD11 Qbus-to-ESDI controller that it had disks
attached.  The trouble turned out to be pretty silly--the A-cable
terminator in the disk I was testing with was in backwards--but later
I discovered what may be a genuine controller botch that is worth
reporting.

Like most Qbus disk controllers, the RQD11 speaks the MSCP protocol
to the host.  More precisely it understands MSCP messages and uses
UQSSP to transmit them; UQSSP is the transport protocol used by
UNIBUS and Qbus controllers like the UDA50 and KDA50 and RQDX3 and
TQK50 and so on.  In general, the host sends commands like `bring
drive online' or `read a block' to the controller, and the controller
sends back response messages like `command succeeded' or `command failed.'
(Never mind how the data part of the block is sent to memory for now.)

The host sets up a ring of buffers for the controller to place messages
in.  Each buffer has an ownership flag: messages owned by the controller
are available to hold new messages; messages owned by the host are not,
usually because there's already a message there.  When the controller
has a message to send, it waits (if necessary) until it owns the next
buffer in the ring (the ring is used in strict round-robin order);
puts the message there; and sets the ownership flag to `host.'
When the host has handled the message, or at least copied it elsewhere,
it sets the flag back to `controller.'

When the controller gives a message to host, it also generates an
interrupt.  There are several other reasons for generating an interrupt,
so it is also supposed to set a single flag elsewhere in a communication
area in host memory to mean `there are new messages.'

My UQSSP driver code checked for new messages only if the flag was set,
and that caused me grief; it turns out that, at least when the host is
a MicroVAX III, the RQD11 sets the `new messages' flag inconsistently,
or perhaps too late.  Presumably it should have been set before requesting
the interrupt, but empirically I can see that sometimes it gets set later.
The effect was that the controller did what I told it, but my device driver
never heard the acknowledgement that said it did.  Obviously this makes
I/O unreasonably slow.

Fortunately there's a simple way around this: my driver's interrupt routine
now peeks at the ownership flag for the buffer where the next message
should appear.  (Remember that the message buffers are used in strict order,
so the host always knows exactly which buffer that is.)  When I do that,
all is well.

I suspect that many existing UQSSP drivers already did what my code does
now; in particular, the controllers and disks I am testing are known to
have worked for many years with Ultrix, and while searching for data on
the controller I came across various notes suggesting that the RQD11 works
under NetBSD/VAX as well.  But those who are writing new code or making
changes to existing code should beware; the RQD11 appears to be breaking
the rules (according to the old UQSSP manual I still have), and (as in
many real-world protocol situations) if you write your code from the spec
(as I did, in fact, albeit many years ago), the real world may trip it up.

Norman Wilson