From jnc at mercury.lcs.mit.edu  Sun Feb  8 04:53:27 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat,  7 Feb 2015 13:53:27 -0500 (EST)
Subject: [TUHS] Version 5 Manual
Message-ID: <20150207185327.DDF7F18C0B9@mercury.lcs.mit.edu>

So, I have a chance to buy a copy of a Version 5 manual, but it will be a
lot. I looked, and the Version 5 manual doesn't appear to be online. So while
normally at the price this is at, I would pass, it might be worth it for me
to buy it, and scan it to make it available.

But, I looked in the "FAQ on the Unix Archive and Unix on the PDP-11", and it
says:

  5th Edition has its on-line manual pages missing. ... Fortunately, we do
  have paper copies of all the research editions of UNIX from 1st to 7th
  Edition, and these will be scanned in and OCR'd.

Several questions: First, when it says "we do have paper copies of all the
research editions of UNIX", I assume it means 'we do have paper copies of
_the manuals for_ all the research editions of UNIX', not 'we do have paper
copies of _the source code for_ all the research editions of UNIX'?

Second, if it is 'manuals', did the scan/OCR thing ever happen, or is it
likely to anytime in the moderate future (next couple of years)?

Third, would a scanned (which I guess we could OCR) version of this manual be
of much use (it would not, after all, be the NROFF source, although probably
a lot of the commands will be identical to the V6 ones, for which we do have
the NROFF)?

Advice, please? Thanks!

	Noel


From wkt at tuhs.org  Sun Feb  8 08:01:45 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 08 Feb 2015 08:01:45 +1000
Subject: [TUHS] Version 5 Manual
In-Reply-To: <20150207185327.DDF7F18C0B9@mercury.lcs.mit.edu>
References: <20150207185327.DDF7F18C0B9@mercury.lcs.mit.edu>
Message-ID: <88A6F964-B664-41AB-B568-F1FE904C41D5@tuhs.org>

Noel, in http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v5/ you will find a PDF scan on the v5 manuals. Many thanks to Norman Wilson who sent me a photocopy set.

Cheers, Warren

On 8 February 2015 04:53:27 AEST, jnc at mercury.lcs.mit.edu wrote:
>So, I have a chance to buy a copy of a Version 5 manual, but it will be
>a
>lot. I looked, and the Version 5 manual doesn't appear to be online. So
>while
>normally at the price this is at, I would pass, it might be worth it
>for me
>to buy it, and scan it to make it available.
>
>But, I looked in the "FAQ on the Unix Archive and Unix on the PDP-11",
>and it
>says:
>
>5th Edition has its on-line manual pages missing. ... Fortunately, we
>do
> have paper copies of all the research editions of UNIX from 1st to 7th
>  Edition, and these will be scanned in and OCR'd.
>
>Several questions: First, when it says "we do have paper copies of all
>the
>research editions of UNIX", I assume it means 'we do have paper copies
>of
>_the manuals for_ all the research editions of UNIX', not 'we do have
>paper
>copies of _the source code for_ all the research editions of UNIX'?
>
>Second, if it is 'manuals', did the scan/OCR thing ever happen, or is
>it
>likely to anytime in the moderate future (next couple of years)?
>
>Third, would a scanned (which I guess we could OCR) version of this
>manual be
>of much use (it would not, after all, be the NROFF source, although
>probably
>a lot of the commands will be identical to the V6 ones, for which we do
>have
>the NROFF)?
>
>Advice, please? Thanks!
>
>	Noel
>_______________________________________________
>TUHS mailing list
>TUHS at minnie.tuhs.org
>https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150208/4db63162/attachment.html>

From cubexyz at gmail.com  Sun Feb  8 15:13:01 2015
From: cubexyz at gmail.com (Mark Longridge)
Date: Sun, 8 Feb 2015 00:13:01 -0500
Subject: [TUHS] Version 5 Manual
In-Reply-To: <88A6F964-B664-41AB-B568-F1FE904C41D5@tuhs.org>
References: <20150207185327.DDF7F18C0B9@mercury.lcs.mit.edu>
 <88A6F964-B664-41AB-B568-F1FE904C41D5@tuhs.org>
Message-ID: <CADxT5N7tbapq-7s9m-6T=awcKe5Sqgf=frG72fGKA43yciJetQ@mail.gmail.com>

On 2/7/15, Warren Toomey <wkt at tuhs.org> wrote:
> Noel, in
> http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v5/ you
> will find a PDF scan on the v5 manuals. Many thanks to Norman Wilson who
> sent me a photocopy set.
>
> Cheers, Warren
>
> On 8 February 2015 04:53:27 AEST, jnc at mercury.lcs.mit.edu wrote:
>>So, I have a chance to buy a copy of a Version 5 manual, but it will be
>>a
>>lot. I looked, and the Version 5 manual doesn't appear to be online. So
>>while
>>normally at the price this is at, I would pass, it might be worth it
>>for me
>>to buy it, and scan it to make it available.
>>
>>But, I looked in the "FAQ on the Unix Archive and Unix on the PDP-11",
>>and it
>>says:
>>
>>5th Edition has its on-line manual pages missing. ... Fortunately, we
>>do
>> have paper copies of all the research editions of UNIX from 1st to 7th
>>  Edition, and these will be scanned in and OCR'd.
>>
>>Several questions: First, when it says "we do have paper copies of all
>>the
>>research editions of UNIX", I assume it means 'we do have paper copies
>>of
>>_the manuals for_ all the research editions of UNIX', not 'we do have
>>paper
>>copies of _the source code for_ all the research editions of UNIX'?
>>
>>Second, if it is 'manuals', did the scan/OCR thing ever happen, or is
>>it
>>likely to anytime in the moderate future (next couple of years)?
>>
>>Third, would a scanned (which I guess we could OCR) version of this
>>manual be
>>of much use (it would not, after all, be the NROFF source, although
>>probably
>>a lot of the commands will be identical to the V6 ones, for which we do
>>have
>>the NROFF)?
>>
>>Advice, please? Thanks!
>>
>>	Noel

Hi Folks,

I thought everybody already knew about the v5 manual, I've known about
it for quite some time now.

The pdf file I have (which I assume is the same as the one mentioned
here) is already OCRed. I've been working on recreating the man pages
for v5 by matching the date codes from v6. If the dates match and the
contents of the files match I just copy over the v6 version into v5.
Sometimes I even use the v4 version if it differs from v6 but matches
the v5 manual. In the worst case scenario there's enough information
to retype a man page from scratch. I also used the v6 man page script
in v5 and that does the job.

There's not much room in the rk05 image so I created two more rk05
images and split up everything so there's some room for everything. I
was going to submit all 3 disk images once I was happy with all the
modifications. I've made a bunch of improvements to the baseline
version contained in uv5swre.zip .

There's a few things missing from v5:

The source code for yacc, sno, chess and crpost is missing. Also the
chess opening book is missing.
Also missing is mboot.s and alloc.s

I consider my work on v5 to be incomplete but there's a lot of
interesting stuff added so far. Some of the missing stuff can be
filled in from v6, it compiles OK. I can send a tarball to archive.org
or tuhs if you folks want to see the work done so far.

Mark


From jacob.ritorto at gmail.com  Sun Feb  8 16:22:06 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Sun, 8 Feb 2015 01:22:06 -0500
Subject: [TUHS] mkfs somewhere else?
Message-ID: <CAHYQbfBg-EVfNDhC67PF4N5zz6mmx2Ka6nXN7igfh1L7yijNhQ@mail.gmail.com>

Hi,
  I'm running 2.9BSD on a pdp11/34 with an Emulex sc21 controller to some
Fuji160 disks.  Booting with root on RL02 for now, but want to eventually
have the whole system on the Fujis and disconnect the rl02s.

  While the previous owner of the disks appears to have suffered a
headcrash near cylinder 0, I'm having an impressive degree of success
writing to other parts of the disk.

  However, when I try to mkfs, I can see the heads trying to write on the
headcrashed part of the disk.  (Nice having those plexiglass covers!)

  Is there a way to tell mkfs (or perhaps some other program) to not try to
write on the damaged cylinders?

thx
jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150208/a14bfdd3/attachment.html>

From dave at horsfall.org  Sun Feb  8 16:36:08 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 8 Feb 2015 17:36:08 +1100 (EST)
Subject: [TUHS] mkfs somewhere else?
In-Reply-To: <CAHYQbfBg-EVfNDhC67PF4N5zz6mmx2Ka6nXN7igfh1L7yijNhQ@mail.gmail.com>
References: <CAHYQbfBg-EVfNDhC67PF4N5zz6mmx2Ka6nXN7igfh1L7yijNhQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.11.1502081733480.3148@aneurin.horsfall.org>

On Sun, 8 Feb 2015, Jacob Ritorto wrote:

> However, when I try to mkfs, I can see the heads trying to write on the 
> headcrashed part of the disk.  (Nice having those plexiglass covers!)
> 
> Is there a way to tell mkfs (or perhaps some other program) to not try 
> to write on the damaged cylinders?

Modify the driver itself?

I also wrote a paper on a "bad block" system, where something like inum 
"-1" contained the list of bad sectors, but never saw it through.

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

From jacob.ritorto at gmail.com  Sun Feb  8 17:03:51 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Sun, 8 Feb 2015 02:03:51 -0500
Subject: [TUHS] mkfs somewhere else?
In-Reply-To: <alpine.BSF.2.11.1502081733480.3148@aneurin.horsfall.org>
References: <CAHYQbfBg-EVfNDhC67PF4N5zz6mmx2Ka6nXN7igfh1L7yijNhQ@mail.gmail.com>
 <alpine.BSF.2.11.1502081733480.3148@aneurin.horsfall.org>
