TUHS

tuhs@tuhs.org

6 participants
6532 discussions

[pups] Making a TK50 2.11BSD boot tape for an 11/73

by David Evans

Howdy. I'd like to confirm that somebody has successfully made a TK50 boot tape for 2.11BSD using a TK50Z attached to some other Unix box. In my case it will likely have to be Linux, though IRIX might be doable. It *should* work, after all, but, well, you know. :) -- David Evans (NeXTMail/MIME OK) dfevans(a)bbcr.uwaterloo.ca Ph.D. Candidate, Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/ University of Waterloo "Default is the value selected by the composer Ontario, Canada overridden by your command." - Roland TR-707 Manual

22 years, 5 months

Re: [TUHS] unsigned division in V7's C

by Wolfgang Helbig

Warren replies: >Not sure if: > >http://www.tuhs.org/Archive/PDP-11/Bug_Fixes/Net.v7bugs/0017 > >is a bug fix for this. And Dennis replies: >Does > http://www.cs.bell-labs.com/who/dmr/odd.html#muldiv >suffice to explain the behavior Thanks for the replies, but the bug I found is about unsigned int's and not long int's. The V7 C code simply the DIV instruction for unsigned division. The dividend is put in the low word of a register pair with the upper word cleared. When the divisor is >= 2^15, DIV interprets it as a negative integer and produces the result (N = 2^16): N - a/(N-b) instead of a/b, and a%(N-b) instead of a%b. This explains the bug I've sent yesterday. I is easily fixed, since when b >= N/2 and a < N, then a/b is either zero or one. And there is another bug when using DIV for unsigned integers: If b = 1 and a >= N/2, then a/b >= N/2, that is a signed overflow. With V7 on Bob Supniks simulator (2.10), I get 60000/1: 0, 60000%1: 60000 DIV did not change the dividend because of overflow. Again a fix is easy: With unsigned ints, don't use DIV to divide by one. In all other cases, DIV produces the correct unsigned results, if the dividend is less N, that is its high word is zero. I wonder why these bugs went unnoticed. Greetings Wolfgang

22 years, 5 months

re: unsigned division in V7's C

by Dennis Ritchie

Helbig observed > while wondering how unsigned integer division is implemented in C > I found a bug in V7: a/b and a%b with b >= 2^15 does not give the expected > results, if a and b are unsigned int's. Does http://www.cs.bell-labs.com/who/dmr/odd.html#muldiv suffice to explain the behavior? Dennis

22 years, 5 months

unsigned division in V7's C

by Wolfgang Helbig

Hi, while wondering how unsigned integer division is implemented in C I found a bug in V7: a/b and a%b with b >= 2^15 does not give the expected results, if a and b are unsigned int's. Was this bug ever noticed or even fixed? Greetings, Wolfgang Here is a program showing the bug: main() { unsigned int a, b; a = 60000; b = 40000; printf("a/b: %u, a%%b: %u\n", a/b, a%b); b = 25000; printf("a/b: %u, a%%b: %u\n", a/b, a%b); } The above program prints a/b: 65534, a%b: 8928 a/b: 2, a%b: 10000 The first line should be of course a/b: 1, a%b: 20000

22 years, 5 months

Re: Patches to improve 6th Edition

by norman＠nose.cs.utoronto.ca

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

22 years, 6 months

Re: [pups] Mail delivery failed: returning message to sender

by pete＠dunnington.u-net.com

On Jan 6, 19:01, Wolfgang Helbig wrote: > Richard L. Hamilton searches: > >The files > > > >http://minnie.tuhs.org/UnixTree/V7/usr/sys/dev/rl.c > >http://minnie.tuhs.org/UnixTree/V7/usr/sys/conf/mkconf.c > > > >don't seem to match - mkconf.c wants to generate references to > >rlopen() and rlclose(), which don't exist in that version of rl. > >What I'm really looking for is the right version of driver(s) etc. > > It seems that a version of the rl driver that matches > mkconf, was never supplied by the bell labs. > > As a workaround delete the rl entry in cdevsw and the line > "int rlopen,..." from c.c. This will give you a block device of the rl disk, > but no raw device. Hmm... my 7th Edition distribution /usr/sys/dev/rl.c certainly *does* have rlopen() and rlclose(). If you want them, I can send rl.c and the matching mkconf.c to you, or to Warren, along with the rl1conf and rl2conf (for RL01 and RL02 disks) from /usr/sys/conf/ and any other files needed (if someone can tell me what might be required -- it's a long long time since I looked at any of this. The distribution came for an 11/23 with 2 x RL02, and it also has some special source files for 11/23, 11/34, etc ("small machines") including tests for recovery from segmentation traps in floating point (which isn't the same on all PDP-11 models), and an RK driver from the Boston Children's Museum which handles overlapped seeks on multiple drives. I'll be away for a couple of days so don't expect a prompt reply, but the source is online here so I can easily copy a few files when I get back. -- Pete Peter Turnbull Network Manager University of York

22 years, 6 months

[pups] Mail delivery failed: returning message to sender

by Wolfgang Helbig

