TUHS

tuhs@tuhs.org

6 participants
6532 discussions

by Peter Turnbull

On Mar 21, 23:04, Robin Birch wrote: > I am probably going to get a broadband connection to wherever I end up. > I will then network all of the various boxes together and connect > everything (including the PDP) to the Internet. I intend having one box > set up as a server [...] > In case the above seems stupid the idea is to take all email through a > server, weed out all incoming rubbish, and route it to various > individual's (partner, daughter etc.) PCs. This is exactly what I do, though I have the sending and receiving sides of the email equation separate. I have one machine that acts as a mail hub. It runs sendmail with a custom sendmail.cf which is capable of delivering internal mail either to /var/mail, which is then exported to other machines, or via UUCP or SMTP to other machines. It also batches up outgoing mail and sends it to my ISP's mail server ("Smart Host") at specific times of the day (mine's not an always-on connection). All the other machines either use UUCP, or use sendmail with the "nullclient" .cf file, to send mail to my hub machine. No reason why the hub couldn't run a POP3 server for the benefit of Windoze PCs as well, but I've never felt the need :-) If you go that route, I'd suggest you think about IMAP rather than POP, though. As far as getting mail from my ISP, I use fetchmail -- but if you do this, be sure that your ISP puts something in the headers that makes it easy for fetchmail to tell which user it's really for (don't forget about mailing lists), and that you have a catchall rule to handle mail you didn't think of. If you have an always-on connection, you could have your DNS MX record(s) set to point to your hub machine, and needn't use fetchmail. However, if you do that, be sure to set up sendmail with anti-relaying and all the proper security patches. -- Pete Peter Turnbull Network Manager University of York

22 years, 3 months

[pups] Totally off topic question

by Robin Birch

Hi Everyone, Sorry for asking this here but you are probably the best people to ask. I'm in the process of packing up my house to redecorate it and move to another. As a result my 11/83 has been packed up and I won't get to play for some time :-(. However, the question - I am probably going to get a broadband connection to wherever I end up. I will then network all of the various boxes together and connect everything (including the PDP) to the Internet. I intend having one box set up as a server for FTP, email and so on and everything else using that. I will probably use a Linux box for this. Can I get a pop3 system for it that will talk to sendmail (only because sendmail is the only mail system that I have used) or can I get a reasonable pop3 server for Linux. Anybody else has ideas on how I should do this then hints tips etc. gratefully received. In case the above seems stupid the idea is to take all email through a server, weed out all incoming rubbish, and route it to various individual's (partner, daughter etc.) PCs. Cheers Robin -- Robin Birch

22 years, 3 months

Re: [pups] Progress on 2.11BSD kernel

by Steven M. Schultz

Hi - > From: "Ian King" <iking(a)killthewabbit.org> > I tried changing the partition type with disklabel -e -r but, when I exited > vi, I got an error message saying that the type I'd provided was not valid. > Viewing the label (with disklabel -r) showed the fstype set to 'unknown'. "unknown" or "unused" On my virtual 11 I see disklabel report: 8 partitions: # size offset fstype [fsize bsize] a: 16720 0 2.11BSD 1024 1024 # (Cyl. 0 - 39) b: 8360 16720 swap # (Cyl. 40 - 59) c: 340670 0 unused 1024 1024 # (Cyl. 0 - 814) h: 315590 25080 2.11BSD 1024 1024 # (Cyl. 60 - 814) > Just for grins, I tried modifying the drive type, too - no success there, > either. The disklabel utility isn't having any of that; again it claims > 'unknown'. Ah, that says something is corrupt somewhere. If you look at /usr/include/sys/disklabel.h you'll see the table of filesystem types: static char *fstypenames[] = { "unused", "swap", "Version 6", "Version 7", "System V", "2.11BSD", "Eighth Edition", "4.2BSD", "MSDOS", "4.4LFS", "unknown", "HPFS", "ISO9660", 0 }; So for 'unknown' to appear there would need to be a 10 in the type field instead of a 5 (for "2.11BSD"). 'unused' is a 0 obviously. Try booting up a standalone disklabel and see what it says without a kernel getting involved. Steve

22 years, 3 months

Re: [pups] Progress on 2.11BSD kernel

by Steven M. Schultz

Hi - > From: "Ian King" <iking(a)killthewabbit.org> > Now I know I'm missing something. I tried following your advice, using the > disklabel utility running under the old kernel. From what you say below, I Which part of the advice? ;) The part of the advice that might be most useful was to put a copy of the standalone disklabel program in / and boot it - NOT run the usermode version while the system is running. cd /sys/pdpstand make cp disklabel / then reboot the system and at the ':' prompt enter ra(0,0)disklabel there are things that can be done with the standalone version that are either impractical under a kernel (because the 'a'/root partition is open/busy) or because the standalone version has no safety checks. > assume you are referring to the 'fstype' parameter on the partition, not the > 'type' parameter for the drive, correct? The drive type is MSCP, and the > partition fstype is 2.11BSD. 'fstype' is what I had in mind. a: 16720 0 2.11BSD 1024 1024 # (Cyl. 0 - 39) > I tried changing the partition type with disklabel -e -r but, when I exited > vi, I got an error message saying that the type I'd provided was not valid. > Viewing the label (with disklabel -r) showed the fstype set to 'unknown'. Now I am confused. 2.11BSD is correct - but then it's "unknown" and that would cause the 'iinit' panic that started this thread of discussion. Down the path of logic that results in a 'iinit' panic and the 'no fs' there's a check for the filesystem type and "unknown" was the likely cause (or at least that was the hope). If the standalone disklabel program says it's "2.11BSD" then there's something else going on - the next likely thought is that 'rootdev' or related entity isn't set to the device that is the actual root filesystem. > Just for grins, I tried modifying the drive type, too - no success there, > either. The disklabel utility isn't having any of that; again it claims > 'unknown'. That's not used for anything important. > Oh well, while I'm waiting for your reply I can rebuild my kernel with a > higher MAXUSERS parameter. :-) ~12 is a good number - not much need for more than that as a rule. Steve