Message-ID: <CAHYQbfDx=8PfQ3noy=Rnjyhsrs=y=7Tzuv4eSrgTvgdNR+ZGLA@mail.gmail.com>

what about using another minor device?  Is xp0d mapped elsewhere?

On Sun, Feb 8, 2015 at 1:36 AM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sun, 8 Feb 2015, Jacob Ritorto wrote:
>
> > However, when I try to mkfs, I can see the heads trying to write on the
> > headcrashed part of the disk.  (Nice having those plexiglass covers!)
> >
> > Is there a way to tell mkfs (or perhaps some other program) to not try
> > to write on the damaged cylinders?
>
> Modify the driver itself?
>
> I also wrote a paper on a "bad block" system, where something like inum
> "-1" contained the list of bad sectors, but never saw it through.
>
> --
> Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
> http://www.horsfall.org/spam.html (and check the home page whilst you're
> there)
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150208/e1507360/attachment.html>

From jacob.ritorto at gmail.com  Sun Feb  8 17:15:31 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Sun, 8 Feb 2015 02:15:31 -0500
Subject: [TUHS] mkfs somewhere else?
In-Reply-To: <CAHYQbfDx=8PfQ3noy=Rnjyhsrs=y=7Tzuv4eSrgTvgdNR+ZGLA@mail.gmail.com>
References: <CAHYQbfBg-EVfNDhC67PF4N5zz6mmx2Ka6nXN7igfh1L7yijNhQ@mail.gmail.com>
 <alpine.BSF.2.11.1502081733480.3148@aneurin.horsfall.org>
 <CAHYQbfDx=8PfQ3noy=Rnjyhsrs=y=7Tzuv4eSrgTvgdNR+ZGLA@mail.gmail.com>
Message-ID: <CAHYQbfDWzsSvTHayVgbr68hXCB1TWOfs44po6Zb-=SKfZs33tg@mail.gmail.com>

Would anyone know if it's still possible to just replace the platters and
clean the heads? This drive is really nice, but the headcrash really needs
to be dealt with.  Are there any more fuji160-compatible platters on
earth?  If so, is there a way to install them to the existing hubs straight
enough that there's acceptable runout?

-j

On Sun, Feb 8, 2015 at 2:03 AM, Jacob Ritorto <jacob.ritorto at gmail.com>
wrote:

> what about using another minor device?  Is xp0d mapped elsewhere?
>
> On Sun, Feb 8, 2015 at 1:36 AM, Dave Horsfall <dave at horsfall.org> wrote:
>
>> On Sun, 8 Feb 2015, Jacob Ritorto wrote:
>>
>> > However, when I try to mkfs, I can see the heads trying to write on the
>> > headcrashed part of the disk.  (Nice having those plexiglass covers!)
>> >
>> > Is there a way to tell mkfs (or perhaps some other program) to not try
>> > to write on the damaged cylinders?
>>
>> Modify the driver itself?
>>
>> I also wrote a paper on a "bad block" system, where something like inum
>> "-1" contained the list of bad sectors, but never saw it through.
>>
>> --
>> Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
>> http://www.horsfall.org/spam.html (and check the home page whilst you're
>> there)
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150208/523818ca/attachment.html>

From dave at horsfall.org  Mon Feb  9 03:34:29 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 9 Feb 2015 04:34:29 +1100 (EST)
Subject: [TUHS] mkfs somewhere else?
In-Reply-To: <CAHYQbfDWzsSvTHayVgbr68hXCB1TWOfs44po6Zb-=SKfZs33tg@mail.gmail.com>
References: <CAHYQbfBg-EVfNDhC67PF4N5zz6mmx2Ka6nXN7igfh1L7yijNhQ@mail.gmail.com>
 <alpine.BSF.2.11.1502081733480.3148@aneurin.horsfall.org>
 <CAHYQbfDx=8PfQ3noy=Rnjyhsrs=y=7Tzuv4eSrgTvgdNR+ZGLA@mail.gmail.com>
 <CAHYQbfDWzsSvTHayVgbr68hXCB1TWOfs44po6Zb-=SKfZs33tg@mail.gmail.com>
Message-ID: <alpine.BSF.2.11.1502090430390.3148@aneurin.horsfall.org>

On Sun, 8 Feb 2015, Jacob Ritorto wrote:

> what about using another minor device?  Is xp0d mapped elsewhere?

Dunno.


On Sun, 8 Feb 2015, Jacob Ritorto wrote:

> Would anyone know if it's still possible to just replace the platters 
> and clean the heads? This drive is really nice, but the headcrash really 
> needs to be dealt with.  Are there any more fuji160-compatible platters 
> on earth?  If so, is there a way to install them to the existing hubs 
> straight enough that there's acceptable runout?

Keep in mind that crashed disk => damaged head => more crashed disks => 
more crashed heads...

It's amazing, in a weird sort of way, just how rapidly a disk-crash 
infection can spread :-(

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From jacob.ritorto at gmail.com  Mon Feb  9 04:52:02 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Sun, 8 Feb 2015 13:52:02 -0500
Subject: [TUHS] mkfs somewhere else?
In-Reply-To: <alpine.BSF.2.11.1502090430390.3148@aneurin.horsfall.org>
References: <CAHYQbfBg-EVfNDhC67PF4N5zz6mmx2Ka6nXN7igfh1L7yijNhQ@mail.gmail.com>
 <alpine.BSF.2.11.1502081733480.3148@aneurin.horsfall.org>
 <CAHYQbfDx=8PfQ3noy=Rnjyhsrs=y=7Tzuv4eSrgTvgdNR+ZGLA@mail.gmail.com>
 <CAHYQbfDWzsSvTHayVgbr68hXCB1TWOfs44po6Zb-=SKfZs33tg@mail.gmail.com>
 <alpine.BSF.2.11.1502090430390.3148@aneurin.horsfall.org>
Message-ID: <CAHYQbfCxcA9rhuhF8tXFiBD1YiR+KD8faxBUREJ5cNv0LHBewQ@mail.gmail.com>

So I managed to find the man page (thanks to the FreeBSD people!) for
2.9BSD's xp driver.  It clued me in that xp0e is further up the disk.
Tried to mkfs that and am getting intermittent chunks of good and bad.  So
I guess life's over for this guy.  So sad because other than the headcrash,
the thing is in immaculate, perfect working condition!  Maybe it could
become a spinning (and mildly horrifying) display inside a coffee table or
something.

On Sun, Feb 8, 2015 at 12:34 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sun, 8 Feb 2015, Jacob Ritorto wrote:
>
> > what about using another minor device?  Is xp0d mapped elsewhere?
>
> Dunno.
>
>
> On Sun, 8 Feb 2015, Jacob Ritorto wrote:
>
> > Would anyone know if it's still possible to just replace the platters
> > and clean the heads? This drive is really nice, but the headcrash really
> > needs to be dealt with.  Are there any more fuji160-compatible platters
> > on earth?  If so, is there a way to install them to the existing hubs
> > straight enough that there's acceptable runout?
>
> Keep in mind that crashed disk => damaged head => more crashed disks =>
> more crashed heads...
>
> It's amazing, in a weird sort of way, just how rapidly a disk-crash
> infection can spread :-(
>
> --
> Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
> http://www.horsfall.org/spam.html (and check the home page whilst you're
> there)
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150208/b983734f/attachment.html>

From jacob.ritorto at gmail.com  Mon Feb  9 05:28:22 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Sun, 8 Feb 2015 14:28:22 -0500
Subject: [TUHS] 2.9BSD on an actual rl02 - swap confusion
Message-ID: <CAHYQbfCD+9CXePzxPhg4adhXfOXKHVQ51mEd8ngLBk6BO_7T8g@mail.gmail.com>

Hi,
  I'm having trouble understanding how to get my swap configured.  Since
rl02s are so little, the MAKE file in /dev doesn't partition them into a,
b, c, etc.  However, when MAKE makes the /dev/rl0 device, it uses only 8500
of its 10000 blocks, so what would presumably be intended as swap space
does exist.  Swap is usually linked to the b partition, right?  So how do I
create this b partition on an rl02?  Or am I getting this horribly wrong?

thx
jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150208/e62b7e99/attachment.html>

From norman at oclsc.org  Mon Feb  9 06:10:58 2015
From: norman at oclsc.org (Norman Wilson)
Date: Sun,  8 Feb 2015 15:10:58 -0500 (EST)
Subject: [TUHS] mkfs somewhere else?
Message-ID: <20150208201058.488D51DE414@lignose.oclsc.org>

  Would anyone know if it's still possible to just replace the platters and
  clean the heads?

If the heads are really crashed, the only safe course is
to replace both the damaged heads and the damaged disk pack.
Anything else admits a substantial risk of carrying the
crash forward.

Cleaning the heads probably isn't an option; when they
crash, they don't just pick up material from the disk
platter, they may themselves be damaged enough that sharp
bits of the heads themselves are sticking out.

Norman Wilson
Toronto ON


From norman at oclsc.org  Mon Feb  9 06:12:07 2015
From: norman at oclsc.org (Norman Wilson)
Date: Sun,  8 Feb 2015 15:12:07 -0500 (EST)
Subject: [TUHS] mkfs somewhere else?
Message-ID: <20150208201207.F3B411DE414@lignose.oclsc.org>

  what about using another minor device?  Is xp0d mapped elsewhere?

Since it's a BSD, won't it try by default to read a partition
table from the first few sectors of the disk?

Norman Wilson
Toronto ON


From norman at oclsc.org  Mon Feb  9 06:20:35 2015
From: norman at oclsc.org (Norman Wilson)
Date: Sun,  8 Feb 2015 15:20:35 -0500 (EST)
Subject: [TUHS] mkfs somewhere else?
Message-ID: <20150208202035.E3D391DE414@lignose.oclsc.org>

Dave Horsfall:

  I also wrote a paper on a "bad block" system, where something like inum
  "-1" contained the list of bad sectors, but never saw it through.

====

During the file system change from V6 to V7, the i-number of
the root changed from 1 to 2, and i-node 1 became unused.
At least some versions of the documentation (I am too harried
to look it up at the moment) claimed i-node 1 was reserved
for holding bad blocks, to keep them out of the free list,
but that the whole thing was unimplemented.

I vaguely remember implementing that at some point: writing
a tool to add named sectors to i-node 1.  Other tools needed
fixing too, though: dump, I think, still treated i-node 1
as an ordinary file, and tried to dump the contents of
all the bad blocks, more or less defeating the purpose.

I left all that behind when I moved to systems with MSCP disks,
having written my own driver code that implemented DEC's
intended port/class driver split, en passant learning how
to inform the disk itself of a bad block so it would hide it
from the host.

I'd write more but I need to go down to the basement and look
at one of my modern* 3TB SATA disks, which is misbehaving
even though modern disks are supposed to be so much better ...

Norman Wilson
Toronto ON

* Not packaged in brass-bound leather like we had in the old days.
You can't get the wood, you know.


From jnc at mercury.lcs.mit.edu  Mon Feb  9 06:42:07 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  8 Feb 2015 15:42:07 -0500 (EST)
Subject: [TUHS] 2.9BSD on an actual rl02 - swap confusion
Message-ID: <20150208204207.7860218C0BE@mercury.lcs.mit.edu>

    > From: Jacob Ritorto

    > I'm having trouble understanding how to get my swap configured. Since
    > rl02s are so little, the MAKE file in /dev doesn't partition them into
    > a, b, c, etc. However, when MAKE makes the /dev/rl0 device, it uses
    > only 8500 of its 10000 blocks, so what would presumably be intended as
    > swap space does exist. Swap is usually linked to the b partition,
    > right? So how do I create this b partition on an rl02?

I don't know how the later systems work, but in V6, the swap device, and the
start block / # of blocks are specified in the c.c configuration file (i.e.
they are compiled into the system). So you can take one partition, and by
specifying less than the full size to 'mkfs', you can use the end of the
partition for swap space (which is presumably what's happening with /dev/rl0
here).

	Noel