Richard L. Hamilton searches: >The files > >http://minnie.tuhs.org/UnixTree/V7/usr/sys/dev/rl.c >http://minnie.tuhs.org/UnixTree/V7/usr/sys/conf/mkconf.c > >don't seem to match - mkconf.c wants to generate references to >rlopen() and rlclose(), which don't exist in that version of rl. >What I'm really looking for is the right version of driver(s) etc. It seems that a version of the rl driver that matches mkconf, was never supplied by the bell labs. As a workaround delete the rl entry in cdevsw and the line "int rlopen,..." from c.c. This will give you a block device of the rl disk, but no raw device. Greetings, Wolfgang

22 years, 6 months

[pups] V7 RL02 driver questions

by Richard L. Hamilton

The files http://minnie.tuhs.org/UnixTree/V7/usr/sys/dev/rl.c http://minnie.tuhs.org/UnixTree/V7/usr/sys/conf/mkconf.c don't seem to match - mkconf.c wants to generate references to rlopen() and rlclose(), which don't exist in that version of rl.c. What I'm really looking for is the right version of driver(s) etc. so that I can regenerate the rl2unix kernel in the V7 image available for use with simh, so that I can add or tweak drivers, eventually adding the dz driver so I can run multiple "terminals" with telnet access. -- mailto:rlhamil@mindwarp.smart.net http://www.smart.net/~rlhamil

22 years, 6 months

db(I) in Unix V6

by Wolfgang Helbig

Hi, tinkering at V6--now I need db(I). It works fine, but three features that are described in its manual page seem to be missing: - The names of the general registers (r0, ...) are not build in, at least db only responds with `?' to `r0'. I can examine the registers via the `$' command though. - The '*' feature doesn't work, i.e. `*_main' gives me a `?'. - I can't specify a number being relocatable, i.e. '10r' gives me a `?'. Is this an exercise to the user? Did anyone solve the exercise. Or did I just not understand the manual page? Greetings, Wolfgang

22 years, 6 months

Re: [pups] V7 setjmp/longjmp

by Wolfgang Helbig

Michael Davidson distrusted: >Note that this means that r4, r3 and r2 get restored to the values >that they had at the time that the next stack frame was established >(ie when the "next" function down was called from the original context) >and that these are not necessarily the values that they had at the >moment when the original call to setjnp returned. Hence the various >caveats about not relying on the value of any register variables >after returning via longjmp. You can trust register variables when setjmp() returns the second time. Then the registers are restored to the values they had when the "next" function was called, that is the "values as of the time longjmp() was called" (quoted from longjmp(3)'s man page. Thus any variable behaves the same, regardless of its storage class. By the way, this is not the case in V6. The register variables-- and only the register variables-- are restored to the values as of the time setexit() was called. (In V6 "setjmp()" is named "setexit()" and "longjmp()" is named "reset()"). Thus the value of a variable depends on its storage class. If it is register, you get the value when setexit() was called, if it is not register, you get the value when reset() was called. This might be considered a bug. Greetings Wolfgang

22 years, 6 months

[pups] V7 setjmp/longjmp

by bwc＠coraid.com

Looking thru the code for setjmp/longjmp (/usr/src/libc/gen/setjmp.s), and have a question. Longjmp seems to make an attempt at restoring register two through four, but setjmp doesn't save them. Where do these register get saved from? Brantley Coile

22 years, 6 months

Re: Patches to improve 6th Edition

by 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

22 years, 6 months

Re: [TUHS] Re: Patches to improve 6th Edition

by 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 :-).

22 years, 6 months

Re: Patches to improve 6th Edition

by 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? :-)

22 years, 6 months

Re: Patches to improve 6th Edition

by 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.

22 years, 6 months

Re: Re: [TUHS] Re: Patches to improve 6th Edition

by 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

22 years, 6 months

V6: 50 bugs tape

by Wolfgang Helbig

Hi, someone on this list mentioned a '50 bugs tape', which contains bug fixes to Unix V6. Is this list somewhere in the archive? Thank you, Wolfgang

22 years, 6 months

Re: [TUHS] In V6 exit(): wakeup(&proc[1])) unnecessary?

by Wolfgang Helbig

>>When a process terminates (in sys1.c/exit()), it explicitly wakes up >>the init process. In light of the fact, that every process has a parent, >>this extra wakeup(&proc[1]) seems unnecessary. > >I believe this is meant to handle the case where a process exits >without having called wait() on its children. > >Imagine two processes, A and B, where A is B's parent and A's parent >is some process other than init. B calls exit(), becomes a zombie, >and awakens A. Some time later, A calls exit() without ever having >called wait(). This will cause B to become a child of init, and as B >is a zombie, init should awaken so that B can die. However, A might >have any number of zombie children, and it would be redundant to call >wakeup(&proc[1]) for each one. Therefore, the wakeup call to init is >done up front, whether it is needed or not. This does result in some >unnecessary wakeup calls but on the whole it seems a good tradeoff for >code simplicity. Oh, I see! So the condition to wakeup init would be "Do I have any zombie children"? The code as it is is simpler. But harder to understand. Thank you very much for your help! Greetings Wolfgang Helbig