22 years, 3 months

Re: [pups] Progress on 2.11BSD kernel

by Steven M. Schultz

Hi - > From: "Ian King" <iking(a)killthewabbit.org> > Well, given the excellent advice I received here (especially from Steven > Schultz), I got the networking kernel to build after moving a few modules > around between overlays. It was indeed the overage on DATA/BSS that was Hmmm, if it was an overage on the DATA/BSS (which is hard to do unless you overdeclare MAXUSERS or the number of tty devices) then shuffling overlays wouldn't have made any difference since overlays affect only code and not data allocation. > Now, when I respond to the boot prompt with 'ra(0,0)unix', I'm getting the > following: > > <banner for the image, date, time, etc.> > panic: iinit > no fs on 5/0 That says the kernel was not able to mount the root filesystem. The earlier messages about the kernel build date, etc appear because the kernel prints those directly from internal strings (and the kernel is loaded by /boot who doesn't "mount" the root filesystem). > I'm booting from an RD54, and checking both 'ls -l /dev/ra*' and > /dev/MAKEDEV, it sure looks to me that the major device number for this > drive is 5 - am I missing anything yet? That's what I called out as the You're not missing anything so far ;) Are there other devices/controllers on the system? That should work (works on my system) but I'm trying to get a handle on what might be confusing the kernel. > for ra.) Note that this is exactly the same device as I have been using all > along with the GENERIC kernel, so I know there's really a filesystem there. That's the puzzling part - why the old one works but the new one doesn't. > (FWIW, I didn't define an autoboot device.) In ufs_subr.c, I see where this > message is apparently generated in the getfs() function, but I can't really mountfs() calls getfs(). mountfs() is called out of main() in init_main.c The panic "iinit" is in init_main.c after mountfs() has returned NULL The times I have seen the 'iinit' panic it's meant that the disklabel was either missing _or_ that the root ('a') partition was not of type FS_V71K. I SUPPOSE it's far fetched, but possible, that the old kernel predates the check for the filesystem type, thus it ignores the type of partition 'a' and assumes it's a valid filesystem. If you have a copy of the standalone 'disklabel' program installed in / you can boot that with ra(0,0)disklabel and examine the label that way. Or boot the tape and load the utility that way. Using the old kernel and running disklabel would work too. If the 'type' for the 'a' partition is not 'FS_V71K' that's the problem. > PS: I'm really glad I followed the advice to copy my old (GENERIC) kernel > image to 'oldunix' - so I can still boot! Ah, glad to hear that the advice came in handy. The other thing that comes in useful is a bootable Zip disk (complete 2BSD system fits on a Zip disk if one has a SCSI adaptor around) - came in handy when I corrupted/broke 'init' ... Steve

22 years, 3 months

[pups] Missing Base Kit Sistem Area Disk 1 in pro/venix 2.0 distribution (by DEC)

by Franco Tassone

Hi all, I have a Pro/venix 2.0 distribution (the one by DEC) and was going to reinstall it on my PRO/350. Unfortunatelly I discoveded that the Base Kit Sistem Area Disk 1 was bad. Anyone in this list can help me in supplying this floppy image ? Thanks in advance. Franco.

22 years, 3 months

[pups] Re: Condition of 2BSD

by Steven M. Schultz

Hi - I received a mail item from Johnny Billquist but the fine folks at Update.UU.SE don't seem to recognize that networks can be subdivided and that _my_ portion has never sent or relayed spam Hope Johnny doesn't mind the reply going here instead. ----- The following addresses had permanent fatal errors ----- bqt(a)update.uu.se (reason: 553 5.3.0 <bqt(a)update.uu.se>... SMTP from 64.32.150.18 blocked by Update due to spam sent/relayed from this network;contact postmaster at Update.UU.SE for details) ----- Transcript of session follows ----- ... while talking to tempo.update.uu.se.: >>> RCPT To:<bqt(a)update.uu.se> <<< 553 5.3.0 <bqt(a)update.uu.se>... SMTP from 64.32.150.18 blocked by Update due to spam sent/relayed from this network;contact postmaster at Update.UU.SE for details 550 5.1.1 bqt(a)update.uu.se... User unknown Hi! > I have a small question, which I hope you can clarify for me. I'm in a > little argument with a person involved in NetBSD. Ummm, I'm not a lawyer of course... > He claims that NetBSD is the oldest free BSD still alive, which I reacted > to since it was my belief that 2BSD now is free. But is 2BSD free? That I don't know. It is more free than it was a long time ago but > This have resulted in the claim that Berkley is the one that is > restricting 2BSD, which was news to me. Is this in any way correct? The > > * Copyright (c) 1986 Regents of the University of California. > * All rights reserved. The Berkeley software License Agreement > * specifies the terms and conditions for redistribution. That was the earlier version of the BSD license - when you had to have a ATT/USL/BellLabs license in order to obtain BSD at all. I am not sure I have a copy of the original UCB license but I think part of it involved having a ATT/USL license. The 'BSD' part of the UCB license permitted free sharing of the UCB portions of the system. The questionable parts involved the original ATT/USL code. If the current owners say that the original (non-UCB) portions are free then that means the entire system is free. > I believed that this was/is more or less the same as the current BSD > license (except that it still have the clause that any software > incorporating code from BSD must say so). At a later time the BSD license agreement added words about redistributing the code with or without modification as long as credit was given. > But appearantly this other guy is claiming that Berkley hasn't let 2BSD > free at all. I'm not sure UCB even knows what 2BSD is any more. > Can you clarify this for me, please? :-) Does the current state of the Caldera/SCO/whatever license override any existing licenses? THAT I do not know. If that is the case then I would say that 2BSD is indeed free, on the other hand if people are still legally constrained by the earlier license then 2BSD is not totally free. Earlier versions of NetBSD would not be free either because they contain "encumbered code" from the era when a ATT/USL license was required. I think it unlikely that anyone is going to send the 'software police' out to kick down a person's door because they're running 2BSD - sounds like that era is over at last. That's free enough for most people I think. Steve

22 years, 3 months

Re: [pups] Progress on 2.11BSD kernel

by Steven M. Schultz

Hi - > From: Johnny Billquist <bqt(a)update.uu.se> > Are the UMRs allocated and set up statically? The clist and buffer cache UMRs are initialized at system boot time. > (I haven't looked inside 2BSD for a while now, and can't remember much of > the internals anymore.) And I haven't been around a UNIBUS system for a long time and the memory of having to deal with UMRs has faded. > How many UMRs does the system use? 8 for buffer cache, you might expect > one or two DH11s, that would require a few more, ethernet takes another > few, but it seems there shouldn't be such a shortage. There are only 31 total - so a few allocated here, a few allocated there could result in not having enough. > What did I miss? Swapping. The kernel has to always be able to get UMRs to be able to swap out a process. The memory is fuzzy but I think the kernel reserved 7 as to be able to swap 56KB at a time of a process but it could get by with less. One UMR is 'reserved' by the hardware to cover the "I/O Page". The clist takes up 1 UMR for DMA terminal devices. Ethernet of course takes a UMR or two. At one time a couple of the ethernet drivers (DEUNA) were a bit braindamaged and allocated more UMRs than they needed - I fixed that though. MSCP and TMSCP devices need UMRs to map their command and response rings. The initial MSCP driver was definitely suboptimal in that regard - again, something I tended to (the problem showed up when more than 1 controller was present in a system). Those UMRs are permanently allocated at boot time by the drivers when they initialize. Tape drivers need to have UMRs (although I don't know of too many folks with the old TE16 drives around on a UNIBUS system) available. It started adding up and on a system with several types of devices each of which wanted to reserve a couple UMRs the available pool for dynamic use (by tapes and swapping) was sometimes too small. Cheers, Steven Schultz

22 years, 3 months

Re: [pups] Progress on 2.11BSD kernel

by Steven M. Schultz

Hi - > From: David Evans <dfevans(a)bbcr.uwaterloo.ca> > > OK. From what I recall (that turned-off machine again...) the entire > discussion on tuning MAXUSERS and friends is based on allocation of UMRs. > Might be a good idea to slip in a note about what to do when you don't have It is less a matter of MAXUSERS than it is of NBUF. NBUF sets the number of disc cache buffers. MAXUSERS affects the size of the proc table, file table, and other tables which are in the permanent (not mapped in/out) portion of the kernel's address space but does not affect the disc buffer cache which is the entity requiring UMRs on a UNIBUS system. The buffer cache must be entirely mapped by UMRs - so if you have a 32KB buffer the kernel will reserve 4 UMRs on a UNIBUS system. Realistically a 64KB buffer cache is about the maximum a UNIBUS system can have because that takes 8 of the UMRs. With the old (thankfully no longer in use, etc) 3Com ethernet boards you had to disable 4 UMRs so the system could access the memory in the card - that made for a very tight fit. The other constraint, even for Qbus systems, is the D space requirement. The 1KB portion of the disc buffer is "external" to the kernel (is mapped in/out as needed) but there is a header structure which is part of the kernel's permanent address space. Each buffer header is 24 bytes so even without UMRs around it's not feasible to have a 200KB cache because that'd use 4800 bytes of kernel D space (which is always on the edge of being overflowed it seems). On a 11/73 I've used a 100KB buffer cache but when I was using 11/44s and /70s the max was 64KB. Cheers, Steven Schultz

22 years, 3 months

Re: [pups] 2.11BSD "make unix" aborts Error 141

by Steven M. Schultz

Hi - > From: norman(a)nose.cs.utoronto.ca (Norman Wilson) > 0141 (octal) is 'a. 141 decimal is 0215 octal, i.e. carriage return with > parity. And I remembered that (correctly as it turns out) without looking at ascii(7) <g> > What seems more likely is that 141 decimal is 0200 + 13 decimal. If a > simple value returned by wait, that means SIGPIPE + core image, which > seems unlikely. If an exit status as displayed by the shell, it just It's, if I recall, being displayed by 'make'. There's no coredump so the interpretation of 0141 is that of an exit status. It's been a while since I've looked into the problem - it was quite annoying to run the sequence (that was causing make to cease) manually and not have it happen the same way. a 'shell' > means SIGPIPE (128 + signal number). Or is signal 13 different in 2.11 > than in V7? (That seems even less likely.) Ah, ok - that makes sense too. No, SIGPIPE is the same as it's always been since it was first defined as 13 > SIGPIPE doesn't seem entirely unreasonable as an accident that could > happen if something goes wrong in the assembly-language-code-tweaking > part of the kernel build. But something is causing the assembler to exit prematurely and break the pipe in the first place. SIGPIPE happens, of course, when a writer process writes to a pipe where the receiving/reading process has exited. 'as' is exiting prematurely - that can be determined by looking at the partially created (or empty) .s file that gets left behind. > Of course if it's a random value handed to sys exit, all rules are off. What might be needed is a decent (or existent ;)) syscall tracing capability. That combined with the capability to "coredump a non-0 exit process) might be enough to track down what's causing 'as' to depart the scene prematurely. Cheers, Steven Schultz

22 years, 3 months

Re: [pups] Progress on 2.11BSD kernel

by Carl Lowenstein

> From: David Evans <dfevans(a)bbcr.uwaterloo.ca> > To: "Steven M. Schultz" <sms(a)2BSD.COM> > Cc: pups(a)minnie.tuhs.org > Subject: Re: [pups] Progress on 2.11BSD kernel > Date: Wed, 19 Mar 2003 13:08:16 -0500 > > On Wed, Mar 19, 2003 at 09:51:10AM -0800, Steven M. Schultz wrote: > > Howdy - > > > > > From: David Evans <dfevans(a)bbcr.uwaterloo.ca> > > > This came in handy for me too when I went the route of messed up MAXUSERS > > > screwage. > > > > That'll do it too ;) > > > > Fortunately /vmunix & /oldvmunix is a familiar procedure from back in > my PMAX device driver hacking days. > > > > On another note, were there any SCSI adapters that made use of the BA23/ > > > BA123 RD disk control buttons? Would be nifty to swap in a new ra0 by > > > simply taking a disk offline/online. > > > > Hmmm, those buttons/cabling are for RD/MSCP devices - not sure if it's > > possible to use them with SCSI devices. > > > > I was thinking of a SCSI adapter that plugged into the bulkhead somehow. > This is plainly rediculous, but a nifty idea nontheless. You could put your SCSI drive into one of those pull-out "mobile adapter" things. But you probably should not pull it out without idling the SCSI bus first. carl -- carl lowenstein marine physical lab u.c. san diego clowenst(a)ucsd.edu

22 years, 3 months

Re: [pups] Progress on 2.11BSD kernel

by Steven M. Schultz

Hi - > From: David Evans <dfevans(a)bbcr.uwaterloo.ca> > I recall cranking MAXUSERS up a little, though I can't remember to Good Idea because the default is only suitable for single user mode and building a new/custom kernel. Quite a few kernel tables are sized based on 'maxusers' - in particular the coremap and swapmap tables (which track the fragments of memory and swap space) will be exhausted easily if you bring up a network'd kernel and start up the various daemons. > what and my PDP-11 is turned off at the monent. A clarification of > how the whole Unibus map register business effects Qbus-based systems > would be nice. It really doesn't - not having UMRs to deal with is a Nice Thing about the Qbus ;) The kernel (and the standalone utilities of course) need to know if they're on a U or Q-bus system but once a Q system is found then the UMR handling is bypassed. Cheers, Steven Schultz

22 years, 3 months

Re: [pups] 2.11BSD "make unix" aborts Error 141

by Carl Lowenstein

> From: "Steven M. Schultz" <sms(a)2BSD.COM> > To: pups(a)minnie.tuhs.org > Subject: Re: [pups] 2.11BSD "make unix" aborts Error 141 > List-Archive: <http://minnie.tuhs.org/pipermail/pups/> > Date: Wed, 19 Mar 2003 09:46:51 -0800 (PST) > > Hi - > > > From: David Evans <dfevans(a)bbcr.uwaterloo.ca> > > Ugh. > > > > Am I naive to suggest a rewrite of as? :) > > Just a little bit <g> > > It's a thought that used to occur to me fairly often a long time > ago. I cured myself of it though after I did the rewrite into > its current form (if you think it's bad now you should have seen it > before ;)). > > The biggest problem are the SDI (Span Dependent Instructions). The > PDP-11 has 'jmp' (non conditional but no range limit) and 'br' (many > flavors of conditional branches but with a +/- 128 byte range). > The compiler generates pseudo instructions like 'jeq' and leaves it > up to the assembler to figure out if a branch will reach or if a > branch around a jump is needed. That's a PITA to handle and is > I believe the cause of much ugliness in the assembler. That, of course, is a _neat feature_ of AS. On the other hand, how much code bloat would result if AS always emitted (bne;jmp) pairs for 'jeq', etc. Maybe only generate (bne;jmp) for forward 'jeq' where the span is not yet known. I am sure there are pathological instabilities in this kind of code generation, where expanding one branch/jump instruction makes another one go out of span range. Answer: 3:1 for each unnecessary pair. But I have no idea of the statistics for real code. carl -- carl lowenstein marine physical lab u.c. san diego clowenst(a)ucsd.edu

22 years, 3 months

Re: [pups] Progress on 2.11BSD kernel

by Steven M. Schultz

Howdy - > From: David Evans <dfevans(a)bbcr.uwaterloo.ca> > This came in handy for me too when I went the route of messed up MAXUSERS > screwage. That'll do it too ;) > I should track down the half-bezel so that I can mount this SCSI Zip drive I > have in my BA123. That would look so weird... It is tight on space but I can get a complete 2.11 system (with sources) and a small swap partition on a 96MB Zip disk. Not suitable really for going multi-user but as a single user mode system for fixing up /etc/init or building a kernel it's nice. Might not look too weird - different of course, who knows but what you might like the new look ;) > On another note, were there any SCSI adapters that made use of the BA23/ > BA123 RD disk control buttons? Would be nifty to swap in a new ra0 by > simply taking a disk offline/online. Hmmm, those buttons/cabling are for RD/MSCP devices - not sure if it's possible to use them with SCSI devices. Steven Schultz

