[TUHS] Re: Patches to improve 6th Edition

[TUHS] Re: Patches to improve 6th Edition

[Norman Wilson]

A belated rejoinder to:

  This bug existed from (at least) the Fifth up until the Eighth
  editions from 1127 (BTL research). The Ninth edition had much
  rewrites in the kernel and the algorthim was changed at that point.

You're welcome.  I can't remember, though, whether I fixed it on
purpose or as part of the many general cleanups and restructurings
I did at that point.  And I didn't do enough of it; recently I
discovered a dumb problem that I probably introduced in the same
cleanups, wherein the i-node allocated for a file that couldn't be
created because the file system was full and the directory entry
couldn't be written was left allocated but nameless ...

Norman Wilson
Toronto ON

[TUHS] Re: Patches to improve 6th Edition

[Wolfgang Helbig]

some hours ago I wrote:
>I ask this, because my system crashes ones in a while. But I changed it
>here and there, so it might be my fault.

It *was* my fault! So far, I have only found one bug in V6: The size
of swapmap and coremap are configured too small, so they might overflow.

The sizes don't take account of shared text segments, that produce
extra chunks of free memory. In V6 there are 19 pure executables, so their
minimal size should be (NPROC+19)*2, or better yet (NPROC+NTEXT)*2, where
NTEXT should be set to 20 instead of 40 as distributed in param.h .

I don't think this bug ever showed up. It is very unlikely. In V7 these
sizes are choosen to be even smaller than NPROC and even with its many pure 
executables, I don't think V7 ever crashed because of this bug.

So, with the only exception reported by Brian S. Walden, there seem to be
no bugs in V6 that crash systems.

Greetings

Wolfgang

[TUHS] Re: Patches to improve 6th Edition

[Wolfgang Helbig]

>
>In article by Mirian Crzig Lennox:
>> This reminds me that I fixed a couple of "bugs" (some outright bugs,
>> and some mere behaviours which I didn't quite like) in playing with my
>> V6/simh environment, and I'm wondering if there is a place I should
>> submit them in case others might be interested. [ .. ]

Mirian, I'd love to see your fixes! By the way, you might want to
look at
	http://www.tuhs.org/Archive/PDP-11/Bug_Fixes/V6enb
for some changes I applied to V6.

Thanks to Warren and Mirian for helping me to undig the "50 bugs tape"! 
But the "bugs fixes" look more like performance enhancements. Do you know
any real bugs in V6? By "real" I mean a bug, that might crash the system.

I ask this, because my system crashes ones in a while. But I changed it
here and there, so it might be my fault.

Greetings,

Wolfgang

>
>P.S Does anybody want to backport vi to 6th & 7th Edition?! :-)

Hmm. It's less work to learn ed, so I took that path :-).

[TUHS] Re: Patches to improve 6th Edition

[Mike Haertel]

In article by Warren Toomey:
> P.S. Does anybody want to backport vi to 6th and 7th Edition?! :-)

The 2BSD tape contains vi source code that can *definitely* be built
on 7th edition (I've done it, it was easy) and supposedly can also
be used to build a 6th-edition "native" vi if you're willing to
backport the V7 C compiler (I haven't done that yet).

Since many people in 2BSD's time frame would not have had access
to V7 systems or V7-ish C compilers, the 2BSD tape also contains a
vi binary for V6 systems.

I think 2BSD was released around the same time as V7, and had an
assumption that many people would not yet have access to V7, and
so would want to use 2BSD as an add-on to V6 systems.

Since 6th edition didn't have environment variables, the 2BSD/V6
version of vi would get the terminal type from a file that mapped
hardwired serial lines to terminal type names.  I think it was
called /etc/htmp.

By the way, does anybody else think that vi should have been upgraded
to vii when V7 came out? :-)

[TUHS] Re: Patches to improve 6th Edition

[Brian S Walden]

Yes there are other bugs you will want to fix as well
if you are using v6 heavily and not on slow hardware
(e.g. a simulator).  In the inode allocation route
(ialloc()) in /usr/sys/ken/alloc.c there is a bug in
the placement of the loop: tag.  You just have to move
it up two line to above the while() loop. See the diff below.
This rare Ken Thompson bug was found in 1988 on an Amdahl UTS machine
that the hardware finally became fast enough that it caused us panics.
This bug existed from (at least) the Fifth up until the Eighth
editions from 1127 (BTL research). The Ninth edition had much
rewrites in the kernel and the algorthim was changed at that point.
Since it was in UTS, it must have been in the porting base of
System V Release 2. This code is the basis for the System V
filesystem, so it probably didn't exist in BSD releases
since they used their fast filesystem (cylinder groups, et al.)
which became UFS. It's amazing thet with the amount of eyes on it
(via Lions Commentary, etc.) it was not spotted earlier.

It would be good to get a collection of all "unreleased" bug fixes
that others may have.


*** alloc.c.orig        Fri Dec 27 23:23:30 2002
--- alloc.c     Fri Dec 27 23:23:30 2002
***************
*** 163,171 ****
        int i, j, k, ino;
  
        fp = getfs(dev);
        while(fp->s_ilock)
                sleep(&fp->s_ilock, PINOD);
- loop:
        if(fp->s_ninode > 0) {
                ino = fp->s_inode[--fp->s_ninode];
                ip = iget(dev, ino);
--- 163,171 ----
        int i, j, k, ino;
  
        fp = getfs(dev);
+ loop:
        while(fp->s_ilock)
                sleep(&fp->s_ilock, PINOD);
        if(fp->s_ninode > 0) {
                ino = fp->s_inode[--fp->s_ninode];
                ip = iget(dev, ino);


In article by Mirian Crzig Lennox:
> This reminds me that I fixed a couple of "bugs" (some outright bugs,
> and some mere behaviours which I didn't quite like) in playing with my
> V6/simh environment, and I'm wondering if there is a place I should
> submit them in case others might be interested.

[TUHS] Re: Patches to improve 6th Edition

[John Holden]

> P.S Does anybody want to backport vi to 6th & 7th Edition?! :-)

'vi' definately works with I+D space under edition 7 (11/44/45/50/53/55/70/73)
There was also an overlayed version for I space only under BSD 2.?, but it was
sooooo slow as to be almost useless

[TUHS] Re: Patches to improve 6th Edition

[Greg Haerr]

> P.S Does anybody want to backport vi to 6th & 7th Edition?! :-)

Isn't the problem here that vi is quite a bit bigger than
64k I+D?  I can probably dig up some small subset
versions that I got running on the ELKS project (x86 Linux).

Regards,

Greg

[TUHS] Re: Patches to improve 6th Edition

[Warren Toomey]

In article by Mirian Crzig Lennox:
> This reminds me that I fixed a couple of "bugs" (some outright bugs,
> and some mere behaviours which I didn't quite like) in playing with my
> V6/simh environment, and I'm wondering if there is a place I should
> submit them in case others might be interested. [ .. ]
>
> If any of these would be considered interesting, I would be only too
> happy to release patches.  I'll doubtless have more, as well, as I
> press on.
> 
> My eventual goal is to come up with a 6th edition UNIX which is quite
> usable, while still being recognisable as 6th edition.
> --Mirian

Mirian, I'll definitely make a place somewhere in the Unix Archive
for your work. 

	Warren

P.S Does anybody want to backport vi to 6th & 7th Edition?! :-)