From jacob.ritorto at gmail.com  Mon Feb  9 06:52:20 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Sun, 8 Feb 2015 15:52:20 -0500
Subject: [TUHS] 2.9BSD on an actual rl02 - swap confusion
In-Reply-To: <20150208204207.7860218C0BE@mercury.lcs.mit.edu>
References: <20150208204207.7860218C0BE@mercury.lcs.mit.edu>
Message-ID: <CAHYQbfDb33-2z1=r=G_gkgwePK-wL+BuGVDEgDGYtfFubZopNQ@mail.gmail.com>

Hey, thanks Guys!  Ok, good that the kernel already knows about it.

  The actual problem I'm having is that ps doesn't work.

  I assume it tries to look at /dev/swap as its pointer, but since there's
no /dev/rl0a, dev/swap has nothing reasonable to point to, so ps fails with
/dev/swap: no such device (iirc).

  Was thinking of experimentally linking /dev/swap to rl0 but logic
dictates that would trash the root filesystem (which is nbd since I can
easily restore the 2.9 rl02 root from the archives with Warren's vtserver!)

Gonna go read some source.  Thanks!

jake



On Sun, Feb 8, 2015 at 3:42 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Jacob Ritorto
>
>     > I'm having trouble understanding how to get my swap configured. Since
>     > rl02s are so little, the MAKE file in /dev doesn't partition them
> into
>     > a, b, c, etc. However, when MAKE makes the /dev/rl0 device, it uses
>     > only 8500 of its 10000 blocks, so what would presumably be intended
> as
>     > swap space does exist. Swap is usually linked to the b partition,
>     > right? So how do I create this b partition on an rl02?
>
> I don't know how the later systems work, but in V6, the swap device, and
> the
> start block / # of blocks are specified in the c.c configuration file (i.e.
> they are compiled into the system). So you can take one partition, and by
> specifying less than the full size to 'mkfs', you can use the end of the
> partition for swap space (which is presumably what's happening with
> /dev/rl0
> here).
>
>         Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150208/542acca4/attachment.html>

From clemc at ccc.com  Mon Feb  9 08:03:17 2015
From: clemc at ccc.com (Clem Cole)
Date: Sun, 8 Feb 2015 17:03:17 -0500
Subject: [TUHS] 2.9BSD on an actual rl02 - swap confusion
In-Reply-To: <20150208204207.7860218C0BE@mercury.lcs.mit.edu>
References: <20150208204207.7860218C0BE@mercury.lcs.mit.edu>
Message-ID: <CAC20D2Mqf-c=DFMqRNZwxAEucZVpfwnTNJq8eo+ACWOm-NhRMQ@mail.gmail.com>

On Sun, Feb 8, 2015 at 3:42 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> I don't know how the later systems work, but in V6, the swap device, and
> the
> start block / # of blocks are specified in the c.c configuration file (i.e.
> they are compiled into the system). So you can take one partition, and by
> specifying less than the full size to 'mkfs', you can use the end of the
> partition for swap space (which is presumably what's happening with
> /dev/rl0
> here).
>
​Ah Noel - Thanks for the refresher course.   That's right.  I now remember
it.  I knew it was compiled into the kernel but I had forgotten the details.

It was not until much later that the swap image became less screwed
down/more reflexible.   You first needed to get to larger disks (rp05/rp06)
which had to be partitioned because they overflowed a 16 bit integer​.
Once people started to partition them, then all sort of new things occurred
and I that's when the idea of a dedicated swap partition came up.   I've
forgotten if that was a BSDism or UNIX/TS.   Certainly by the time of Sam's
4.1A?? configuration tool that created conf.c and low.s it had already been
in for a while.

As I recall in V6 and I think V7, the process was first placed in the swap
image before the exec (or at least space reserved for it).   So you had to
have a swap space to boot because to fork the "init" it needed to assigned
to the swap space (chick/egg issue). When demand support was added to the
kernel, the process did not have to have that requirement, so it meant swap
set up could be a post initial program load operation for the start
sequence.

Clem


Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150208/72b8c8bf/attachment.html>

From ron at ronnatalie.com  Mon Feb  9 08:09:52 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 8 Feb 2015 17:09:52 -0500
Subject: [TUHS] 2.9BSD on an actual rl02 - swap confusion
In-Reply-To: <CAC20D2Mqf-c=DFMqRNZwxAEucZVpfwnTNJq8eo+ACWOm-NhRMQ@mail.gmail.com>
References: <20150208204207.7860218C0BE@mercury.lcs.mit.edu>
 <CAC20D2Mqf-c=DFMqRNZwxAEucZVpfwnTNJq8eo+ACWOm-NhRMQ@mail.gmail.com>
Message-ID: <CE82AB0B-31B1-4D2C-BBC6-6AFF72AD20AF@ronnatalie.com>

Yep, certain of the smaller drives like RK05’s had no way of “partitioning them.”   So you needed the swapstart to put it at the end of the volume.
Even before we got large drives, we put our swap on it’s own fixed head disk (RS-11).    Actually, in retrospect it probably would have been better to put temp there rather than swap, but it seemed to be a good idea at the time.    Later we got the bulk core boxes that emulated the fixed head disks and did put temp there.



From jnc at mercury.lcs.mit.edu  Mon Feb  9 08:42:09 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  8 Feb 2015 17:42:09 -0500 (EST)
Subject: [TUHS] 2.9BSD on an actual rl02 - swap confusion
Message-ID: <20150208224209.6AB7718C0BE@mercury.lcs.mit.edu>

    > From: Clem Cole <clemc at ccc.com>

    > Once people started to partition them, then all sort of new things
    > occurred and I that's when the idea of a dedicated swap partition came
    > up. I've forgotten if that was a BSDism or UNIX/TS.

Well, vanilla V6 had i) partitioned drives (that was the only way to support
an RP03), and ii) the swap device in the c.c config file. That's all you need
to put swap in its own partition. (One of the other MIT-LCS groups with V6
did that; we didn't, because it was better to swap off the RK, which did
multi-block transfers in a single I/O operation.)

    > As I recall in V6 and I think V7, the process was first placed in the
    > swap image before the exec (or at least space reserved for it).

As best I understand it, the way fork worked in V6 was that if there was not
enough memory for an in-core fork (in which case the entire memory of the
process was just copied), the process was 'swapped out', and the swapped out
image assumed the identity of the child.

But this is kind of confusing, because when I was bringing up V6 under the
Ersatz11 simulator, I had a problem where the swapper (process 0) was trying
to fork (with the child becoming 1 and running /etc/init), and it did the
'swap out' thing. But there was a ton of free memory at that point, so... why
was it doing a swap? Eh, something to investigate sometime...

	Noel


From clemc at ccc.com  Mon Feb  9 09:45:35 2015
From: clemc at ccc.com (Clem Cole)
Date: Sun, 8 Feb 2015 18:45:35 -0500
Subject: [TUHS] 2.9BSD on an actual rl02 - swap confusion
In-Reply-To: <20150208224209.6AB7718C0BE@mercury.lcs.mit.edu>
References: <20150208224209.6AB7718C0BE@mercury.lcs.mit.edu>
Message-ID: <CAC20D2OZo9FaNfr8CkehuTBK3VaGg723KTgohTF01=pezA6vOw@mail.gmail.com>