22 years, 3 months

Re: [pups] 2.11BSD "make unix" aborts Error 141

by Steven M. Schultz

Hi - > From: David Evans <dfevans(a)bbcr.uwaterloo.ca> > Ugh. > > Am I naive to suggest a rewrite of as? :) Just a little bit <g> It's a thought that used to occur to me fairly often a long time ago. I cured myself of it though after I did the rewrite into its current form (if you think it's bad now you should have seen it before ;)). The biggest problem are the SDI (Span Dependent Instructions). The PDP-11 has 'jmp' (non conditional but no range limit) and 'br' (many flavors of conditional branches but with a +/- 128 byte range). The compiler generates pseudo instructions like 'jeq' and leaves it up to the assembler to figure out if a branch will reach or if a branch around a jump is needed. That's a PITA to handle and is I believe the cause of much ugliness in the assembler. So I'm fought the urge to rewrite the assembler and 'won' - I no longer feel the rewrite urges ;) Cheers, Steven Schultz

22 years, 3 months

Re: [pups] 2.11BSD "make unix" aborts Error 141

by norman＠nose.cs.utoronto.ca

Steven M. Schultz: It's the exit status of the assembler. On _some_ modules, the assembler ('as') jumps off into the weeds and executes an 'exit' system call with a non-zero value in R0. 141 is a lower case 'a' as I recall. 0141 (octal) is 'a. 141 decimal is 0215 octal, i.e. carriage return with parity. What seems more likely is that 141 decimal is 0200 + 13 decimal. If a simple value returned by wait, that means SIGPIPE + core image, which seems unlikely. If an exit status as displayed by the shell, it just means SIGPIPE (128 + signal number). Or is signal 13 different in 2.11 than in V7? (That seems even less likely.) SIGPIPE doesn't seem entirely unreasonable as an accident that could happen if something goes wrong in the assembly-language-code-tweaking part of the kernel build. Of course if it's a random value handed to sys exit, all rules are off. Norman Wilson Toronto ON

22 years, 3 months

Re: [pups] 2.11BSD "make unix" aborts Error 141

by Steven M. Schultz

Hi - > From: "Jonathan Engdahl" <j.r.engdahl(a)adelphia.net> > I'm running essentially the CURLY 2.11BSD system with networking on a Ah, yes - the 'master reference 2.11BSD system' ('SHEMP' is a virtual pdp-11 running under P11 ;)). > PDP-11/53. When I go to rebuild unix with "make all", the build will run for > a while, then quit with "Error 141". If I type "make all" again, it keeps on Yep, I've been seeing that for years and aside from some kernel hackery to assist in the debugging I haven't done much other than to come up with a workaround. > going for a while. After several iterations of this, eventually the make > completes, and the system will boot the result. What is this "Error 141" > business? It's the exit status of the assembler. On _some_ modules, the assembler ('as') jumps off into the weeds and executes an 'exit' system call with a non-zero value in R0. 141 is a lower case 'a' as I recall. Now for the interesting part. If you do something like setenv FOOBAR abcdef and run the make the assembler won't "exit 'a". ALSO, if you run the pipeline of the failing command manually, using temp files, it won't fail. Makes it very hard to debug. > I've not looked for the cause of this yet. I'm being lazy, and hoping > someone has seen this before and can give me a quick answer, before I go I'm lazy too (I hear that being lazy is a virtue in programmers ;)) so I just pad the environment with "FOO abc" or something and the make works. The only idea I've come up with to try and track the problem down is a hack to the 'exit' logic in the kernel to create a coredump of a program that exits with 'non-zero' status. Then at least there'd be something to postmortem. An added complication is that the assembler has this nasty habit of using 'jmp' to move around rather than 'jsr' so it's hard to find out where the program was at times. A long time ago I did make a few changes to 'as' to reduce the usage of 'jmp' in an attempt to track this down but then, when even I ran the program under the debugger it never failed - a typical Heisenberg type of bug ;( Good Luck. Steven Schultz

22 years, 3 months

[pups] Progress on 2.11BSD kernel

by Ian King

Well, given the excellent advice I received here (especially from Steven Schultz), I got the networking kernel to build after moving a few modules around between overlays. It was indeed the overage on DATA/BSS that was killing my build. I did a 'make install' and sync'ed, then restarted. <sigh> Now, when I respond to the boot prompt with 'ra(0,0)unix', I'm getting the following: <banner for the image, date, time, etc.> panic: iinit no fs on 5/0 I'm booting from an RD54, and checking both 'ls -l /dev/ra*' and /dev/MAKEDEV, it sure looks to me that the major device number for this drive is 5 - am I missing anything yet? That's what I called out as the ROOTDEV in my config file (in sys/conf), with '5,1' as the SWAPDEV. (I snuck a peek at the CURLY config file as well, and it shows major device 5 for ra.) Note that this is exactly the same device as I have been using all along with the GENERIC kernel, so I know there's really a filesystem there. (FWIW, I didn't define an autoboot device.) In ufs_subr.c, I see where this message is apparently generated in the getfs() function, but I can't really tell from that where it's biting me. Hey, if it wasn't a challenge, it wouldn't be fun, right? Right? TIA -- Ian PS: I'm really glad I followed the advice to copy my old (GENERIC) kernel image to 'oldunix' - so I can still boot!

22 years, 3 months

Re: [pups] 2BSD build problem - unix.o not too big

by Steven M. Schultz

Hi - > From: David Evans <dfevans(a)bbcr.uwaterloo.ca> > > I don't recall seeing any overlay info when I set up my 11/73 back in > January. I even asked the dreaded overlay FAQ here! :) I was also at 431. Ok, I probably only thought about including the writeup in the documentation. I know I did write up a moderately lengthy article about dealing with the overlay setup in response to a problem someone was having. I just never went and incorporated it into the setup/installatino documentation ;( One thing, obvious now that I think of it, I forgot to mention last night is that "too big for type 431" can also happen if the D space total is too large. If 'MAXUSERS' is set too high for example then more than 48KB of D space will be needed and the linker will complain. Look at the sum of the DATA and BSS segments (it might be necessary to sum up the .o files individually) - if it's pushing 48KB then that's the problem. Cheers, Steven Schultz

22 years, 3 months

Re: [TUHS] SCO & Caldera?

by Christian Groessler

Hi, On 03/12/2003 10:18:33 AM ZE10B "Greg 'groggy' Lehey" wrote: > >On Wednesday, 12 March 2003 at 9:27:13 +1000, Warren Toomey wrote: >> >> So the new license specifically prohibits System III, whereas the >> Ancient UNIX license implicitly permitted System III. > >Heh. So we have something to show for our $100 after all :-) Is System III somewhere in the archive for us $100 license owners? regards, chris

