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: 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: On 2/7/15, Warren Toomey 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: 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: 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: References: Message-ID: 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: References: Message-ID: what about using another minor device? Is xp0d mapped elsewhere? On Sun, Feb 8, 2015 at 1:36 AM, Dave Horsfall 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: 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: References: Message-ID: 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 wrote: > what about using another minor device? Is xp0d mapped elsewhere? > > On Sun, Feb 8, 2015 at 1:36 AM, Dave Horsfall 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: 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: References: Message-ID: 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: References: Message-ID: 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 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: 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: 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: 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: 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 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: 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: On Sun, Feb 8, 2015 at 3:42 PM, Noel Chiappa 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: 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: References: <20150208204207.7860218C0BE@mercury.lcs.mit.edu> Message-ID: 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 > 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: On Sun, Feb 8, 2015 at 5:42 PM, Noel Chiappa 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: 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: 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: 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: 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: 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 > 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: 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 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: 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: References: <20150211162054.1496F18C096@mercury.lcs.mit.edu> Message-ID: ..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 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 > 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: 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: 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 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: 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: 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 > 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: 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 wrote: > > From: Dave Horsfall > > > 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: 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: 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: References: <20150208201058.488D51DE414@lignose.oclsc.org> Message-ID: 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: References: <20150208201058.488D51DE414@lignose.oclsc.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: References: <20150212134700.4DC2618C098@mercury.lcs.mit.edu> Message-ID: 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: 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: 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: References: 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: References: Message-ID: 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: 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 >> 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: <9D89138A-970D-4011-B370-09FB8D985C58@ronnatalie.com> Message-ID: 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 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: References: <20150222195031.6EA2D18C0DD@mercury.lcs.mit.edu> 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> <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: 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: Message-ID: Dave Horsfall 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/ - -------------------------------------------------------------------------------