srg@uw-apl.UUCP (Spencer Garrett) (05/01/87)
I've just installed 4.3 BSD on a Microvax II. Everything seems happy except the ethernet. If I do an ifconfig in rc.local then the system hangs on boot. If I let the system come up without that and do the ifconfig manually then the ethernet works for a while before the system hangs. The cpu seems healthy and the DEQNA board is an F1 revision and works in another Microvax running Ultrix. The processor doesn't halt (CR to a waiting getty elicits another login prompt) but the system will stop processing commands. I suspect that some critical system resource is remaining locked, so trivial syscalls like a write to the terminal succeeds, but not fork or exec. I haven't gotten named working yet, but /etc/hosts seems to suffice in its absense. I can't believe the Berkeley code would be DOA like this, but then the generic kernel on our tapes claimed it hadn't been configured for this cpu type. Simply building a new kernel solved that, but I've run out of ready ideas about the ethernet problem. Does anyone out there have any ideas? srg@june.cs.washington.edu or beaver.cs.washington.edu!uw-apl!srg
larry@utecfb.UUCP (05/04/87)
We had similar problems when we first brought up 4.3, and it turned
out that the whole problem was a result of the nameserver. First
when you run ifconfig with a symbolic name such as
ifconfig lo0 localhost
the gethost* routines will try to connect to named to find the
address for localhost. Unfortunately, the gethost* routines connect
to the named using localhost.port#, thus they will hang for 45 seconds
(the network timeout interval) before giving up. If you have several
ifconfig's in a row, then they will hang one after another.
I gets worse also because the internal named timer for trying to get
information from another nameserver is 3 minutes! Thus it is likely
that your system did not really hang, you just did not leave it alone
long enough to get past all the timeouts in rc.local
We solved the problem by not putting any symbolic names in ifconfig
lines. Make the host addresses real internet addresses like
ifconfig lo0 127.1
and the system will come up. Individual progarms will still hang if
named is running, but is not configured properly. You should comment
its invocation out of rc.local.
One last thing, I am not in charge of the nameserver stuff around here,
but I am close enough to know the thing has evolved a lot since the
version which went out on the 4.3 tape. You should try to obtain
a newer version, although I don't know where you can get it from.
There is a mailing list out there somewhere that discusses bugs/fixes
for the beast.
Larry Philps Engineering Computing Facility University of Toronto
NEW PATH: larry@ecf.toronto.edu
USENET: {linus, ihnp4, allegra, decvax, floyd}!utcsri!ecfb!larry
CSNET: larry@Toronto
ARPA: larry%Toronto@CSNet-Relay
BITNET: larry@ecf.utoronto.BITNETdan@maccs.UUCP (Dan Trottier) (05/14/87)
In article <144@utecfb.Toronto.Edu> larry@ecf.toronto.edu (Larry Philps) writes: >We had similar problems when we first brought up 4.3, and it turned >out that the whole problem was a result of the nameserver. First >when you run ifconfig with a symbolic name such as > ifconfig lo0 localhost >the gethost* routines will try to connect to named to find the >address for localhost. Unfortunately, the gethost* routines connect >to the named using localhost.port#, thus they will hang for 45 seconds >(the network timeout interval) before giving up. If you have several >ifconfig's in a row, then they will hang one after another. >... >We solved the problem by not putting any symbolic names in ifconfig >lines. Make the host addresses real internet addresses like > ifconfig lo0 127.1 >and the system will come up. Individual progarms will still hang if >named is running, but is not configured properly. You should comment >its invocation out of rc.local. >... We had the same problem here at maccs (McMaster Univ. Comp. Sci.). I spoke with Keith Bostic (at Berkeley) and got our system up and running using the same method as Larry Philps tried. Keith did mention that a patch for this problem -- Keith didn't refer to it as such -- should appear soon in "ucb_fixes". Besides the networking problem the only glitch in bringing 4.3 up was the changed nameming convention in the /dev directory and the disk partition changes with regard to the RA81 drives. (does anybody know if 4.3 handles bad blocking any better on these drives?) One more question, in our distribution (VAX 11/780, full source) there seems to be missing the crypting ability. For example vi doesn't recognize the "-x" option anymore and xsend, xget, and enroll are missing. Now we had and still have these utilities from 4.2 and will be using them but what I would like to know is how come they are not in my distribution. Maybe I should ask if any of you that have 4.3 have received the encryption utilities. I think I remember something about DES encryption algorithm being changed. Could it be that it is now classified and cannot be distributed with foreign orders. This is all very silly if this is the case. -- Dan Trottier | seismo!mnetor!{genat|lsuc}!maccs!dan DCSS, McMaster University | dan@mcmaster.BITNET Hamilton Ontario Canada | Tel: (416) 525-9140 ext:3444 L8S-4K1 |