22 years, 3 months

Re: [TUHS] SCO & Caldera?

by Warren Toomey

On Tue, Mar 18, 2003 at 03:31:55PM -0800, Andru Luvisi wrote: > I don't have the $100 license, but I did get one of the click-through > licenses. Then I assume you would be safe to download SysIII from the SCO/Caldera page, as long as the license covers that. Warren

22 years, 3 months

SysIII from SCO/Caldera

by Warren Toomey

8-) Looks like Caldera are quite happy for you to obtain SysIII without signing any license agreement. http://www2.caldera.com/offers/ancient001/sysIII/ This is just a FYI. You would have to consider your legal position if you did decide to download it. Warren

22 years, 3 months

Re: [TUHS] Russian Ancient UNIX stuff in the Archive

by msokolov＠ivan.Harhan.ORG

Sven Mascheck <sven.mascheck(a)student.uni-ulm.de> wrote: > Then the following might be an option, /UnixArchive/Applications/Ritter_Vi/ > > "This is basically ex/vi 3.7, 6/7/85, from the 2.11BSD distribution" > "A larger addition is the ability to handle ISO character sets." > > (recent development continued on <http://ex-vi.berlios.de/>) Where can I get the early versions of this effort? http://ex-vi.berlios.de/Changes lists at the very bottom: : Release 31/05/00 : * String extraction using mkstr and xstr is not longer be done. : * An ANSI C preprocessor may be used. : * Changes of symbol names due to collisions on newer systems. : * Fixed a null pointer reference in ex_tty.c. : * Included the 2.11BSD termcap in a subdirectory. Ex could use any : termcap library, however, that does not use malloc(). : * Support of eight bit characters excluding the range 0200 to 0237 is : enabled with -DISO8859_1. It does not include the regular expression code, : but otherwise works well in practice with the ISO-8859-1 character set. And all the newer stuff up to late 2002 is porting to "modern UNIX". But I don't want "modern UNIX", I'm running the original UNIX in its virgin form, I just want the 8-bit fix. The only files downloadable from ex-vi.berlios.de are 2002 releases and in the UNIX Archive Applications/Ritter_Vi contains only a tiny README file pointing to http://ex-vi.berlios.de/. Where are the old 2000 versions? MS

22 years, 3 months

Russian Ancient UNIX stuff in the Archive

by msokolov＠ivan.Harhan.ORG

Hi there, I remember seeing in the Unix Archive a few years ago (back when the $100 licenses just came out and it was called PUPS Archive) some Russian Ancient UNIX stuff, some things contributed to the UNIX community by the early Russian UNIX users (on Soviet PDP-11s). However, I am now looking for it and cannot find it. Would anyone have a pointer? I am trying to russify my flagship UNIX (4.3BSD-Quasijarus) and I'm adding/ fixing 8-bit support in various parts of the system, and I got stuck on ex/vi. The sucker just won't handle 8-bit chars. Since my job is to maintain Ancient UNIX (my flavor thereof) rather than replace it, replacing the original ex/vi with one of the modern reimplementations is not an option. I need to massage 8-bit support into the existing original Berkeley ex/vi with as few changes as possible. A friend of mine told me that Back in The Days the first UNIX users in the then USSR were running patched (russified) 2.xBSD on Soviet PDP-11s and had KOI-8 for Russian. Since the flagship editor on <any>BSD is ex/vi, this makes me think that those early Russian users used it and thus their patches accomplished just what I need. And so I'm looking for those patches. TIA for any help, MS

22 years, 3 months

Re: [pups] 2BSD build problem - unix.o not too big

by Steven M. Schultz

> From: "Ian King" <iking(a)killthewabbit.org> > I'm building a 2.11BSD kernel on my 11/73 (so I can include the networking > code and put my machine on the LAN!), and I'm seeing the error "too big for > type 431". Through the wonders of Google, I saw your discussion of this > error and followed your advice (from 1996!). However, when I ask 'size I'd have, up to now, sworn that the overlay setup was in the documentation (one of the appendices) but it could well be that it's still off in a file somewhere in the mess I call my filesystem ;) > unix.o', I get a size comfortably within the limits for base - 50112, well > below the 57344 you cite. None of the overlays exceeds 8192, and the 'total > text' figure is well below your example, too. FWIW, I did a 'naive build' Do you have any 0 length overlays? There can't be any gaps in the overlay structure. For example, this is legal: overlays: 8128,7552,8000,7296,8192,7424,5824,6784,3520 but this is not: overlays: 8128,7552,8000,7296,8192,0,5824,6784,3520 > first, copying GENERIC and changing a few parameters; after seeing the error > 'text segment too big' I went through the config file with a little more > thought and eliminated drivers I clearly didn't need (I don't have RL01/02s, You might need to go thru the Makefile too. Good idea to eliminate drivers you don't have (save their D-space requirements) but that can create empty overlays and that does not work. > for instance). Then I started getting this error. I did a 'make clean' > just to be sure, but still make gives me the 'too big for type 431' error. > (Yes, I RTFM on ld.) Hmmm, patch level 431 is recent enough I'd have thought to avoid a 'ld' problem (current is 444 but nothing recently has touched ld). What is the output from 'size unix.o'? Cheers, Steven Schultz

22 years, 3 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