On Sun, Feb 8, 2015 at 5:42 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> But this is kind of confusing, because when I was bringing up V6 under the
> Ersatz11 simulator, I had a problem where the swapper (process 0) was
> trying
> to fork (with the child becoming 1 and running /etc/init), and it did the
> 'swap out' thing. But there was a ton of free memory at that point, so...
> why
> was it doing a swap? Eh, something to investigate sometime...
>

​I'm relying on very old memory here ...  but my memory is that before
either fork or exec or maybe both (I forget all of this and don't have the
code on my laptop to check) the kernel did something in the swap area/maps.
  It may have been just preallocate the data area for the process.  ​But if
there was not enough space/got an error of some type, the system call
failed.

What this meant was the even if you has free ram, you had to have a working
swap device very early in the start up.   I wish I could remember those
details - hard to believe I spent so many hours (of fun) hacking on the
kernel of those systems ;-)



Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150208/d0aa6d3a/attachment.html>

From cubexyz at gmail.com  Mon Feb  9 18:45:51 2015
From: cubexyz at gmail.com (Mark Longridge)
Date: Mon, 9 Feb 2015 03:45:51 -0500
Subject: [TUHS] augmented unix v5
Message-ID: <CADxT5N5QEUa6Ktvf9R7kd0JzJC-9mGK_XiwYsA=bV=avqvKmng@mail.gmail.com>

Ok folks,

I've uploaded what I call Unix v5a to:

http://www.maxhost.org/other/unix-v5-feb-2015.tar.gz

I use simh on Linux to emulate the PDP-11/70.

The tarball contains:

unix_v5_rk.dsk
unix_v5_rk1.dsk
unix_v5_rk2.dsk
pdp11-v5.ini
readme-v5.txt
unix-v5a.sh

The original file is uv5swre.zip if anyone wants to compare them.

Mark


From asbesto at freaknet.org  Wed Feb 11 22:01:35 2015
From: asbesto at freaknet.org (asbesto)
Date: Wed, 11 Feb 2015 12:01:35 +0000
Subject: [TUHS] OS COSMOS, russian UNIX emulated system now online :)
Message-ID: <20150211120135.GA31944@freaknet.org>


Hi there,

we just added OS DEMOS (ÐÐ¡ ÐÐÐÐÐ¡), a Russian BSD clone, to our emulated 
systems online here:

telnet museo.mooo.com 

login: pdp11, password: pdp11

:)


-- 
[ ::::::::: 73 de IW9HGS : http://freaknet.org/asbesto ::::::::::: ]
[ Freaknet Medialab :: Poetry Hacklab : Dyne.Org :: Radio Cybernet ]
[ NON SCRIVERMI USANDO LETTERE ACCENTATE  -  NON MANDARMI ALLEGATI ]
[ *I DELETE* EMAIL > 100K, ATTACHMENTS, HTML, M$-WORD DOC and SPAM ]



From asbesto at freaknet.org  Wed Feb 11 23:33:45 2015
From: asbesto at freaknet.org (asbesto)
Date: Wed, 11 Feb 2015 13:33:45 +0000
Subject: [TUHS] OS DEMOS, russian UNIX emulated system now online :)
In-Reply-To: <20150211120135.GA31944@freaknet.org>
References: <20150211120135.GA31944@freaknet.org>
Message-ID: <20150211133345.GA3665@freaknet.org>

Wed, Feb 11, 2015 at 12:01:35PM +0000, asbesto wrote:

> we just added OS DEMOS (ÐÐ¡ ÐÐÐÐÐ¡), a Russian BSD clone, to our emulated 
> systems online here:

ehm. DEMOS, in the subj :) sorry for the typo :)

-- 
[ ::::::::: 73 de IW9HGS : http://freaknet.org/asbesto ::::::::::: ]
[ Freaknet Medialab :: Poetry Hacklab : Dyne.Org :: Radio Cybernet ]
[ NON SCRIVERMI USANDO LETTERE ACCENTATE  -  NON MANDARMI ALLEGATI ]
[ *I DELETE* EMAIL > 100K, ATTACHMENTS, HTML, M$-WORD DOC and SPAM ]



From jacob.ritorto at gmail.com  Thu Feb 12 01:47:05 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 11 Feb 2015 10:47:05 -0500
Subject: [TUHS] 2.9 kernel compile
Message-ID: <CAHYQbfCrwikSJeuWuqRPi4B4kNKyJV6Jtwdb0srcG7UY4YvwKA@mail.gmail.com>

Hi,
  Since my Fuji160 drive is rather head-crashed, I've replaced it with an
M2333k, which is a smaller SMD rig with more sectors than the 160.
Unfortunately, after many dip switch settings and config changes, I have to
conclude that the sc21 just doesn't work with this new disk.

  I've plugged in my SC41 controller that speaks MSCP and supports the
M2333k correctly.  So now it's a matter of getting a unix small enough to
run on the 11/34 that can also speak MSCP.  Enter Jonathan Engdahl's
2.9bsd-MSCP.

  I managed to restor a root dump from his distribution and am able to
occasionally boot it on my 11/34, but it crashes very soon after booting
and I don't understand why. I think it's something to do with the fact that
he compiled it to run on an 11/23. Maybe it lacks unibus support. Maybe
something to do with clock differences. Not sure. But I was thinking that I
could make it work by recompiling the kernel with 11/34 support.

I fired 2.9MSCP up in simh emulating an 11/23 and it works fine. Just to
corroborate my hardware experience of it on the '34, I switch the cpu
emulation to 11/34 and got a mostly identical crash sequence as with my
real hardware.

  So I switched the emulation back to '23, rebooted and edited the assym.s
file found in Jonathan's /usr/src/sys/RA directory. I changed
PDP11 = 23.
to
PDP11 = 34.

as well as

UNIBUS_MAP = 0
to
UNIBUS_MAP = 1

and recompiled with 'make unix,' then copied the resultant unix to /unix.

I switched simh back to emulating an 11/34 and rebooted. It crashes
randomly just as it did before the kernel recompile.

Any idea what I'm missing here? My hope was to simply move this
freshly-compiled 11/34-friendly kernel onto my real 11/34 and have a
working hardware system.

thx
jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150211/1758f162/attachment.html>

From jnc at mercury.lcs.mit.edu  Thu Feb 12 02:20:54 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 11 Feb 2015 11:20:54 -0500 (EST)
Subject: [TUHS] 2.9 kernel compile
Message-ID: <20150211162054.1496F18C096@mercury.lcs.mit.edu>

    > From: Jacob Ritorto

    > I think it's something to do with the fact that he compiled it to run on
    > an 11/23. Maybe it lacks unibus support.

No, the UNIBUS and QBUS appear (from the programming level) to be identical.
There are subtle differences (the /23 and its devices can address more than
256KB of memory, and some devices have minor differences between the QBUS and
UBIBUS - e.g. the QBUS DZ has only 4 lines, not 8), but in general, they
should be interchangeable.

    > Maybe something to do with clock differences.

Again, if it boots at all, that's not it. (The vanilla /23 doesn't have a
software-controllable clock, and when booting Unix on one, one has to leave
the clock switched off till UNIX is running - at least, for the early versions
of UNIX.)

    > I fired 2.9MSCP up in simh emulating an 11/23 and it works fine. Just to
    > corroborate my hardware experience of it on the '34, I switch the cpu
    > emulation to 11/34 and got a mostly identical crash sequence as with my
    > real hardware.

Ah. Now we're getting somewhere! If the simulator crashes in the same way, it's
not flaky hardware (my first guess as to the cause).

What are the symptoms (in as much detail as you can give us)? What, if anything,
is printed before it dies?

    > I changed ...
    > UNIBUS_MAP = 0
    > to
    > UNIBUS_MAP = 1

The /34 doesn't have a UNIBUS map.

    Noel


From b4 at gewt.net  Thu Feb 12 02:27:08 2015
From: b4 at gewt.net (Cory Smelosky)
Date: Wed, 11 Feb 2015 11:27:08 -0500 (EST)
Subject: [TUHS] 2.9 kernel compile
In-Reply-To: <20150211162054.1496F18C096@mercury.lcs.mit.edu>
References: <20150211162054.1496F18C096@mercury.lcs.mit.edu>
Message-ID: <alpine.GSO.2.03.1502111126070.1006@gewt.net>

On Wed, 11 Feb 2015, Noel Chiappa wrote:

>    > From: Jacob Ritorto
>
>    > I think it's something to do with the fact that he compiled it to run on
>    > an 11/23. Maybe it lacks unibus support.
>
> No, the UNIBUS and QBUS appear (from the programming level) to be identical.
> There are subtle differences (the /23 and its devices can address more than
> 256KB of memory, and some devices have minor differences between the QBUS and
> UBIBUS - e.g. the QBUS DZ has only 4 lines, not 8), but in general, they
> should be interchangeable.

Only the 11/23+ can, early rev 11/23s couldn't go above 256K.

>
>    > Maybe something to do with clock differences.
>
> Again, if it boots at all, that's not it. (The vanilla /23 doesn't have a
> software-controllable clock, and when booting Unix on one, one has to leave
> the clock switched off till UNIX is running - at least, for the early versions
> of UNIX.)
>
>    > I fired 2.9MSCP up in simh emulating an 11/23 and it works fine. Just to
>    > corroborate my hardware experience of it on the '34, I switch the cpu
>    > emulation to 11/34 and got a mostly identical crash sequence as with my
>    > real hardware.
>
> Ah. Now we're getting somewhere! If the simulator crashes in the same way, it's
> not flaky hardware (my first guess as to the cause).
>
> What are the symptoms (in as much detail as you can give us)? What, if anything,
> is printed before it dies?
>
>    > I changed ...
>    > UNIBUS_MAP = 0
>    > to
>    > UNIBUS_MAP = 1
>
> The /34 doesn't have a UNIBUS map.
>
>    Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From jnc at mercury.lcs.mit.edu  Thu Feb 12 02:37:38 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 11 Feb 2015 11:37:38 -0500 (EST)
Subject: [TUHS] 2.9 kernel compile
Message-ID: <20150211163738.8DFC518C096@mercury.lcs.mit.edu>

    > From: Cory Smelosky <b4 at gewt.net>

    > Only the 11/23+ can, early rev 11/23s couldn't go above 256K.

Correctamundo on the last part, but not the first. I have both 11/23+'s and
11/23's, and I can assure you that Rev C and later 11/23's (the vast majority
of them) can do more than 256KB. See:

  http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/hardware/micronotes/1123.eco

for more.

	Noel


From jacob.ritorto at gmail.com  Thu Feb 12 06:32:59 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 11 Feb 2015 15:32:59 -0500
Subject: [TUHS] 2.9 kernel compile
In-Reply-To: <20150211162054.1496F18C096@mercury.lcs.mit.edu>
References: <20150211162054.1496F18C096@mercury.lcs.mit.edu>
Message-ID: <CAHYQbfBEy2fWX29=wSOEZmutjpo9FzrW52UeVhwg8DRa0Bj7DQ@mail.gmail.com>

OK, I recompiled again with PDP11 = 34. and UNIBUS_MAP = 0.

I set simh to 11/34 and I managed to get actual panics before (that I
didn't record), but now I'm just getting hangs, mostly when hitting ctrl-D
to bring system to mutiuser.  Same if I mount -a in single user and then
try to access /usr (works for a while, then hangs.).

 When hung, I can still get character echo to my terminal but can't
interrupt or background the running command, etc.  Would it help if I
traced memory and single-stepped through the (apparently) infinite loop?

The real 11/34 runs like a top under regular 2.9 (on rl02).  Can't get it
to do anything wrong; no panics, no hangs.
However, here are some examples of crashes on the real pdp11/34 (booting
via vtserver, then bringing in system from the MSCP disk), with the
original 2.9bsd-MSCP kernel (the one specifically built for 11/23):

   Opened boot.dd read-write
 rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr EOF

40Boot
: ra(0,0)unix

Berkeley UNIX (Rev. 2.9.25) Sat Aug 11 17:56:41 EDT 2001
mem = 158720

CONFIGURE SYSTEM:
                      ka6 = 2200
aps = 141572
pc = 50456 ps = 30250
__ovno = 7
trap type 11
panic: trap


and another: plain boring old hang at boot when trying to size devices.
Can't even echo characters this time.


   Opened boot.dd read-write
 rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr EOF

40Boot
: ra(0,0)unix

Berkeley UNIX (Rev. 2.9.25) Sat Aug 11 17:56:41 EDT 2001
mem = 158720

CONFIGURE SYSTEM:




One thing I think is interesting is that it's claiming 158720KW of memory.
Is that weird?  The real 11/34 has 128KW and simh is set to 256.  Where's
it getting that odd number?  Vanilla 2.9.1 on the real 11/34 boots with

Berkeley UNIX (Rev. 2.9.1) Sun Nov 20 14:55:50 PST 1983
mem = 135872



On Wed, Feb 11, 2015 at 11:20 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Jacob Ritorto
>
>     > I think it's something to do with the fact that he compiled it to
> run on
>     > an 11/23. Maybe it lacks unibus support.
>
> No, the UNIBUS and QBUS appear (from the programming level) to be
> identical.
> There are subtle differences (the /23 and its devices can address more than
> 256KB of memory, and some devices have minor differences between the QBUS
> and
> UBIBUS - e.g. the QBUS DZ has only 4 lines, not 8), but in general, they
> should be interchangeable.
>
>     > Maybe something to do with clock differences.
>
> Again, if it boots at all, that's not it. (The vanilla /23 doesn't have a
> software-controllable clock, and when booting Unix on one, one has to leave
> the clock switched off till UNIX is running - at least, for the early
> versions
> of UNIX.)
>
>     > I fired 2.9MSCP up in simh emulating an 11/23 and it works fine.
> Just to
>     > corroborate my hardware experience of it on the '34, I switch the cpu
>     > emulation to 11/34 and got a mostly identical crash sequence as with
> my
>     > real hardware.
>
> Ah. Now we're getting somewhere! If the simulator crashes in the same way,
> it's
> not flaky hardware (my first guess as to the cause).
>
> What are the symptoms (in as much detail as you can give us)? What, if
> anything,
> is printed before it dies?
>
>     > I changed ...
>     > UNIBUS_MAP = 0
>     > to
>     > UNIBUS_MAP = 1
>
> The /34 doesn't have a UNIBUS map.
>
>     Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150211/88a4195d/attachment.html>

From jacob.ritorto at gmail.com  Thu Feb 12 06:38:08 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 11 Feb 2015 15:38:08 -0500
Subject: [TUHS] 2.9 kernel compile
In-Reply-To: <CAHYQbfBEy2fWX29=wSOEZmutjpo9FzrW52UeVhwg8DRa0Bj7DQ@mail.gmail.com>
References: <20150211162054.1496F18C096@mercury.lcs.mit.edu>
 <CAHYQbfBEy2fWX29=wSOEZmutjpo9FzrW52UeVhwg8DRa0Bj7DQ@mail.gmail.com>
Message-ID: <CAHYQbfBgAjmRFmvEUY6KoVd8wkiVUybOdb-BwNKQ23vCLAHSWg@mail.gmail.com>

..and here's another boot crash on the real machine:
Berkeley UNIX (Rev. 2.9.25) Sat Aug 11 17:56:41 EDT 2001
mem = 158720

CONFIGURE SYSTEM:
ra 0 csr 172150 vector 154 attached
xp ? csr 176700 vector 254 skipped:  No CSR
rl ? csr 174400 vector 160 didn't interrupt
dz ? csr 160110 vector 320 skipped:  No autoconfig routines
lp ? csr 177514 vector 200 skipped:  No autoconfig routines
ka6 = 2200
aps = 141572
pc = 50456 ps = 30250
__ovno = 7
trap type 11
panic: trap

On Wed, Feb 11, 2015 at 3:32 PM, Jacob Ritorto <jacob.ritorto at gmail.com>
wrote:

> OK, I recompiled again with PDP11 = 34. and UNIBUS_MAP = 0.
>
> I set simh to 11/34 and I managed to get actual panics before (that I
> didn't record), but now I'm just getting hangs, mostly when hitting ctrl-D
> to bring system to mutiuser.  Same if I mount -a in single user and then
> try to access /usr (works for a while, then hangs.).
>
>  When hung, I can still get character echo to my terminal but can't
> interrupt or background the running command, etc.  Would it help if I
> traced memory and single-stepped through the (apparently) infinite loop?
>
> The real 11/34 runs like a top under regular 2.9 (on rl02).  Can't get it
> to do anything wrong; no panics, no hangs.
> However, here are some examples of crashes on the real pdp11/34 (booting
> via vtserver, then bringing in system from the MSCP disk), with the
> original 2.9bsd-MSCP kernel (the one specifically built for 11/23):
>
>    Opened boot.dd read-write
>  rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr EOF
>
> 40Boot
> : ra(0,0)unix
>  Berkeley UNIX (Rev. 2.9.25) Sat Aug 11 17:56:41 EDT 2001
> mem = 158720
> CONFIGURE SYSTEM:
>                       ka6 = 2200
> aps = 141572
> pc = 50456 ps = 30250
> __ovno = 7
> trap type 11
> panic: trap
>
>
> and another: plain boring old hang at boot when trying to size devices.
> Can't even echo characters this time.
>
>
>    Opened boot.dd read-write
>  rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr EOF
>
> 40Boot
> : ra(0,0)unix
>
> Berkeley UNIX (Rev. 2.9.25) Sat Aug 11 17:56:41 EDT 2001
> mem = 158720
> CONFIGURE SYSTEM:
>
>
>
>
> One thing I think is interesting is that it's claiming 158720KW of
> memory.  Is that weird?  The real 11/34 has 128KW and simh is set to 256.
> Where's it getting that odd number?  Vanilla 2.9.1 on the real 11/34 boots
> with
>
> Berkeley UNIX (Rev. 2.9.1) Sun Nov 20 14:55:50 PST 1983
> mem = 135872
>
>
>
> On Wed, Feb 11, 2015 at 11:20 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
> wrote:
>
>>     > From: Jacob Ritorto
>>
>>     > I think it's something to do with the fact that he compiled it to
>> run on
>>     > an 11/23. Maybe it lacks unibus support.
>>
>> No, the UNIBUS and QBUS appear (from the programming level) to be
>> identical.
>> There are subtle differences (the /23 and its devices can address more
>> than
>> 256KB of memory, and some devices have minor differences between the QBUS
>> and
>> UBIBUS - e.g. the QBUS DZ has only 4 lines, not 8), but in general, they
>> should be interchangeable.
>>
>>     > Maybe something to do with clock differences.
>>
>> Again, if it boots at all, that's not it. (The vanilla /23 doesn't have a
>> software-controllable clock, and when booting Unix on one, one has to
>> leave
>> the clock switched off till UNIX is running - at least, for the early
>> versions
>> of UNIX.)
>>
>>     > I fired 2.9MSCP up in simh emulating an 11/23 and it works fine.
>> Just to
>>     > corroborate my hardware experience of it on the '34, I switch the
>> cpu
>>     > emulation to 11/34 and got a mostly identical crash sequence as
>> with my
>>     > real hardware.
>>
>> Ah. Now we're getting somewhere! If the simulator crashes in the same
>> way, it's
>> not flaky hardware (my first guess as to the cause).
>>
>> What are the symptoms (in as much detail as you can give us)? What, if
>> anything,
>> is printed before it dies?
>>
>>     > I changed ...
>>     > UNIBUS_MAP = 0
>>     > to
>>     > UNIBUS_MAP = 1
>>
>> The /34 doesn't have a UNIBUS map.
>>
>>     Noel
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150211/6c80c3b6/attachment.html>

