TUHS

tuhs@tuhs.org

22 participants
6537 discussions

Re: [TUHS] Thompson at Berkeley on an 11/70

by Doug McIlroy

To tell whether Ken installed v6 or a copy of his home system, look at /usr/dict/words. On the home system that file is the wordlist from Webster's Collegiate Dictionary, 7th edition, licensed for Bell Labs use only. On distribution systems we substituted the wordlist for "spell". The latter list contains many more proper names, acronyms, etc than the dictionary did, in particular names that appear in Unix documentation such as Ritchie, Kernighan, and McIlroy. It also lacks lots of trivially derivable words like "organizationally". If you do have the Webster file rather than the spell file, please don't propagate it. Doug

10 years, 3 months

Thompson at Berkeley on an 11/70

by Jacob Goense

I'm experimenting with adapting Unix history and lore using the new EXPECT/SEND feature in simh. My favorite guinea pig is the story of Ken Thompsons sabbatical at Berkeley where he brings up V6 on new 11/70 with Bob Kridle and Jeff Schriebman. Any details not yet recorded in obvious places[1] are of course more than welcome! One of the things I'm trying to get right is what they actually brought up there initially in 1975. This must have been standard V6 or the Bell UNIX Ken brought with him, but I can't figure it out. Salus has Schriebman, Haley and Joy installing the fixes on the 50 bugs tape late summer 1976. This suggests it was stock V6 initially, but they might have been playing on a different system or working from a fresh install in 1976. If it was stock V6 initially, what were they waiting for? Legal stuff? If it was 1975 Bell UNIX, can I reconstruct this using the 54 patches collected by Mike O'Brien[2], or is that going to be way off from what Thompson left in Urbana-Champaign with Greg Chesson in 1975? [1] http://www.tuhs.org/books.html minus the Bell journals for example [2] Hidden in /usr/sys/v6unix/unix_changes in one of the Spencer tapes http://www.tuhs.org/Archive/Applications/Spencer_Tapes/unsw3.tar.gz

10 years, 3 months

Re: [TUHS] Three Questions

by Doug McIlroy

> Does anything at all exist of PDP-7 Unics? All I know about is that > there was a B language interpreter. Maybe a printout of the manual has > survived? There was no manual. doug

10 years, 3 months

Three Questions

by Mark Longridge

Ok, the first question is: Has anyone got Unix sysv running on PDP-11 via simh? I downloaded some files from archive.org which included the file 'sys_V_tape' but so far I haven't got anywhere with it. Looks interesting though. Second question is: What is the deal with Unix version 8? Except for the manuals v8 seems to have disappeared into the twilight zone. Wikipedia doesn't say much, only "Used internally, and only licensed for educational use". So can we look at the source code? Was it sold in binary form only? Ok, now the big question: Does anything at all exist of PDP-7 Unics? All I know about is that there was a B language interpreter. Maybe a printout of the manual has survived? Mark

10 years, 3 months

Three Questions

by norman＠oclsc.org

Mark Longridge: What is the deal with Unix version 8? Except for the manuals v8 seems to have disappeared into the twilight zone. Wikipedia doesn't say much, only "Used internally, and only licensed for educational use". So can we look at the source code? Was it sold in binary form only? ======= The Eighth Edition system was never released in any general way, only to a few educational institutions (I forget the number but it was no more than a dozen) under specific letter agreements that forbade redistribution. It was never sold, in source or binary or any other form; the tape included a bootstrap image and full source code. I was involved in all this--in fact one of the first nontrivial things I did after arriving at Bell Labs was to help Dennis assemble the tape--but that was more than 30 years ago and the details have faded. The system as distributed ran only on the VAX-11/750 and 11/780. The bootstrap image on the tape was probably more restrictive than that; if one of the licensees needed something different to get started we would have tried to make it, but I don't remember whether that ever happened. Later systems (loosely corresponding to the Ninth and Tenth editions of the manual) ran on a somewhat wider set of VAXes, in particular the MicroVAX II and III and the VAX 8700 and 8550 (but not the dual- processor 8800). There was never a real distribution of either of those systems, though a few sites made special requests and got hand-crafted snapshots under the same restrictive letter agreement. So far as I know, no Research UNIX system after 7/e has ever been made available under anything but a special letter agreement. There was at one point some discussion amongst several interested parties (including me and The Esteemed Warren Toomey) about strategies to open up the later source code, but that was quashed by the IBM vs The SCO Group lawsuit. It would likely be very hard to make happen now, because I doubt there's anyone left inside Bell Labs with both the influence and the interest, though I'd be quite happy to be proven wrong on that. I know of one place in the world where (a descendant of) that system is still running, but I am not at the moment in a position to say where that is. I do know, however, of at least two places where there are safe copies of the source code, so it is unlikely to disappear from the historic record even if that record cannot be made open for a long time. Norman Wilson Toronto ON (Computing Science Research Centre, Bell Labs, 1984-1990)

10 years, 3 months

microfiche scanning news

by Nelson H. F. Beebe

There was a posting on the SIMH list today from Joerg Hoppe <j_hoppe(a)t-online.de> about a project to build a microfiche scanner that has now successfully converted 53,545 document pages to electronic form, and the files are being uploaded to the PDP-11 section of bitsavers.org. The scanner is described here: http://retrocmp.com/projects/scanning-micro-fiches There are links on that page to the rest of the story. It is an amazing piece of work for a single person. ------------------------------------------------------------------------------- - 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(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

10 years, 3 months

Old kernel hacker chuckle

by Ronald Natalie

I have an appointment Monday with my oral surgeon, Dr. Naimi. I still can’t resist pronouncing it Dr. Namei.

10 years, 4 months

Claude Shannon

by Dave Horsfall

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)

10 years, 4 months

Re: [TUHS] v5 and v6 kernel is mode 777

by jnc＠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

10 years, 4 months

v5 and v6 kernel is mode 777

by Mark Longridge

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

10 years, 4 months

Re: [TUHS] v5 and v6 kernel is mode 777

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)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

10 years, 4 months

Re: [TUHS] 2.9 kernel compile

by jnc＠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

10 years, 5 months

Re: [TUHS] 2.9 kernel compile

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > Read my paper on it :-) URL? Noel

10 years, 5 months

Re: [TUHS] mkfs somewhere else?

by norman＠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

10 years, 5 months

Re: [TUHS] 2.9 kernel compile

by jnc＠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

10 years, 5 months

Re: [TUHS] 2.9 kernel compile

by jnc＠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

10 years, 5 months

Re: [TUHS] 2.9 kernel compile

by jnc＠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

10 years, 5 months

Re: [TUHS] 2.9 kernel compile

by jnc＠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

10 years, 5 months

Re: [TUHS] 2.9 kernel compile

by jnc＠mercury.lcs.mit.edu

> From: Cory Smelosky <b4(a)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/hardwar… for more. Noel

10 years, 5 months

2.9 kernel compile

by Jacob Ritorto

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

10 years, 5 months

OS COSMOS, russian UNIX emulated system now online :)

by asbesto

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 ]

10 years, 5 months

augmented unix v5

by Mark Longridge

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

10 years, 5 months

Re: [TUHS] 2.9BSD on an actual rl02 - swap confusion

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole <clemc(a)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

10 years, 5 months

Re: [TUHS] 2.9BSD on an actual rl02 - swap confusion

by jnc＠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

10 years, 5 months

Re: [TUHS] mkfs somewhere else?

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

10 years, 5 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