I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Seventh Edition:
http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
Hi,
Warren put the v6enb.tar.gz into
http://minnie.cs.adfa.edu.au/TUHS/Archive/PDP-11/Bug_Fixes/V6enb/
Thank you, Warren!
Besides some minor and rather unimportant changes to V6, this file
contains README files, that try to explain how to install
UNIX V6 on Bob Supnik's simulator from the tape file provided by
Ken Wellsch. These setup instructions are aimed at the beginner
level with regard to UNIX as well as to the simulator.
The "bug fixes" are supplied as "diff -e" files on tp-formatted
tape files, ready to be used by the simulator.
Two simple ANSI-C programs are provided to insert (enblock) or remove
(deblock) blocking information in tape files needed by Bob's simulator.
Have fun,
Wolfgang
I was browsing through the 2.11BSD docs on my OpenBSD PC, and I noticed
I couldn't format the Pascal manuals. Can anybody format them for me
in (if at all possible) PostScript format, or else plain TXT (with ^H_
and other more(1) hacks ofcourse)? I haven't got 2.11 to work in simh
yet, otherwise I'd try it in 2.11.
--
If I traveled to the end of the rainbow
As Dame Fortune did intend,
Murphy would be there to tell me
The pot's at the other end.
-- Bert Whitney
Lars J. Buitinck
All,
My RD54 just died on me. It spins up, but, apparently, not all the way.. it
does not
make its usual calibration sound anymore. After this, the drive seems to be
dead.
Does this sound familiar? Is it the HDA or the electronics?
(I have another RD54, perhaps I can exchange the electronics pcb's ?)
--fred (__sigh__)
--
Fred N. van Kempen Fred.van.Kempen(a)MicroWalt.NL
Microsoft MCSE+I/MCSE/MCSD Compaq ASE/ACT
UNIX Systems Programmer Cisco ACRC/CCDA/CCNA/SupportPro
InterNetworking en Network Security Consultant
MicroWalt Corporation (Netherlands), Korte Heul 95, 1403 ND BUSSUM
Phone +31 (35) 6980059 FAX +31 (35) 6980215 http://WWW.MicroWalt.NL/
Dit bericht en eventuele bijlagen is uitsluitend bestemd voor de
geadresseerde. Openbaarmaking, vermenigvuldiging, verspreiding aan
derden is niet toegestaan. Er wordt geen verantwoordelijkheid
genomen voor de juiste en volledige overbrenging van de inhoud van
dit bericht, noch voor de tijdige ontvangst ervan.
Hi,
I'm having problems compiling some large-ish programs on 2.11BSD, for example
MH. Even when putting *everything* on overlays, I still get an error:
[ejb@styx] ~/mh-6.8.4.orig/uip > /bin/ld -i -X -o xforw /lib/crt0.o -Z forw.o
-Z whatnowproc.o -Z whatnowsbr.o -Z sendsbr.o -Z annosbr.o -Z distsbr.o -Z
../config/config.o -Z ../sbr/libmh.a -Z ../mts/libmts.a -Z ../zotnet/libzot.a
-Z -lc -Z -lerrlst -Z ../config/version.o
ld: too big for type 431 (problem 2: tsize = 0, ovrnd = 8192, dtotal = 0)
[ejb@styx] ~/mh-6.8.4.orig/uip >
is there any way around this, or is MH just too big to fix on a PDP?
-larne-
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id KAA56896
for pups-liszt; Fri, 20 Apr 2001 10:01:25 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
>From "Steven M. Schultz" <sms(a)moe.2bsd.com> Fri Apr 20 09:47:22 2001
Received: from moe.2bsd.com (MOE.2BSD.COM [206.139.202.200])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id KAA56892
for <pups(a)minnie.cs.adfa.edu.au>; Fri, 20 Apr 2001 10:01:20 +1000 (EST)
(envelope-from sms(a)moe.2bsd.com)
Received: (from sms@localhost)
by moe.2bsd.com (8.10.1/8.10.1) id f3JNlMq22283
for pups(a)minnie.cs.adfa.edu.au; Thu, 19 Apr 2001 16:47:22 -0700 (PDT)
Date: Thu, 19 Apr 2001 16:47:22 -0700 (PDT)
From: "Steven M. Schultz" <sms(a)moe.2bsd.com>
Message-Id: <200104192347.f3JNlMq22283(a)moe.2bsd.com>
To: pups(a)minnie.cs.adfa.edu.au
Subject: Re: [pups] Maximum PDP-11 executable size?
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
Hi -
> From: Edward Brocklesby <ejb(a)leguin.org.uk>
> I'm having problems compiling some large-ish programs on 2.11BSD, for example
> MH. Even when putting *everything* on overlays, I still get an error:
It has been eons and eons since I attempted MH and I can't remember
if I gave up or finally got something to work (shows how long its
been ;)).
> [ejb@styx] ~/mh-6.8.4.orig/uip > /bin/ld -i -X -o xforw /lib/crt0.o -Z forw.o
> -Z whatnowproc.o -Z whatnowsbr.o -Z sendsbr.o -Z annosbr.o -Z distsbr.o -Z
> ../config/config.o -Z ../sbr/libmh.a -Z ../mts/libmts.a -Z ../zotnet/libzot.a
> -Z -lc -Z -lerrlst -Z ../config/version.o
> ld: too big for type 431 (problem 2: tsize = 0, ovrnd = 8192, dtotal = 0)
> [ejb@styx] ~/mh-6.8.4.orig/uip >
Hmmm, I grep'd the current source to 'ld' and couldn't find the
message "problem 2: ...". I do remember that being present during
the debugging of 'ld' when the long symbol names (the "string table"
aka 4.3BSD a.out format) capability was being developed.
That suggests that 'ld' might be out of date.
The answer to the 'Maximum PDP-11 executable size?' question is fairly
length and a bit involved ;). Assuming split I/D:
Short answer: 120KB to 904KB
Long answer:
without overlays there is one 64KB code segment and one 56KB data
segment giving 120KB for a non overlaid program. In practice if a
program hits 56KB out of 'ld' then there's no room for malloc() and
the program may link but it won't run ;(
For overlaid programs there is still but one 56KB data segment (the top
8KB is for the stack) but now the code can be arranged differently:
There is a maximum of 15 overlays and there can be no 'gaps' (zero
length/empty overlays between populated overlays).
BASE OVERLAYSIZE TOTALTEXT
8KB 56KB * 15 840KB
16KB 48KB * 15 736KB
24KB 40KB * 15 624KB
32KB 32KB * 15 512KB
40KB 24KB * 15 400KB
48KB 16KB * 15 288KB
56KB 8KB * 15 176KB
In reality the kernel probably would choke on the first several cases,
and even if it didn't that large of a program would cause severe
swapping.
Most overlaid programs on the system ('vi' for example) use either the
base=48KB or base=56KB layout. I think 'kermit' might use the 40KB
base segment.
The "tsize" error would indicate that the code size summing had an
overflow - that was a bug at one time and was later fixed, which
again suggests that the 'ld' is out dated somehow.
If 'ld' was able to create 'xforw' try doing a "size xforw" on it
and seeing how far it got - perhaps a clue can be gathered that
way.
You may need to usually terminate the overlay list with a -Y - I don't
believe it's "required" though.
-Z -lc -Z -lerrlst -Y ../config/version.o
> is there any way around this, or is MH just too big to fix on a PDP?
Couple things to try. Use 'size' on the .o (and/or .a) files to
see how big things are - add them up and see if things start overflowing
16 bits. There was an overflow bug in ld's size computations - it was
fixed by using a 'long' in a couple places to detect wraparound.
What version of 2.11 (should be in the first couple lines of /VERSION)
are you using? Sure feels like 'ld' is old and having problems that
were fixed later on.
Steven Schultz
sms(a)to.gd-es.com
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id KAA57165
for pups-liszt; Fri, 20 Apr 2001 10:57:13 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
>From Edward Brocklesby <ejb(a)leguin.org.uk> Fri Apr 20 10:48:19 2001
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 KAA57161
for <pups(a)minnie.cs.adfa.edu.au>; Fri, 20 Apr 2001 10:57:08 +1000 (EST)
(envelope-from ejb(a)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 BAA17554;
Fri, 20 Apr 2001 01:48:21 +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(a)leguin.org.uk>
Organization: Leguin Network Services
To: "Steven M. Schultz" <sms(a)moe.2bsd.com>, pups(a)minnie.cs.adfa.edu.au
Subject: Re: [pups] Maximum PDP-11 executable size?
Date: Fri, 20 Apr 2001 01:48:19 +0100
X-Mailer: KMail [version 1.2]
References: <200104192347.f3JNlMq22283(a)moe.2bsd.com>
In-Reply-To: <200104192347.f3JNlMq22283(a)moe.2bsd.com>
MIME-Version: 1.0
Message-Id: <01042001482004.00527(a)klamath.leguin.org.uk>
Content-Transfer-Encoding: 8bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
On Friday 20 April 2001 12:47 am, Steven M. Schultz wrote:
> > [ejb@styx] ~/mh-6.8.4.orig/uip > /bin/ld -i -X -o xforw /lib/crt0.o -Z
> > forw.o -Z whatnowproc.o -Z whatnowsbr.o -Z sendsbr.o -Z annosbr.o -Z
> > distsbr.o -Z ../config/config.o -Z ../sbr/libmh.a -Z ../mts/libmts.a -Z
> > ../zotnet/libzot.a -Z -lc -Z -lerrlst -Z ../config/version.o
> > ld: too big for type 431 (problem 2: tsize = 0, ovrnd = 8192, dtotal = 0)
> > [ejb@styx] ~/mh-6.8.4.orig/uip >
>
> Hmmm, I grep'd the current source to 'ld' and couldn't find the
> message "problem 2: ...". I do remember that being present during
That's something I added myself, to try to help with the problem..
> That suggests that 'ld' might be out of date.
/VERSION says:
Current Patch Level: 400
Date: January 24, 1998
That's what was on the PUPS FTP site..
> without overlays there is one 64KB code segment and one 56KB data
> segment giving 120KB for a non overlaid program. In practice if a
> program hits 56KB out of 'ld' then there's no room for malloc() and
> the program may link but it won't run ;(
>
> For overlaid programs there is still but one 56KB data segment (the top
> 8KB is for the stack) but now the code can be arranged differently:
>
> There is a maximum of 15 overlays and there can be no 'gaps' (zero
> length/empty overlays between populated overlays).
>
> BASE OVERLAYSIZE TOTALTEXT
> 8KB 56KB * 15 840KB
> 16KB 48KB * 15 736KB
> 24KB 40KB * 15 624KB
> 32KB 32KB * 15 512KB
> 40KB 24KB * 15 400KB
> 48KB 16KB * 15 288KB
> 56KB 8KB * 15 176KB
>
> In reality the kernel probably would choke on the first several cases,
> and even if it didn't that large of a program would cause severe
> swapping.
>
> Most overlaid programs on the system ('vi' for example) use either the
> base=48KB or base=56KB layout. I think 'kermit' might use the 40KB
> base segment.
hm.. how do you specify the base segment size to ld? i don't see anything in
the manual page. Just link enough code into the base that it becomes the
right size?
> The "tsize" error would indicate that the code size summing had an
> overflow - that was a bug at one time and was later fixed, which
> again suggests that the 'ld' is out dated somehow.
possibly, i will look on the 2BSD patch archives now..
> If 'ld' was able to create 'xforw' try doing a "size xforw" on it
> and seeing how far it got - perhaps a clue can be gathered that
> way.
text data bss dec hex
27648 35860 32412 95920 176b0 total text: 83072
overlays: 832,4352,2624,832,1920,29568,192,11008,4096
this particular link gave the error:
ld: too big for type 431 (problem 2: tsize = 0, ovrnd = -32768, dtotal = 0)
the negative ovrnd i find very strange- perhaps the wrapround bug?
> You may need to usually terminate the overlay list with a -Y - I don't
> believe it's "required" though.
>
> -Z -lc -Z -lerrlst -Y ../config/version.o
nope.. this doesn't seem to help
> > is there any way around this, or is MH just too big to fix on a PDP?
>
> Couple things to try. Use 'size' on the .o (and/or .a) files to
> see how big things are - add them up and see if things start overflowing
> 16 bits. There was an overflow bug in ld's size computations - it was
> fixed by using a 'long' in a couple places to detect wraparound.
Well, considering that there's a couple of *large* libraries here..
-rw-r--r-- 1 ejb 127074 Apr 9 14:47 ../zotnet/libzot.a
-rw-r--r-- 1 ejb 102126 Apr 9 14:39 ../sbr/libmh.a
maybe that's the problem..
-larne-
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id NAA57746
for pups-liszt; Fri, 20 Apr 2001 13:01:24 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
>From "Steven M. Schultz" <sms(a)moe.2bsd.com> Fri Apr 20 12:42:54 2001
Received: from moe.2bsd.com (MOE.2BSD.COM [206.139.202.200])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id NAA57741
for <pups(a)minnie.cs.adfa.edu.au>; Fri, 20 Apr 2001 13:01:19 +1000 (EST)
(envelope-from sms(a)moe.2bsd.com)
Received: (from sms@localhost)
by moe.2bsd.com (8.10.1/8.10.1) id f3K2gsf23361
for pups(a)minnie.cs.adfa.edu.au; Thu, 19 Apr 2001 19:42:54 -0700 (PDT)
Date: Thu, 19 Apr 2001 19:42:54 -0700 (PDT)
From: "Steven M. Schultz" <sms(a)moe.2bsd.com>
Message-Id: <200104200242.f3K2gsf23361(a)moe.2bsd.com>
To: pups(a)minnie.cs.adfa.edu.au
Subject: Re: [pups] Maximum PDP-11 executable size?
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
Hi -
> > message "problem 2: ...". I do remember that being present during
>
> That's something I added myself, to try to help with the problem..
Ok - whew, for a minute there I thought some of my debug code had
leaked to the world ;) That's the style of debug message I use <g>
> /VERSION says:
> Current Patch Level: 400
> Date: January 24, 1998
Ouch - that is a bit old, there are updates thru 434 (I've 435 in
midstream but haven't had time to finish it).
> That's what was on the PUPS FTP site..
Ah. Much becomes clear now. That indeed was the version at one time.
A year or so ago I and Warren coordinated an update to the 2.11 in PUPS
The current PUPS version is 431 (only 3 updates since then - I've
slowed down a lot over the last couple years).
> hm.. how do you specify the base segment size to ld? i don't see anything in
You don't. At least not directly. Anything outside an overlay
goes into the base segment. Thus anything before the first -Z goes
into the base, and anything after the -Y goes into the base.
> the manual page. Just link enough code into the base that it becomes the
> right size?
That's basically the way to do it. You can do "size" on the .o files
first to get an idea what you want to put where but after that tuning
the overlays to fit is a bit of an art.
> text data bss dec hex
> 27648 35860 32412 95920 176b0 total text: 83072
> overlays: 832,4352,2624,832,1920,29568,192,11008,4096
the single BIGGEST problem is that 'data + bss' exceeds not only the
56KB limit but the total 64KB limit available to a process. Looks
like MH want 35860+32412 or 68272 bytes of D space.
You might be able to get the code to fit - I'd pack the base to at
least 40KB (more likely 48KB) and only have two or three overlays
of 24KB or 16KB.
THe data space problem means you're going to have to go and lower
a lot of the buffer size limits. Remember: even if you do get
the dataspace down to where the linker doesn't complain the program
will almost certainly try to malloc() memory. Thus the smaller the
data+bss the better - and be prepared for malloc() failures
One thing that can be done is to run 'xstr' over the sources and
collect error message strings, printf strings, and so on into a common
pool. The other thing that can be done is create a strings file
and extract as many as possible strings from the source modules into
an external file. Examples of doing this type of thing can be found
in the source tree - 'lint' was one such program, 'sendmail' was another
and kermit yet another (that's why there are 'sendmail.sr' and
'kermit5.sr' files on the system).
In fact 'kermit' is a good example of squishing a monster program into
a small machine. Check out /usr/src/new/kermit5.188
> ld: too big for type 431 (problem 2: tsize = 0, ovrnd = -32768, dtotal = 0)
>
> the negative ovrnd i find very strange- perhaps the wrapround bug?
Hmmm, could be.
> Well, considering that there's a couple of *large* libraries here..
> -rw-r--r-- 1 ejb 127074 Apr 9 14:47 ../zotnet/libzot.a
> -rw-r--r-- 1 ejb 102126 Apr 9 14:39 ../sbr/libmh.a
>
> maybe that's the problem..
The size of the .a doesn't accurately reflect the code+text+bss
For one thing 'bss' takes up no room at all in an archive. Don't
forget that symbol tables and relocation information (as well as
'ar' book keeping info) is present. You can't rely on "ls -l"
to say very much about an object file - only "size" can do that.
"size libmh.a" will give a much better idea where the problem areas
are.
Steven Schultz
sms(a)to.gd-es.com
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id OAA58045
for pups-liszt; Fri, 20 Apr 2001 14:21:45 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
>From Edward Brocklesby <ejb(a)leguin.org.uk> Fri Apr 20 14:12:58 2001
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 OAA58041
for <pups(a)minnie.cs.adfa.edu.au>; Fri, 20 Apr 2001 14:21:41 +1000 (EST)
(envelope-from ejb(a)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 FAA19106;
Fri, 20 Apr 2001 05:12:59 +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(a)leguin.org.uk>
Organization: Leguin Network Services
To: "Steven M. Schultz" <sms(a)moe.2bsd.com>, pups(a)minnie.cs.adfa.edu.au
Subject: Re: [pups] Maximum PDP-11 executable size?
Date: Fri, 20 Apr 2001 05:12:58 +0100
X-Mailer: KMail [version 1.2]
References: <200104200242.f3K2gsf23361(a)moe.2bsd.com>
In-Reply-To: <200104200242.f3K2gsf23361(a)moe.2bsd.com>
MIME-Version: 1.0
Message-Id: <01042005125805.00527(a)klamath.leguin.org.uk>
Content-Transfer-Encoding: 8bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
On Friday 20 April 2001 3:42 am, Steven M. Schultz wrote:
> the single BIGGEST problem is that 'data + bss' exceeds not only the
> 56KB limit but the total 64KB limit available to a process. Looks
> like MH want 35860+32412 or 68272 bytes of D space.
>
> You might be able to get the code to fit - I'd pack the base to at
> least 40KB (more likely 48KB) and only have two or three overlays
> of 24KB or 16KB.
The problem appears to be `libmh.a', which alone has 30K text + 22K data +
24K bss (77444 total). Any way around this? I've tried all the combinations
i can think of, to no avail..
> One thing that can be done is to run 'xstr' over the sources and
> collect error message strings, printf strings, and so on into a common
> pool. The other thing that can be done is create a strings file
> and extract as many as possible strings from the source modules into
> an external file. Examples of doing this type of thing can be found
> in the source tree - 'lint' was one such program, 'sendmail' was another
> and kermit yet another (that's why there are 'sendmail.sr' and
> 'kermit5.sr' files on the system).
hmm... a lot of work just to get MH working.
> > ld: too big for type 431 (problem 2: tsize = 0, ovrnd = -32768, dtotal =
> > 0)
> >
> > the negative ovrnd i find very strange- perhaps the wrapround bug?
>
> Hmmm, could be.
Could be i used the wrong printf format also..
> "size libmh.a" will give a much better idea where the problem areas
> are.
unfortunately, size doesn't appear to work on archive libraries.
-larne-
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id PAA58237
for pups-liszt; Fri, 20 Apr 2001 15:01:25 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
>From "Steven M. Schultz" <sms(a)moe.2bsd.com> Fri Apr 20 14:49:59 2001
Received: from moe.2bsd.com (MOE.2BSD.COM [206.139.202.200])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id PAA58232
for <pups(a)minnie.cs.adfa.edu.au>; Fri, 20 Apr 2001 15:01:21 +1000 (EST)
(envelope-from sms(a)moe.2bsd.com)
Received: (from sms@localhost)
by moe.2bsd.com (8.10.1/8.10.1) id f3K4nxv24294
for pups(a)minnie.cs.adfa.edu.au; Thu, 19 Apr 2001 21:49:59 -0700 (PDT)
Date: Thu, 19 Apr 2001 21:49:59 -0700 (PDT)
From: "Steven M. Schultz" <sms(a)moe.2bsd.com>
Message-Id: <200104200449.f3K4nxv24294(a)moe.2bsd.com>
To: pups(a)minnie.cs.adfa.edu.au
Subject: Re: [pups] Maximum PDP-11 executable size?
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> From: Edward Brocklesby <ejb(a)leguin.org.uk>
> The problem appears to be `libmh.a', which alone has 30K text + 22K data +
> 24K bss (77444 total). Any way around this? I've tried all the combinations
> i can think of, to no avail..
I think this would be a very good time to point out that 'data' is
NOT overlaid, only the text is overlaid. There is but 1 data segment
and all data+bss goes into it.
Text overlays work because there's a very careful dance done by the
assembler and linker. Functions use a 'thunk' (intermediate
transfer vector) - thus when a program calls foo() it is really
calling something like ~foo(). That thunk performs part of the
function prolog and then checks if the overlay mapping needs to changeoa and if so makes a syscall to have the kernel twiddle the MMU. Then
the thunk calls foo+4 (skipping the part of the function prolog that
has already been done). Very elegant but completely unapplicable
to data references (think on it - how is each and every pointer
dereference to be checked to see if that data is mapped in?).
In order to get the code to fit it would be necessary to extract
all of the .o files from the .a file ("ar x libmh.a") and
pack the .o files into overlays so they fit nicely.
> > One thing that can be done is to run 'xstr' over the sources and
>
> hmm... a lot of work just to get MH working.
Getting 32bit programs (and MH was done on a VAX or PDP10 (which is
actually a 36 bit machine ;)) to run on a 16 bit machine is a lot of
work.
Since MH was written with a large address space in mind it will likely
be necessary to go thru the code and find the "#define BUFSIZE 32000"
or whatever and scale things back. The odds are good that many
buffers are declared to be large just because it didn't matter on
a big address space machine. That's what had to be done for 'vi',
'sendmail', 'kermit', etc.
> > "size libmh.a" will give a much better idea where the problem areas
> > are.
>
> unfortunately, size doesn't appear to work on archive libraries.
Oh. Darn, I got my systems mixed up. On some systems 'size' will
work on .a files - something to put on the TODO pile (shouldn't be
too hard since 'nm' works with .a files).
Steven Schultz
sms(a)moe.2bsd.com
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id PAA58368
for pups-liszt; Fri, 20 Apr 2001 15:35:23 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
>From Edward Brocklesby <ejb(a)leguin.org.uk> Fri Apr 20 15:26:25 2001
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 PAA58364
for <pups(a)minnie.cs.adfa.edu.au>; Fri, 20 Apr 2001 15:35:18 +1000 (EST)
(envelope-from ejb(a)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 GAA19840;
Fri, 20 Apr 2001 06:26:27 +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(a)leguin.org.uk>
Organization: Leguin Network Services
To: "Steven M. Schultz" <sms(a)moe.2bsd.com>, pups(a)minnie.cs.adfa.edu.au
Subject: Re: [pups] Maximum PDP-11 executable size?
Date: Fri, 20 Apr 2001 06:26:25 +0100
X-Mailer: KMail [version 1.2]
References: <200104200449.f3K4nxv24294(a)moe.2bsd.com>
In-Reply-To: <200104200449.f3K4nxv24294(a)moe.2bsd.com>
MIME-Version: 1.0
Message-Id: <01042006262506.00527(a)klamath.leguin.org.uk>
Content-Transfer-Encoding: 8bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
On Friday 20 April 2001 5:49 am, Steven M. Schultz wrote:
> In order to get the code to fit it would be necessary to extract
> all of the .o files from the .a file ("ar x libmh.a") and
> pack the .o files into overlays so they fit nicely.
hmm.. i might have a look at doing this after i get xstr working.
> Getting 32bit programs (and MH was done on a VAX or PDP10 (which is
> actually a 36 bit machine ;)) to run on a 16 bit machine is a lot of
> work.
36bit with 9bit bytes, iirc .. fun :>
I'm currently converting libmh.a to use xstr, but I've come across a
problem.. given the definition
static char unixbuf[BUFSIZ] = "";
xstr generates the code
static char unixbuf[BUFSIZ] = (&xstr[0]);
which the C compiler refuses to compile. Any way around this?
-larne-
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id RAA59071
for pups-liszt; Fri, 20 Apr 2001 17:41:53 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
>From Wolfgang Helbig <helbig(a)Informatik.BA-Stuttgart.DE> Fri Apr 20 17:37:28 2001
Received: from RVC1.Informatik.BA-Stuttgart.DE (isdn258.s.netic.de [212.9.163.2])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id RAA59067
for <pups(a)minnie.cs.adfa.edu.au>; Fri, 20 Apr 2001 17:41:48 +1000 (EST)
(envelope-from helbig(a)Informatik.BA-Stuttgart.DE)
Received: (from helbig@localhost)
by RVC1.Informatik.BA-Stuttgart.DE (8.11.2/8.9.3) id f3K7bSv10954;
Fri, 20 Apr 2001 09:37:28 +0200 (CEST)
Date: Fri, 20 Apr 2001 09:37:28 +0200 (CEST)
From: Wolfgang Helbig <helbig(a)Informatik.BA-Stuttgart.DE>
Message-Id: <200104200737.f3K7bSv10954(a)RVC1.Informatik.BA-Stuttgart.DE>
To: helbig(a)Informatik.BA-Stuttgart.DE, leypold(a)informatik.uni-tuebingen.de
Subject: Re: [pups] V6 and Supnik-simulator
Cc: pups(a)minnie.cs.adfa.edu.au
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> > 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?
I asked Dennis, and he told me, the best place for those directories
is the minnie archive. So I'd like to put it there, but don't know how to.
Wolfgang
>
> 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
[...]
> > 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)
[...]
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id SAA59307
for pups-liszt; Fri, 20 Apr 2001 18:22:59 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
>From Markus E Leypold <leypold(a)informatik.uni-tuebingen.de> Fri Apr 20 18:15:44 2001
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 SAA59303
for <pups(a)minnie.cs.adfa.edu.au>; Fri, 20 Apr 2001 18:22:55 +1000 (EST)
(envelope-from leypold(a)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 C80C01066; Fri, 20 Apr 2001 10:14:18 +0200 (MST)
Received: (from leypold@localhost)
by neuromancer.informatik.uni-tuebingen.de (8.9.3/8.8.7) id IAA01537;
Fri, 20 Apr 2001 08:15:44 GMT
Date: Fri, 20 Apr 2001 08:15:44 GMT
Message-Id: <200104200815.IAA01537(a)neuromancer.informatik.uni-tuebingen.de>
X-Authentication-Warning: neuromancer.informatik.uni-tuebingen.de: leypold set sender to leypold(a)informatik.uni-tuebingen.de using -f
From: Markus E Leypold <leypold(a)informatik.uni-tuebingen.de>
To: helbig(a)Informatik.BA-Stuttgart.DE
Cc: helbig(a)Informatik.BA-Stuttgart.DE, pups(a)minnie.cs.adfa.edu.au
In-reply-to: <200104200737.f3K7bSv10954(a)RVC1.Informatik.BA-Stuttgart.DE>
(message from Wolfgang Helbig on Fri, 20 Apr 2001 09:37:28 +0200
(CEST))
Subject: Re: [pups] V6 and Supnik-simulator
References: <200104200737.f3K7bSv10954(a)RVC1.Informatik.BA-Stuttgart.DE>
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> Delivered-To: leypold(a)informatik.uni-tuebingen.de
> Date: Fri, 20 Apr 2001 09:37:28 +0200 (CEST)
> From: Wolfgang Helbig <helbig(a)Informatik.BA-Stuttgart.DE>
> Cc: pups(a)minnie.cs.adfa.edu.au
>
> > > 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?
>
> I asked Dennis, and he told me, the best place for those directories
> is the minnie archive. So I'd like to put it there, but don't know how to.
Well -- send a mail to warren k tomey (wkt@.... -- you'll find him in
the mailing list). He has been building the archive and might tell
you, how to transfer the files. Since PUPS-archive has an incoming
directory, I think, it might be, that ftp-'put' to incoming will
work. Warren or some other archive maintainer can pick it from there,
and place it in the proper directories.
Ask Warren. He is the one who should know.
Regards -- Markus
PS: Somehow I know your name. You haven't written a book by chance?
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id TAA59510
for pups-liszt; Fri, 20 Apr 2001 19:00:17 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
>From Johnny Billquist <bqt(a)update.uu.se> Fri Apr 20 18:51:19 2001
Received: from Tempo.Update.UU.SE (root(a)Tempo.Update.UU.SE [130.238.19.17])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id TAA59503
for <pups(a)minnie.cs.adfa.edu.au>; Fri, 20 Apr 2001 19:00:11 +1000 (EST)
(envelope-from bqt(a)update.uu.se)
Received: from localhost (bqt@localhost)
by Tempo.Update.UU.SE (8.11.2/8.11.2/Update-Iltempogigante) with ESMTP id f3K8pKq08127;
Fri, 20 Apr 2001 10:51:20 +0200
Date: Fri, 20 Apr 2001 10:51:19 +0200 (CEST)
From: Johnny Billquist <bqt(a)update.uu.se>
To: Edward Brocklesby <ejb(a)leguin.org.uk>
cc: "Steven M. Schultz" <sms(a)moe.2bsd.com>, pups(a)minnie.cs.adfa.edu.au
Subject: Re: [pups] Maximum PDP-11 executable size?
In-Reply-To: <01042006262506.00527(a)klamath.leguin.org.uk>
Message-ID: <Pine.LNX.4.21.0104201049370.3728-100000(a)Tempo.Update.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
On Fri, 20 Apr 2001, Edward Brocklesby wrote:
> On Friday 20 April 2001 5:49 am, Steven M. Schultz wrote:
> > Getting 32bit programs (and MH was done on a VAX or PDP10 (which is
> > actually a 36 bit machine ;)) to run on a 16 bit machine is a lot of
> > work.
>
> 36bit with 9bit bytes, iirc .. fun :>
Actually, the PDP-10 have variable byte size. Anything from 1 to 36
bits. Lazy people went with 9 bit bytes, while size-aware people used 7
bit bytes. And then you have SIXBIT...
/Department for worthless knowledge. :-)
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id FAA65073
for pups-liszt; Sat, 21 Apr 2001 05:02:46 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
>From Tom Ivar Helbekkmo <tih(a)Hamartun.Priv.NO> Sat Apr 21 04:23:51 2001
Received: from uucp-relay.eunet.no (gasspedal.eunet.no [193.71.71.15])
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id FAA65069
for <pups(a)minnie.cs.adfa.edu.au>; Sat, 21 Apr 2001 05:02:41 +1000 (EST)
(envelope-from tih(a)barsoom.Hamartun.Priv.NO)
Received: (from uucp@localhost)
by uucp-relay.eunet.no (8.9.3/8.9.3) with UUCP id UAA97313;
Fri, 20 Apr 2001 20:54:02 +0200 (CEST)
(envelope-from tih(a)barsoom.Hamartun.Priv.NO)
Received: by barsoom.Hamartun.Priv.NO (Postfix, from userid 1001)
id D4DED7201; Fri, 20 Apr 2001 20:23:52 +0200 (CEST)
To: "Steven M. Schultz" <sms(a)moe.2bsd.com>
Cc: pups(a)minnie.cs.adfa.edu.au
Subject: Re: [pups] Maximum PDP-11 executable size?
References: <200104200242.f3K2gsf23361(a)moe.2bsd.com>
From: Tom Ivar Helbekkmo <tih(a)Hamartun.Priv.NO>
Date: 20 Apr 2001 20:23:51 +0200
In-Reply-To: "Steven M. Schultz"'s message of "Thu, 19 Apr 2001 19:42:54 -0700 (PDT)"
Message-ID: <867l0f8m6g.fsf(a)barsoom.Hamartun.Priv.NO>
User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
"Steven M. Schultz" <sms(a)moe.2bsd.com> writes:
> > Current Patch Level: 400
> > Date: January 24, 1998
>
> Ouch - that is a bit old, there are updates thru 434 (I've 435 in
> midstream but haven't had time to finish it).
You mean 435/436: patch 435 was released on February 7th, 2001. :-)
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
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
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@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(a)minnie.cs.adfa.edu.au)
>From Markus E Leypold <leypold(a)informatik.uni-tuebingen.de> Tue Apr 17 21:51:14 2001
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(a)minnie.cs.adfa.edu.au>; Tue, 17 Apr 2001 21:59:33 +1000 (EST)
(envelope-from leypold(a)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@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(a)neuromancer.informatik.uni-tuebingen.de>
X-Authentication-Warning: neuromancer.informatik.uni-tuebingen.de: leypold set sender to leypold(a)informatik.uni-tuebingen.de using -f
From: Markus E Leypold <leypold(a)informatik.uni-tuebingen.de>
To: helbig(a)Informatik.BA-Stuttgart.DE
Cc: pups(a)minnie.cs.adfa.edu.au
In-reply-to: <200104151708.f3FH8WS05058(a)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(a)RVC1.Informatik.BA-Stuttgart.DE>
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> Delivered-To: leypold(a)informatik.uni-tuebingen.de
> Date: Sun, 15 Apr 2001 19:08:32 +0200 (CEST)
> From: Wolfgang Helbig <helbig(a)Informatik.BA-Stuttgart.DE>
> Sender: owner-pups(a)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(a)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@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(a)minnie.cs.adfa.edu.au)
>From Markus E Leypold <leypold(a)informatik.uni-tuebingen.de> Tue Apr 17 21:53:23 2001
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(a)minnie.cs.adfa.edu.au>; Tue, 17 Apr 2001 22:02:12 +1000 (EST)
(envelope-from leypold(a)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@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(a)neuromancer.informatik.uni-tuebingen.de>
X-Authentication-Warning: neuromancer.informatik.uni-tuebingen.de: leypold set sender to leypold(a)informatik.uni-tuebingen.de using -f
From: Markus E Leypold <leypold(a)informatik.uni-tuebingen.de>
To: iking(a)microsoft.com
Cc: helbig(a)Informatik.BA-Stuttgart.DE, kwellsch(a)tampabay.rr.com,
pups(a)minnie.cs.adfa.edu.au
In-reply-to:
<8D25F244B8274141B5D313CA4823F39C0235D23D(a)red-msg-06.redmond.corp.microsoft.com>
(iking(a)microsoft.com)
Subject: Re: [pups] Ken_Welsch_v6 and Dennis_v6
References: <8D25F244B8274141B5D313CA4823F39C0235D23D(a)red-msg-06.redmond.corp.microsoft.com>
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
> Delivered-To: leypold(a)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(a)microsoft.com>
> Cc: <pups(a)minnie.cs.adfa.edu.au>
> Sender: owner-pups(a)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@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(a)minnie.cs.adfa.edu.au)
>From Edward Brocklesby <ejb(a)leguin.org.uk> Wed Apr 18 02:06:34 2001
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(a)minnie.cs.adfa.edu.au>; Wed, 18 Apr 2001 02:15:15 +1000 (EST)
(envelope-from ejb(a)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(a)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(a)leguin.org.uk>
Organization: Leguin Network Services
To: pups(a)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(a)klamath.leguin.org.uk>
Content-Transfer-Encoding: 8bit
Sender: owner-pups(a)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-
On 17 Apr, Edward Brocklesby wrote:
> 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..
[...]
> the problem seems to be with packets arriving and being processed out of
> order..
I had exactely the same problem on my 11/73 with a DELQA running
2.11BSD. I noticed this after I reconfigured the qe0 interface and the
routes while the system was up and running. It disapeared after I had
to powercycle the machine for other reasons.
--
tschüß,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
Received: (from major@localhost)
by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id IAA40135
for pups-liszt; Wed, 18 Apr 2001 08:30:41 +1000 (EST)
(envelope-from owner-pups(a)minnie.cs.adfa.edu.au)
>From Edward Brocklesby <ejb(a)leguin.org.uk> Wed Apr 18 08:21:47 2001
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 IAA40123
for <pups(a)minnie.cs.adfa.edu.au>; Wed, 18 Apr 2001 08:30:36 +1000 (EST)
(envelope-from ejb(a)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 WAA25491;
Tue, 17 Apr 2001 22:21:49 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(a)leguin.org.uk>
Organization: Leguin Network Services
To: jkunz(a)unixag-kl.fh-kl.de
Subject: Re: [pups] very strange problems with 2.11BSD tcp/ip stack
Date: Tue, 17 Apr 2001 22:21:47 +0000
X-Mailer: KMail [version 1.2]
Cc: pups(a)minnie.cs.adfa.edu.au
References: <200104172132.XAA27697(a)unixag-kl.fh-kl.de>
In-Reply-To: <200104172132.XAA27697(a)unixag-kl.fh-kl.de>
MIME-Version: 1.0
Message-Id: <0104172221470N.00508(a)klamath.leguin.org.uk>
Content-Transfer-Encoding: 8bit
Sender: owner-pups(a)minnie.cs.adfa.edu.au
Precedence: bulk
On Tuesday 17 April 2001 9:32 pm, jkunz(a)unixag-kl.fh-kl.de wrote:
> I had exactely the same problem on my 11/73 with a DELQA running
> 2.11BSD. I noticed this after I reconfigured the qe0 interface and the
> routes while the system was up and running. It disapeared after I had
> to powercycle the machine for other reasons.
Yeah, that's probably the problem.. I was fiddling with the routes (changing
the IP and subnet) just before it started.. after a reboot it seems fine.
-larne-
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
over to an RK05 (using Warren's excellent tools) to boot on the 11/34.
-- Ian
-----Original Message-----
From: Wolfgang Helbig [mailto:helbig@Informatik.BA-Stuttgart.DE]
Sent: Saturday, April 14, 2001 11:49 AM
To: helbig(a)Informatik.BA-Stuttgart.DE; kwellsch(a)tampabay.rr.com
Cc: pups(a)minnie.cs.adfa.edu.au
Subject: Re: [pups] Ken_Welsch_v6 and Dennis_v6
> I always wondered why when booting the image it did not print the
> notice so often displayed with V6. I've not looked at the physical
> tape this image was pulled from in many years, but I cannot imagine
> the fine folks at the University of Waterloo (where I worked for many
> years) would have changed anything. So I would gather from your
> detective work that based on dates, this tape just predates that
> provided by Dennis Richie by such a short time? I do know
No, the other way round: The tape you provided is from October 10th and
the disk image provided by Dennis is from July 18th. The "RESTRICED
RIGHT"- remark was put into the kernel on October 10th. It is on the
tape that you provided, it is not on the disk image from Dennis. But
the source code from the Lions book shows this remark as well.
I don't know who changed main.c on October 10th 1975 (I lived in Israel
at that time)
You see the remark only if you set the switch register on the PDP-11 to
a nonzero value befor booting. I installed V6 from the tape following
the setup instructions. With the Supnik simulator, enter
sim > d sr 1
sim > boot rk0
@rkunix
And it will print your rights!
Wolfgang
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?
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(a)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.
