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
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
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!
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
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
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
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
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
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
> 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