22 years, 6 months

In V6 exit(): wakeup(&proc[1])) unnecessary?

by Wolfgang Helbig

Hi, encouraged by the profound answers I thankfully recieved to my previous question about the Unix V6 kernel, here is another one: When a process terminates (in sys1.c/exit()), it explicitly wakes up the init process. In light of the fact, that every process has a parent, this extra wakeup(&proc[1]) seems unnecessary. Furthermore, the "goto loop:" at the end of exit() will never be executed. So is this just defensive programming, or did I miss something? Greetings, Wolfgang Helbig

22 years, 6 months

[pups] 11/34

by Robin Birch

Dear All, There is a complete 11/34 for sale on EBay (1 day to go). It comes with a complete V6 with source. Somebody buy it please. This is nothing to do with me, I just saw it tonight. It's in Pontypridd South Wales Cheers Robin -- Robin Birch

22 years, 6 months

RE: [TUHS] re: Raise of interrupt level necessary

by Ian King

Yes, I have v6 running on an 11/34; it's amazing how easy it is to corrupt the filesystem. :-) One of these days, I need to dd another fresh system disk (RK05) off my "sacred copy" of a PUPS image (tediously transferred via 9600 baud serial using Warren's excellent vtserver tools). In any case, why do you ask? - Ian -----Original Message----- From: Wolfgang Helbig [mailto:helbig@Informatik.BA-Stuttgart.DE] Sent: Saturday, December 14, 2002 12:48 AM To: tuhs(a)minnie.tuhs.org Subject: Re: [TUHS] re: Raise of interrupt level necessary [snip] I also removed IPL protection from the return sequence of the trap routine, still works. Testing was done on Bob Supnik's SIMH PDP-11 simulator with only one terminal. By the way, is anyone running V6 on a real PDP-11? [snip]

22 years, 6 months

re: Raise of interrupt level necessary

by Wolfgang Helbig

>Date: Sat, 14 Dec 2002 15:27:40 -0800 Michael Davidson wrote: >If you think that the "rule" is "no ISR can touch user space while >interrupting a kernel process", then it is display() that breaks >the rule. The point is, that this rule leads to somewhat simpler and therefore better code -- breaking the rule calls for some justification. Calling display() from the clock-ISR is the only place where an ISR does not conform to this rule. Greetings Wolfgang Helbig

22 years, 6 months

Re: [TUHS] re: Raise of interrupt level necessary

by Wolfgang Helbig

Dennis, I greatly appreciate your reply. What amazes me most, is the fact that after 20 odd years you still remember those tricky details: >For example, the clock interrupt routine can inspect user >space (for display(), for example, though this is inactive >on the 11/40), and even change it (for profiling). >It does appear that other things (checking for >a direct-from user-mode interrupt) in the clock routine >already guard against these particular problems. To see what happens, I just removed those IPL raising instructions from gword, pword,_savu, _aretu, _copyseg, and _clearseg in m40.s. In fact, it didn't crash the system. At least on my configuration, ISRs don't touch user space while interrupting a kernel process. This rule is broken by the clock ISR, which calls display() unconditionally. Just curious: Is there any other reason beside seeing blinking lights that justifies calling display() 60 times per second and breaking the rule? I also removed IPL protection from the return sequence of the trap routine, still works. Testing was done on Bob Supnik's SIMH PDP-11 simulator with only one terminal. By the way, is anyone running V6 on a real PDP-11? Here is the diff of my modifications to m40.s: # diff m40.s.6 m40.s 44d43 * bis $340,PS 455,456d453 * mov PS,-(sp) * bis $340,PS 472,473d468 * mov PS,-(sp) * bis $340,PS 480d474 * mov (sp)+,PS 485d478 * mov (sp)+,PS 539d531 * bis $340,PS 548d539 * bis $340,PS 594c585 * mov $30340,PS --- . bis $30000,PS 621c612 * mov $30340,PS --- . bis $30000,PS Greetings, Wolfgang Helbig

22 years, 6 months

qbus scsi controllers

by Robertdkeys＠aol.com

I know it causes one to salivate like Pavlov's dogs, even thinking about them, but, anyone know of any qbus scsi controllers that might someday come available at anything like reasonable sorts of guildern de realme? (running and ducking for cover....(:+]].....) Just thought I would check. Thanks Bob

22 years, 6 months

Re: [TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by Robertdkeys＠aol.com

The particular webster wqesd4 I have looks like about an '86 or so board, from chip dates, and the main chip that is socketed is marked with "ENGR-SAMPLE"...doh.... Maybe I do have a very early board that won't run with a faster cpu. The rom is a part no. 080469-01 REV 01, if that means anything to anyone, as marked on its paper label. The later sigma board does not have the problem. Oh, well, if I have to run it with a KA630 at slo-poke gait, so be it....(:+\\... There are two diodes, one looks like an ordinary silicon rectifier and one looks like a zener of some sort, possibly, off pin 19 of the 74ls240 at position V2 on the board. Those come off the J6 pin 10 of 10, and are in parallel. Thanks Bob

22 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS