philip@cel.cummins.com (Philip D. Pokorny) (06/29/91)
We recently had a disk go bad on us... The node was running
SR10.1 and had several of our cross-compilers and other tools on
it. We had good backup and so just restored the files to another
machine on the network while we figured out what to do with the
disk. After changing the links on the network to point to the
new locations, everything should be fine right?... Wrong...
The old machine was a DN3000 with SR10.1. The new machine is a
400t running SR10.3. The compilers run fine at SR10.3 on the
400t and I believe they run fine on a DN2500 at SR10.3, but on
DN3000's at SR10.1 I get:
$ /tool/sdsi/cmd/as6805 aknow.c -o test.o
?(sh) "/tool/sdsi/cmd/as6805" - absolute load address already occupied (process manager/loader)
$ tb -full
Process 28813 (parent 25204, group 0)
Time 91/06/28.13:07(EST)
Program //eagle/tool1/sdsi.v50/cmd/as6805
Status 03030013: absolute load address already occupied (process manager/loader)
No traceback available
Proc2 Uid 527212AA.F0015778
Parent Process 25204 (52714426.50015778)
Process Group 0 (52714426.50015778)
No fault status saved in this dump
It seems like I would have seen this before. I was the one that
ported this software for the vendor (They sent me source, I sent
them the executables) and their test suite ran like a charm...
(I used the 6.7 compiler, maybe on a 400/10.3 or 3000/10.1) Does
this trigger any memories for anyone??? Seems like an obvious
problem that should have been seen before...
Thanks,
Philip
philip@cel.cummins.com
PS. I suppose that this is probably documented in the release
notes somewhere but I thought I'd give the USENET a shot before
I go digging in the documentation. (So I haven't RTFM...)
:)