TUHS

tuhs@tuhs.org

61 participants
6532 discussions

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

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