From jnc at mercury.lcs.mit.edu  Thu Feb 12 07:14:08 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 11 Feb 2015 16:14:08 -0500 (EST)
Subject: [TUHS] 2.9 kernel compile
Message-ID: <20150211211408.EAE9E18C096@mercury.lcs.mit.edu>

    > From: Jacob Ritorto

    > I set simh to 11/34 and I managed to get actual panics before (that I
    > didn't record)

Ah.


    > now I'm just getting hangs, mostly when hitting ctrl-D to bring system to
    > mutiuser.

The fact that it boots to the shell OK indicates things are mostly OK. I
wonder what it's trying to do, in going to multi-user, that's wedging the
system?

    > Same if I mount -a in single user and then try to access /usr (works for
    > a while, then hangs.).

Ah. That sounds very much like a 'lost' interrupt. The process is waiting
(inside the kernel) for the device to complete, and ..... crickets.

    > When hung, I can still get character echo to my terminal

So the machine is still running OK (most echoing is done inside the TTY
interrupt handler).

    >  but can't interrupt or background the running command, etc.

Like I said, it's sleeping inside the kernel, and missed the wakeup event.

If you have another console logged in, it would be interesting to see if that
one is frozen too. If not, we can use tools like 'ps', running on the second
line, to look at the first process and see what it's waiting for.

Single user, the following hack:

  sh < /dev/ttyX > /dev/ttyX &

can be used to start a shell on another tty line (since going full multi-user
seems to wedge it).

    > Would it help if I traced memory and single-stepped through the
    > (apparently) infinite loop?

No, because it's very likely not a loop! ;-)


    > here are some examples of crashes on the real pdp11/34 (booting via
    > vtserver, then bringing in system from the MSCP disk), with the original
    > 2.9bsd-MSCP kernel (the one specifically built for 11/23):
    >
    >  CONFIGURE SYSTEM:
    >  ka6 = 2200
    >  aps = 141572
    >  pc = 50456 ps = 30250
    >  __ovno = 7
    >  trap type 11
    >  panic: trap

That's a segmentation fault. Very odd trap to get! 2.9 uses overlays right?
Maybe there's a problem with how some overlay fits, or something? I don't know
much about the overlay feature, never used it, sorry.

Most of the other data (PS address, PC, KDSA6 contents, etc) aren't much use
without a dump.


    > and another: plain boring old hang at boot when trying to size devices.
    > Can't even echo characters this time.

If the init process hasn't got as far an opening the TTY, you might not get
character echoing.

If that randomly lost interrupt got lost very early on, you might could see
this sort of behaviour.


    > One thing I think is interesting is that it's claiming 158720KW of
    > memory. Is that weird? ...  Where's it getting that odd number?  Vanilla
    > 2.9.1 on the real 11/34 boots with
    >
    >  Berkeley UNIX (Rev. 2.9.1) Sun Nov 20 14:55:50 PST 1983
    >  mem = 135872

No idea where it's coming from, but remember Beowulf Schaeffer's advice to
Gregory Pelton in "Flatlander".

And now that I think about it, if the system thinks it has more memory than it
actually does, that would definitely cause problems.

Probably you should put some printf()'s in startup() and see where it's coming
from.

	Noel


From jacob.ritorto at gmail.com  Thu Feb 12 13:23:20 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 11 Feb 2015 22:23:20 -0500
Subject: [TUHS] 2.9 kernel compile
In-Reply-To: <20150211211408.EAE9E18C096@mercury.lcs.mit.edu>
References: <20150211211408.EAE9E18C096@mercury.lcs.mit.edu>
Message-ID: <CAHYQbfACaVPYw2j3S=rjHXg0QLrhCjtrXhsMqV+o+iePkdiBkw@mail.gmail.com>

OK, I jiggled the memory board and the seqfault went away.  Which is weird
because I had all the boards out of this one, thoroughly vacuumed the
backplane and all boards and deoxidized the edge connectors before
reassembling.   So now the real box is behaving more like the simh and just
hanging, not panicing anymore.  How can I find this startup() you mention?

On Wed, Feb 11, 2015 at 4:14 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Jacob Ritorto
>
>     > I set simh to 11/34 and I managed to get actual panics before (that I
>     > didn't record)
>
> Ah.
>
>
>     > now I'm just getting hangs, mostly when hitting ctrl-D to bring
> system to
>     > mutiuser.
>
> The fact that it boots to the shell OK indicates things are mostly OK. I
> wonder what it's trying to do, in going to multi-user, that's wedging the
> system?
>
>     > Same if I mount -a in single user and then try to access /usr (works
> for
>     > a while, then hangs.).
>
> Ah. That sounds very much like a 'lost' interrupt. The process is waiting
> (inside the kernel) for the device to complete, and ..... crickets.
>
>     > When hung, I can still get character echo to my terminal
>
> So the machine is still running OK (most echoing is done inside the TTY
> interrupt handler).
>
>     >  but can't interrupt or background the running command, etc.
>
> Like I said, it's sleeping inside the kernel, and missed the wakeup event.
>
> If you have another console logged in, it would be interesting to see if
> that
> one is frozen too. If not, we can use tools like 'ps', running on the
> second
> line, to look at the first process and see what it's waiting for.
>
> Single user, the following hack:
>
>   sh < /dev/ttyX > /dev/ttyX &
>
> can be used to start a shell on another tty line (since going full
> multi-user
> seems to wedge it).
>
>     > Would it help if I traced memory and single-stepped through the
>     > (apparently) infinite loop?
>
> No, because it's very likely not a loop! ;-)
>
>
>     > here are some examples of crashes on the real pdp11/34 (booting via
>     > vtserver, then bringing in system from the MSCP disk), with the
> original
>     > 2.9bsd-MSCP kernel (the one specifically built for 11/23):
>     >
>     >  CONFIGURE SYSTEM:
>     >  ka6 = 2200
>     >  aps = 141572
>     >  pc = 50456 ps = 30250
>     >  __ovno = 7
>     >  trap type 11
>     >  panic: trap
>
> That's a segmentation fault. Very odd trap to get! 2.9 uses overlays right?
> Maybe there's a problem with how some overlay fits, or something? I don't
> know
> much about the overlay feature, never used it, sorry.
>
> Most of the other data (PS address, PC, KDSA6 contents, etc) aren't much
> use
> without a dump.
>
>
>     > and another: plain boring old hang at boot when trying to size
> devices.
>     > Can't even echo characters this time.
>
> If the init process hasn't got as far an opening the TTY, you might not get
> character echoing.
>
> If that randomly lost interrupt got lost very early on, you might could see
> this sort of behaviour.
>
>
>     > One thing I think is interesting is that it's claiming 158720KW of
>     > memory. Is that weird? ...  Where's it getting that odd number?
> Vanilla
>     > 2.9.1 on the real 11/34 boots with
>     >
>     >  Berkeley UNIX (Rev. 2.9.1) Sun Nov 20 14:55:50 PST 1983
>     >  mem = 135872
>
> No idea where it's coming from, but remember Beowulf Schaeffer's advice to
> Gregory Pelton in "Flatlander".
>
> And now that I think about it, if the system thinks it has more memory
> than it
> actually does, that would definitely cause problems.
>
> Probably you should put some printf()'s in startup() and see where it's
> coming
> from.
>
>         Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150211/f647ab2c/attachment.html>

From jnc at mercury.lcs.mit.edu  Thu Feb 12 13:43:59 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 11 Feb 2015 22:43:59 -0500 (EST)
Subject: [TUHS] 2.9 kernel compile
Message-ID: <20150212034359.20E3F18C096@mercury.lcs.mit.edu>

    > From: Jacob Ritorto

    > I jiggled the memory board and the seqfault went away.

Ugh. A flaky. I hate those....

    > So now the real box is behaving more like the simh and just hanging,
    > not panicing anymore.

Does it _always_ hang at the same point in time? If so, what are the
circumstances, - have you just tried to start multi-user operation, or what?

    > How can I find this startup() you mention?

It's in machdep.c in sys/sys.

	Noel


From dave at horsfall.org  Thu Feb 12 19:50:38 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 12 Feb 2015 20:50:38 +1100 (EST)
Subject: [TUHS] 2.9 kernel compile
In-Reply-To: <20150211162054.1496F18C096@mercury.lcs.mit.edu>
References: <20150211162054.1496F18C096@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.11.1502122049091.3148@aneurin.horsfall.org>

On Wed, 11 Feb 2015, Noel Chiappa wrote:

>     > Maybe something to do with clock differences.
> 
> Again, if it boots at all, that's not it. (The vanilla /23 doesn't have 
> a software-controllable clock, and when booting Unix on one, one has to 
> leave the clock switched off till UNIX is running - at least, for the 
> early versions of UNIX.)

Read my paper on it :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From jnc at mercury.lcs.mit.edu  Thu Feb 12 23:47:00 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 12 Feb 2015 08:47:00 -0500 (EST)
Subject: [TUHS] 2.9 kernel compile
Message-ID: <20150212134700.4DC2618C098@mercury.lcs.mit.edu>

    > From: Dave Horsfall <dave at horsfall.org>

    > Read my paper on it :-)

