"asbesto" wrote:
> 1) a 74LS175 chip named E15 on our schematic diagram, that seem
> phisically BROKEN on an edge (there is a fessure on the plastic
> DIP package). i can't change it now because i don't have a
> soldering station here to do a nice job, but looking the chip i
> think it may work...
I never remove IC's in *one* go. The chances that you damage the
multi-layer board beyond repair are real. This is what I do.
I use a dremel tool (small motor with sharp rotating blade) to
cut the pins of the IC one by one.
Don't use a cutting tool to cut the pins because the side force
might push the remainder of the pin through the solder joint
thus damaging the board.
After you have cut all the pins the IC just falls of the board.
Now, you can use a fine hot soldering iron and remove the pins
one by one use a pair of squeezers.
good luck with your repairs,
- Henk.
well,
some months ago i asked for help booting a pdp11/34 here at
freaknet medialab :)
well, i think now we have a more complete knowledge of the REAL
problem !
the M7891 board (128K x 18 bit MOS MEMORY MODULE) have the D2 red
led light turned ON when turning on the CPU !
this means PARITY ERROR on this board :(
checking the board we found 2 problems:
1) a 74LS175 chip named E15 on our schematic diagram, that seem
phisically BROKEN on an edge (there is a fessure on the plastic
DIP package). i can't change it now because i don't have a
soldering station here to do a nice job, but looking the chip i
think it may work...
2) a 5 Kohm 4-resistor bridge named R22 on our diagram, that is phisically
BROKEN. this bridge give +5V on signals named DATA OC L, CSR OC L, OC L
and X ADD OC L. i changed it with a 4.7Kohm 4-resistor bridge, without
any result. (maybe the 74ls175 is really broken :)
an other ipothesys may be: some electrolitic capacitor in short circuit.
we had this problem on a decwriter III ! :)
the real problem is: if we aren't able to repair the M7891 board, where
can we find a "new" one ???
can somebody help us ? it's a shame for us to have our pdp11/34 offline :((
any help is appreciated ! *:)
--
[asbesto : freaknet medialab : radio#cybernet : GPG key on keyservers]
[ MAIL ATTACH, SPAM, HTML, WORD, and msgs larger than 95K > /dev/null ]
[http://www.freaknet.org/asbesto :::::: http://kyuzz.org/radiocybernet]
Hi All,
I know that this isn't pdp related but the people are here who know :-). Is there
an available unix that supports lance and dssi on a VAX 3400 and/or is there anyone
working on this.
Regards
Robin
This email and any attachments are confidential and intended for the addressee
only. If you are not the named recipient, you must not use, disclose, reproduce,
copy or distribute the contents of this communication. If you have received this
in error, please contact the sender and then delete this email from your system.
while trying to build Franz Lisp (from 4.3 BSD) on VAX/ULTRIX 4.5,
I noticed its peculiar list of supported platforms:
use: lispconf type
where type is one of
vax_4_1 vax_4_1a vax_4_1c vax_4_2 vax_4_3
vax_eunice_vms
sun_4_1c sun_unisoft dual_unisoft pixel_unisoft
sun_4_2beta lisa_unisys3 mc500_2_0
I was especially surprised by "lisa_unisys3". is that Unisoft SysIII
for the Apple Lisa?! and does anyone know what
{dual,pixel}_unisoft and mc500_2_0 mean?
--
If I travelled to the end of the rainbow
As Dame Fortune did intend,
Murphy would be there to tell me
The pot's at the other end.
Lars Buitinck
I'll have to try this with the RQDX3 as primary and the SCSI as secondary.
Maybe BSD is smart enough to do it right. In any case, I have the source for
the BSD boot code, and I can fix it. It will be a pain, though, having to
type the alternate address every time I boot BSD. I'd probably have to
restructure /dev and /etc/fstab also, and who knows what else. Maybe it
would be easier to change the jumpers if I needed to run RT11. I don't use
RT11 that much, but I'd like to have it available.
--
Jonathan Engdahl
http://users.safeaccess.com/engdahl
"The things which are seen are temporary,
but the things which are not seen are eternal." II Cor. 4:18
----- Original Message -----
From: "Fred N. van Kempen" <Fred.van.Kempen(a)microwalt.nl>
To: "Jonathan Engdahl" <j.r.engdahl(a)adelphia.net>
Sent: Wednesday, April 02, 2003 5:58 AM
Subject: RE: [pups] booting RT11 from alternate controller
Jonathan,
> I have a PDP-11/53 with a SCSI controller at 172150, and an
> RQDX3 at 172144.
This works for the ROM, but most PDP-11 operating systems will
refuse to boot from anything but the "default" controller of
any kind, meaning, an MSCP controller it will only accept at
172150. The OS itself can deal with them, but not so for the
boot-level code that loads them.
I have tried similar setups with an 11/83 using an ESDI disk
controller at MSCP #0 (doing KDA50 emu), and an RQDX3 at
MSCP #1 (just for the floppies, indeed) and that didnt work
either, with RT11, MicroRSX and Ultrix.
--f
I have a PDP-11/53 with a SCSI controller at 172150, and an RQDX3 at 172144.
There are a couple SCSI drives on the primary controller, and an RX50 on the
RQDX3. Everything seems to work OK, and I can read the floppies, except I
cannot boot RT11 from a floppy. From the 11/53 boot ROM you can say
B/A DU0
It will then ask for the address of the alternate controller. It reads from
the floppy, then it reads from both hard drives, then hangs.
What I hunch is happening is that the boot ROM reads the RT11 boot sector
from the floppy, but then the boot sector tries to continue booting from the
hard drives, which isn't going to work, because they are 2.11BSD formatted.
The objective is to have some non-RQDX3 hard drive controller as the
primary, and a secondary RQDX3 for the floppy, and to be able to boot UNIX
from the hard drive, and RT11 from the floopy. Any ideas on how to
accomplish this?
--
Jonathan Engdahl
http://users.safeaccess.com/engdahl
"The things which are seen are temporary,
but the things which are not seen are eternal." II Cor. 4:18
Helbig remarked (quoting Davidson):
> >Yes, you are right - V7 restores the register variables to a state which
> >is consistent with the other auto variables in the function - ie the value
> >which they had when longjmp was called.
> >
> >The caveats about not relying on register variables applied to V6.
> Nope, even in V6, register variables are restored to the values they had
> when reset(III) was called! (reset() is the name of longjmp() in V6).
> By the way, reset() is much smaller than longjmp() but provides the same
> functionality.
> I wonder why longjmp() was rewritten.
Setjmp/longjmp do more (setjmp returns different values
for the initial call and the longjmp-invoked one).
But the thing that would become more important
is that the PDP-11 compiler's calling sequence was
especially friendly toward restoring register values--
it just worked automatically.
Other machines and compilers were not so friendly.
This is why ANSI and ISO had to put in special rules
about promising to preserve only things marked
volatile.
We've been through this before.
Dennis
>X-Unix-From: michael_davidson(a)pacbell.net Tue Dec 31 17:04:50 2002
>Date: Tue, 31 Dec 2002 08:02:37 -0800
>From: Michael Davidson <michael_davidson(a)pacbell.net>
>User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4)
Gecko/20011128 Netscape6/6.2.1
>X-Accept-Language: en-us
>MIME-Version: 1.0
>To: Wolfgang Helbig <helbig(a)Informatik.BA-Stuttgart.DE>
>CC: pups(a)minnie.tuhs.org
>Subject: Re: [pups] V7 setjmp/longjmp
>Content-Transfer-Encoding: 7bit
>
>Wolfgang Helbig wrote:
>>You can trust register variables when setjmp() returns the second time. Then
>>the registers are restored to the values they had when the "next" function was
>>called, that is the "values as of the time longjmp() was called" (quoted from
>>longjmp(3)'s man page. Thus any variable behaves the same, regardless of its
>>storage class.
>>
>Yes, you are right - V7 restores the register variables to a state which
>is consistent with the other auto variables in the function - ie the value
>which they had when longjmp was called.
>
>The caveats about not relying on register variables applied to V6.
Nope, even in V6, register variables are restored to the values they had
when reset(III) was called! (reset() is the name of longjmp() in V6).
By the way, reset() is much smaller than longjmp() but provides the same
functionality.
I wonder why longjmp() was rewritten.
Wolfgang.
On Mar 21, 19:31, Ian King wrote:
> Yup. I used to do that, but had an older version of sendmail and got
> 'co-opted' as a relay host for a spammer. :-(
I've seen a few attempts to do that. I should point out that even if
you only run sendmail for the benefit of machines on your own network,
and even if you use a dialup (rather than always-on) connection, you
want the ant-relay stuff. I see regular attempts to connect to port 25
on my hub, even though it's behind a dynamic IP address on an ISDN
dialup (I also see regular attempts to connect to the telnet, ssh, and
ftp ports, and others, maybe 2-3 times a week. If you run a common
operating system, don't assume that a dynamic IP address, or NAT, or
using a dialup, gives any worthwhile protection).
> FWIW: rather than update sendmail and hack another .cf, I bought a
> Windows-based mail server
Nowadays, it's easy to use m4 to set up sendmail.cf for the common
sorts of home use -- just define the settings for masquerading and
smarthost, and press go (more or less). The only time you need to hack
it a bit is if you want something unusual, like some mail going to the
local machine and some forwarded to other machines on your network, or
using UUCP.
> Instead, I use my free time to hack 2.11BSD and UNIX v6! :-)
I have to admit that sounds like a better use of the time :-)
--
Pete Peter Turnbull
Network Manager
University of York
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
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
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
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
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
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.
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
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
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
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
> 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
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
> 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
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
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
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