From: quillen@orion (John Quillen)
Subject: Re: SCSI/CAM problems
Organization: Fox Chase Cancer Center
Date: Mon, 14 Sep 1992 13:17:50 GMT

I tried installing the SCSI/CAM driver on a 5000/200 that we had just installed
4.2a on, but hadn't put into production (we swapped in a 5000/240).

After discovering that I couldn't boot a kernel with "swap on boot" in the
config, I reconfigured for "swap on rz0b...".

I got a slew of errors trying to do a dump to an Archive Python and decided
to just forget it.  I was really looking forward to a new SCSI driver, we've
been having dumps hang occasionally and I was hoping this would take care
of the problem.  I didn't examine the errors because I felt there shouldn't
have been any, since I wasn't doing anything out of the ordinary.

In article <1992Sep8.171248.21775@decvax.dec.com> jag@zk3.dec.com writes:
>In article <Bu862I.Dq@ie.utoronto.ca>, andy@ie.utoronto.ca (Andy Sun) writes:
>>john@iastate.edu (John Hascall) writes:

>>>I was told that backing out of SCSI/CAM was NOT as simple as
>>>just "setld -d ..."  If we can't get a fix by next week we are
>>>resigned to going backwards to 4.2a.
>>OH MY GOD!! (fainted...)
>    No No No (waving ammonia salts ...), only for the CAMBASE* subset is
>there a problem.  For the kernel, a delete and a rebuild is all that is
>needed.
I have to disagree.  There were at least 8 objects missing from
/sys/MIPS/BINARY.  I found them one at a time by running make until it
failed with "don't know how to make ../../BINARY/autoconf.o", etc.  And
copied each binary over from another 4.2a machine.  After all of that,
I think I wound up giving up because it appeared that various header and
C files (I think machine/common/conf.c was the final straw) were considerably
different and I punted and reinstalled UDTBIN420 & UDTBIN425.  I copied
/usr/etc/uerf{,.bin} over from another machine, and still have to get dump
and mt.

(find just revealed to me that all of the .h's and .c's were saved as .nocam.
I used files.mips.nocam and looked for BINARY/*.o.nocam (which weren't there).
At that point it didn't occur to me to look for machine/common/conf.c.nocam.)

Hint: To anyone out there who doesn't know, check through /usr/etc/subsets 
(CAM*.inv, UDTBIN*.inv) to see what subsets things came from.

>    I for one want to get this to work.  We have spent a lot of engineering
>time and effort to make this new subsystem.
I appreciate your efforts, but I must say, I was truly disappointed.  I would
much rather waited 6 months for something usable, that wouldn't have wasted
so much of my time.  I tend to expect, and am willing to work through, problems
with software packages and I'm sorry for my attitude in this post.  But we
just can't afford problems like this at the OS level, especially on something
that the hardware depends on.  We were fortunate that we had a machine that no
one was counting on being up at the time I tried this.

It's getting to the point where I'm just not going to install n.0 of
anything:-(

John
-- 
------------
John Quillen  JW_Quillen@fccc.edu  Phone: (215) 728-3660  FAX: (215) 728-2513
Research Computing Services / The Fox Chase Cancer Center / Phila. PA, USA
        "The world is full of apathy ... but who cares?"  R. Murphy
Newsgroups: comp.unix.ultrix