URL?

	Noel


From jacob.ritorto at gmail.com  Fri Feb 13 00:16:43 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Thu, 12 Feb 2015 09:16:43 -0500
Subject: [TUHS] 2.9 kernel compile
In-Reply-To: <20150212134700.4DC2618C098@mercury.lcs.mit.edu>
References: <20150212134700.4DC2618C098@mercury.lcs.mit.edu>
Message-ID: <CAHYQbfBRPLmrPdACckn69K+f+tUjOgmFCjtU37KY424KuLM=Yw@mail.gmail.com>

found a copy here, i think..
https://github.com/eunuchs/unix-archive/blob/master/PDP-11/Bug_Fixes/V7_on11-34/unix_on_1134.txt

On Thu, Feb 12, 2015 at 8:47 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Dave Horsfall <dave at horsfall.org>
>
>     > Read my paper on it :-)
>
> URL?
>
>         Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150212/30780ed5/attachment.html>

From jnc at mercury.lcs.mit.edu  Fri Feb 13 01:27:01 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 12 Feb 2015 10:27:01 -0500 (EST)
Subject: [TUHS] 2.9 kernel compile
Message-ID: <20150212152701.279D718C097@mercury.lcs.mit.edu>

    > From: Jacob Ritorto

    > found a copy here, i think..

Ah, thanks.

You might want to look around in the parent directory; apparently there are
two differences between the 11/34 and 11/40, other than the clock and switch
register: the stack limit register, and different handling of
segmentation-violation aborted instructions (which affects instruction
restart on stack extension).

I don't know about 2.9, maybe it knows about these. For V6, the SLR won't be
an issue; the SLR is an option on the 11/40, so not all machines had it, and
m40.s in V6 doesn't use it. The instruction restart thing sounds like it will
be an issue with running V6 on a /34.

	Noel


From dave at horsfall.org  Fri Feb 13 01:29:49 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 13 Feb 2015 02:29:49 +1100 (EST)
Subject: [TUHS] mkfs somewhere else?
In-Reply-To: <20150208201058.488D51DE414@lignose.oclsc.org>
References: <20150208201058.488D51DE414@lignose.oclsc.org>
Message-ID: <alpine.BSF.2.11.1502130222030.3148@aneurin.horsfall.org>

On Sun, 8 Feb 2015, Norman Wilson wrote:

> Cleaning the heads probably isn't an option; when they crash, they don't 
> just pick up material from the disk platter, they may themselves be 
> damaged enough that sharp bits of the heads themselves are sticking out.

Not just that, but the aerodynamics have been screwed up.  The heads will 
no longer "float" on an air-cushion; I believe the gap is the traditional 
human hair width, if that.

Trivia: there is a small NiCd battery in the RK-05 drive which has to be 
replaced every so often; its sole job is to drag those heads back in the 
event of a power failure, whether it was writing at the time or not.

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From jnc at mercury.lcs.mit.edu  Fri Feb 13 01:44:02 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu, 12 Feb 2015 10:44:02 -0500 (EST)
Subject: [TUHS] 2.9 kernel compile
Message-ID: <20150212154402.E70AC18C097@mercury.lcs.mit.edu>

    > From: Noel Chiappa

    > apparently there are two differences between the 11/34 and 11/40, other
    > than the clock and switch register

Too early in the morning here, clearly... I was thinking of the 11/23 and the
11/40 here in the clock/SR comment, not the /34 and the /40.

_Iff_ the 11/34 is using the standard DL11-W console interface board (which
includes an LTC), there's no difference that I know of between the 11/34 and
the 11/40 on the LTC front (although the LTC is an option in the /40, so a /40
might not have one, in which case the V6 will panic on trying to boot unless
it has a KW11-P).

As for the switch register... I guess that on machines with a KY11-A, there
is no switch register? (Too lazy/busy to go read the manual(s) to confirm...)

	Noel


From cowan at ccil.org  Fri Feb 13 01:50:47 2015
From: cowan at ccil.org (cowan at ccil.org)
Date: Thu, 12 Feb 2015 10:50:47 -0500
Subject: [TUHS] mkfs somewhere else?
In-Reply-To: <alpine.BSF.2.11.1502130222030.3148@aneurin.horsfall.org>
References: <20150208201058.488D51DE414@lignose.oclsc.org>
 <alpine.BSF.2.11.1502130222030.3148@aneurin.horsfall.org>
Message-ID: <c2c53cba0affff2f8d00de6bf7797cec.squirrel@www.ccil.org>

Dave Horsfall:

> Not just that, but the aerodynamics have been screwed up.  The heads will
> no longer "float" on an air-cushion; I believe the gap is the traditional
> human hair width, if that.

Much larger.  I remember seeing a scale drawing that showed the gap
as half an inch or so, with a dust particle the size of a freaking
mountain and a human hair that looked like a Tipler cylinder.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
If I have not seen as far as others, it is because giants were standing
on my shoulders.  --Hal Abelson





From random832 at fastmail.us  Fri Feb 13 05:18:26 2015
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Thu, 12 Feb 2015 14:18:26 -0500
Subject: [TUHS] mkfs somewhere else?
In-Reply-To: <c2c53cba0affff2f8d00de6bf7797cec.squirrel@www.ccil.org>
References: <20150208201058.488D51DE414@lignose.oclsc.org>
 <alpine.BSF.2.11.1502130222030.3148@aneurin.horsfall.org>
 <c2c53cba0affff2f8d00de6bf7797cec.squirrel@www.ccil.org>
Message-ID: <1423768706.2152582.226788265.13389F90@webmail.messagingengine.com>

On Thu, Feb 12, 2015, at 10:50, cowan at ccil.org wrote:
> Dave Horsfall:
> 
> > Not just that, but the aerodynamics have been screwed up.  The heads will
> > no longer "float" on an air-cushion; I believe the gap is the traditional
> > human hair width, if that.
> 
> Much larger.  I remember seeing a scale drawing that showed the gap
> as half an inch or so, with a dust particle the size of a freaking
> mountain and a human hair that looked like a Tipler cylinder.

I think that's based on a modern hard drive, though. There's a reason
modern hard drives are sealed with air filters on the pressure
equalizing ports.


From dave at horsfall.org  Fri Feb 13 12:15:33 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 13 Feb 2015 13:15:33 +1100 (EST)
Subject: [TUHS] 2.9 kernel compile
In-Reply-To: <CAHYQbfBRPLmrPdACckn69K+f+tUjOgmFCjtU37KY424KuLM=Yw@mail.gmail.com>
References: <20150212134700.4DC2618C098@mercury.lcs.mit.edu>
 <CAHYQbfBRPLmrPdACckn69K+f+tUjOgmFCjtU37KY424KuLM=Yw@mail.gmail.com>
Message-ID: <alpine.BSF.2.11.1502131311260.3148@aneurin.horsfall.org>

On Thu, 12 Feb 2015, Jacob Ritorto wrote:

> found a copy here, 
> ithink.. https://github.com/eunuchs/unix-archive/blob/master/PDP-11/Bug_Fixe 
> s/V7_on11-34/unix_on_1134.txt

Yeah; I wrote that.  It originally appeared in an issue of AUUGN; don't 
know which one, as I haven't set myself up as a mirror for Minnie yet.

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

From dave at horsfall.org  Fri Feb 13 12:20:06 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 13 Feb 2015 13:20:06 +1100 (EST)
Subject: [TUHS] 2.9 kernel compile
In-Reply-To: <20150212152701.279D718C097@mercury.lcs.mit.edu>
References: <20150212152701.279D718C097@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.11.1502131319210.3148@aneurin.horsfall.org>

On Thu, 12 Feb 2015, Noel Chiappa wrote:

> I don't know about 2.9, maybe it knows about these. For V6, the SLR 
> won't be an issue; the SLR is an option on the 11/40, so not all 
> machines had it, and m40.s in V6 doesn't use it. The instruction restart 
> thing sounds like it will be an issue with running V6 on a /34.

I have no idea how, or even whether, I handled that...

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From cubexyz at gmail.com  Mon Feb 23 05:36:50 2015
From: cubexyz at gmail.com (Mark Longridge)
Date: Sun, 22 Feb 2015 14:36:50 -0500
Subject: [TUHS] v5 and v6 kernel is mode 777
Message-ID: <CADxT5N5HEftowuKauBvujcNAm9OCqK+xJrevkEGq=eoO4MhtEA@mail.gmail.com>

I just had it brought to my attention that the unix kernel is mode 777
in Unix v5 and v6:

ls -l /unix
-rwxrwx  1 root        27066 Mar 23  1975 /unix

There's no reason for it to be mode 777 is there? It seems rather dangerous.

In Unix v7 it defaults to mode 775 and in 32v it is 755. I figure it
setting it to mode 755 will work and so far it seems fine in v5.

Mark


From jnc at mercury.lcs.mit.edu  Mon Feb 23 05:50:31 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 22 Feb 2015 14:50:31 -0500 (EST)
Subject: [TUHS] v5 and v6 kernel is mode 777
Message-ID: <20150222195031.6EA2D18C0DD@mercury.lcs.mit.edu>

    > From: Mark Longridge

    > There's no reason for it to be mode 777 is there?

Not that I know of. Once UNIX has booted, it has no use for 'unix' (or
whatever file it booted from), and the boot loader doesn't even read the mode.

I think I habitually set mine to 644. (The 'execute' bits are, of course,
pointless...)

	Noel


From ron at ronnatalie.com  Mon Feb 23 05:49:27 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 22 Feb 2015 14:49:27 -0500
Subject: [TUHS] v5 and v6 kernel is mode 777
In-Reply-To: <CADxT5N5HEftowuKauBvujcNAm9OCqK+xJrevkEGq=eoO4MhtEA@mail.gmail.com>
References: <CADxT5N5HEftowuKauBvujcNAm9OCqK+xJrevkEGq=eoO4MhtEA@mail.gmail.com>
Message-ID: <9D89138A-970D-4011-B370-09FB8D985C58@ronnatalie.com>

Your ls is missing a set of perms (-rwxrwxrwx).

No it should not be 777.    It needs to be readable because certain programs in user mode read the symbol table.




From dave at horsfall.org  Mon Feb 23 05:56:45 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 23 Feb 2015 06:56:45 +1100 (EST)
Subject: [TUHS] v5 and v6 kernel is mode 777
In-Reply-To: <CADxT5N5HEftowuKauBvujcNAm9OCqK+xJrevkEGq=eoO4MhtEA@mail.gmail.com>
References: <CADxT5N5HEftowuKauBvujcNAm9OCqK+xJrevkEGq=eoO4MhtEA@mail.gmail.com>
Message-ID: <alpine.BSF.2.11.1502230654350.77856@aneurin.horsfall.org>

On Sun, 22 Feb 2015, Mark Longridge wrote:

> I just had it brought to my attention that the unix kernel is mode 777
> in Unix v5 and v6:
> 
> ls -l /unix
> -rwxrwx  1 root        27066 Mar 23  1975 /unix
> 
> There's no reason for it to be mode 777 is there? It seems rather 
> dangerous.

Those were happy days back then.

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From dave at horsfall.org  Mon Feb 23 06:01:38 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 23 Feb 2015 07:01:38 +1100 (EST)
Subject: [TUHS] v5 and v6 kernel is mode 777
In-Reply-To: <20150222195031.6EA2D18C0DD@mercury.lcs.mit.edu>
References: <20150222195031.6EA2D18C0DD@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.11.1502230657400.77856@aneurin.horsfall.org>

On Sun, 22 Feb 2015, Noel Chiappa wrote:

> > There's no reason for it to be mode 777 is there?
> 
> Not that I know of. Once UNIX has booted, it has no use for 'unix' (or 
> whatever file it booted from), and the boot loader doesn't even read the 
> mode.

Didn't "ps" try and read its symbol table?  I had fun days when I booted, 
say, "/unix.new", and "ps" wouldn't sodding work...

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From jnc at mercury.lcs.mit.edu  Mon Feb 23 06:19:45 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 22 Feb 2015 15:19:45 -0500 (EST)
Subject: [TUHS] v5 and v6 kernel is mode 777
Message-ID: <20150222201945.874CC18C0E9@mercury.lcs.mit.edu>

    > From: Dave Horsfall <dave at horsfall.org>

    >> Once UNIX has booted, it has no use for 'unix' (or whatever file it
    >> booted from)

    > Didn't "ps" try and read its symbol table?

Sorry, meant 'UNIX the monolithic kernel'; yes, ps and siblings (e.g. iostat)
need to get the running system's symbol table.


    > I had fun days when I booted, say, "/unix.new", and "ps" wouldn't
    > sodding work...

Know that feeling! I added the following to one of the kernel data files:

    char *endsys &end;

and then in programs which grab the system's symbol table, I have an nlist()
entry:

  "_endsys",

with the follwing code:

  /* Check that the namelist applies to the current system.
   */

  checknms(symfile)
  char	*symfile;

  {	char	*chkloc, *chkval;

	if (nl[0].type == 0)
		cerror("No namelist\n");

	chkloc = nl[ENDSYS].value;
	chkval = rdloc(chkloc);

	if (chkval != nl[END].value) {
		cerror("Symbol table in %s doesn't match running system\n",
		       symfile);
		}
  }

on the theory that pretty much any change at all is going to result in a
change in the system's size (and thus the address of 'end').

Although in a split I/D system, this may not be true (you could change the
code, and have the data+BSS remain the same size); I should probably check
the location of 'etext' as well...

Anyway, a rebuilt system may result in the address of 'endsys' changing, and
thus the rdloc() won't return the contents of the running system's 'endsys',
but the chances of an essentially-random fetch being the same as the value of
'end' in /unix are pretty slim, I would say...

	Noel


From cubexyz at gmail.com  Mon Feb 23 06:30:44 2015
From: cubexyz at gmail.com (Mark Longridge)
Date: Sun, 22 Feb 2015 15:30:44 -0500
Subject: [TUHS] v5 and v6 kernel is mode 777
In-Reply-To: <9D89138A-970D-4011-B370-09FB8D985C58@ronnatalie.com>
References: <CADxT5N5HEftowuKauBvujcNAm9OCqK+xJrevkEGq=eoO4MhtEA@mail.gmail.com>
 <9D89138A-970D-4011-B370-09FB8D985C58@ronnatalie.com>
Message-ID: <CADxT5N4B=QBwkPiHspjaGj1PcxE2M7EHEH3n24p02vsFcOtf7A@mail.gmail.com>

Ron,

You are quite right. I tried to use 1bsd's ls in v5 for the columnar
output and there are bugs.

This is what it should look like:

ls -l /unix
-rwxr-xr-x  1 root    27066 Feb 22 14:34 unix

So it's now mode 755 and everything seems to work fine.

Mark

On 2/22/15, Ronald Natalie <ron at ronnatalie.com> wrote:
> Your ls is missing a set of perms (-rwxrwxrwx).
>
> No it should not be 777.    It needs to be readable because certain programs
> in user mode read the symbol table.
>
>
>


From erc at pobox.com  Mon Feb 23 15:31:11 2015
From: erc at pobox.com (Ed Carp)
Date: Sun, 22 Feb 2015 21:31:11 -0800
Subject: [TUHS] v5 and v6 kernel is mode 777
In-Reply-To: <alpine.BSF.2.11.1502230657400.77856@aneurin.horsfall.org>
References: <20150222195031.6EA2D18C0DD@mercury.lcs.mit.edu>
 <alpine.BSF.2.11.1502230657400.77856@aneurin.horsfall.org>
Message-ID: <54EABB1F.7060704@pobox.com>

Yes - I remember those days!

BTW, ever tried running /unix from a shell prompt? :)


On 02/22/2015 12:01 PM, Dave Horsfall wrote:
> On Sun, 22 Feb 2015, Noel Chiappa wrote:
> 
>>> There's no reason for it to be mode 777 is there?
>>
>> Not that I know of. Once UNIX has booted, it has no use for 'unix' (or 
>> whatever file it booted from), and the boot loader doesn't even read the 
>> mode.
> 
> Didn't "ps" try and read its symbol table?  I had fun days when I booted, 
> say, "/unix.new", and "ps" wouldn't sodding work...


From scj at yaccman.com  Tue Feb 24 04:42:41 2015
From: scj at yaccman.com (scj at yaccman.com)
Date: Mon, 23 Feb 2015 10:42:41 -0800
Subject: [TUHS] v5 and v6 kernel is mode 777
In-Reply-To: <54EABB1F.7060704@pobox.com>
References: <20150222195031.6EA2D18C0DD@mercury.lcs.mit.edu>
 <alpine.BSF.2.11.1502230657400.77856@aneurin.horsfall.org>
 <54EABB1F.7060704@pobox.com>
Message-ID: <67b0d8f45837f53d68cfff6004cf6ba5.squirrel@webmail.yaccman.com>

I do remember somebody sending an executable file to the voice synthesizer
once.  The results were so awesomely spectacular that the file was
promptly squirreled away an trotted out for visitors for years
afterwards...


> Yes - I remember those days!
>
> BTW, ever tried running /unix from a shell prompt? :)
>
>




From dave at horsfall.org  Tue Feb 24 06:35:13 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 24 Feb 2015 07:35:13 +1100 (EST)
Subject: [TUHS] Claude Shannon
Message-ID: <alpine.BSF.2.11.1502240733470.91742@aneurin.horsfall.org>

Claude Shannon passed away on this day in 2001.

Regarded as the Father of Information Theory, I doubt whether you'll go 
through a day without bumping into him: computers, electronics, file 
compression, audio sampling, you name it and he was probably behind it.

Please take a moment to remember him.

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From beebe at math.utah.edu  Tue Feb 24 09:45:26 2015
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Mon, 23 Feb 2015 16:45:26 -0700 (MST)
Subject: [TUHS] Claude Shannon
In-Reply-To: <alpine.BSF.2.11.1502240733470.91742@aneurin.horsfall.org>
Message-ID: <CMM.0.95.0.1424735126.beebe@psi.math.utah.edu>

Dave Horsfall <dave at horsfall.org> posts a note today about the 14th
anniversary of the death of Claude Shannon on 24 February 2001.

Readers can find an extensive bibliography of his works, and
publications by others about him or his works, here:

	http://www.math.utah.edu/pub/bibnet/authors/s/shannon-claude-elwood.bib
	http://www.math.utah.edu/pub/bibnet/authors/s/shannon-claude-elwood.html

They look identical on the screen, but the first is needed for BibTeX use,
and the second has live hyperlinks.

Notices to me of omissions, errata, etc., in the bibliography archives
are always welcome.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


