[SunRescue] NetBSD 1.4 miniroot problem fixed

[BSD Bob]

> >Well, there is nothing that bad with a high end 3/xxx machine.  Sadly,
> >all I have in that line are a 3/110 and a 3/260.  They are more of
> >the plebian class machine.
> 
>    The 3/2xx is nothing to sneeze at. It's the second fastest 3/ and can be
> loaded up with 100M+ of RAM.

Ohh, I did not thing it rated that high.....hmmm, mebbie I will have to
reinvestigate its potential.  Iff I can  somehow hang 4 big drives and
the tape and maybe a reel-to-reel off her, she might make a  good little
home server, then....   I was using the 4/260 for that.  But, I may have
to try the 3/260, since I have more spares for that class machine than
the 4 machines.

> ......  I am beginning to wonder if the interposer controllers may
> >be part of the scsi timeout problem.
> 
>    I have 1.4 running on two 3/50's and a 3/60, and they are all
> MD21 systems. No problems with the MD21. Out of the three, two units
> report phantom drives on LUN 1, but NetBSD recognizes them as being
> offline, so no harm done. I don't use tape drives at all anymore, so I
> don't know how those work.

I love that phantom drive syndrome.  I have to order drives by skipping
to every even ID position.  I sense it is that md21 thing.  Maybe it
would be good to yank those and put in regular scsi drives.   Large
ESDI drives are getting hard to scare up, anymore.

Most of the problem I was having was inordinately slow tape operations.
It took two days to do a simple root dump of 15M.  It was too slow to
do anything with, and I still do most of my backups and archiving to
1/4 inch cartridges (I cornered the market one time and have a lifetime
supply of the mothers...(:+\\...).  They work, they are mostly reliable,
and can be read on almost anything if you can somehow mount a drive up.
Almost as good as reel-to-reels.  Of late, though, I have been using
a sparcbook as a portable ``tape'' dumper, so maybe my need for a hard
copy on QIC cartridges may lessen slightly.  If it can't grok tape,
I feel like it has not gotten out of training unix wheels, yet.

.....
 
> ..... (I have an old SUN0207 which I'm using
> as my magic install disk.)

Great idea.... I keep a spare drive set up for my VAXen, but had not
thought about that for the suntoyz.  I should probably do that.  I
have a spare applecrate that I could throw one of those 200mb things
in and use that as a portable booter.  How have you got yours ID'd
and set up?  Is it a live bootable system, or just a miniroot on swap?
 
.....

>    Well, 1.4 seems to work fine on my Sun-3's, but as stated it's
> seriously broken on old VME Sun-4's. 1.3.3 booted fine on my 4/2xx, and
> it seemed to be stable as long as I didn't exercise the disks too hard.
> Breaking up a long string of back-to-back activity by pausing the
> process for a second or two seemed to allow it to catch its breath.
>    I suppose, if one wanted a really crude hack, one could add a counter
> to the sd driver and have it insert pauses after a certain number of
> rapid-fire requests, or something. Maybe turning off DMA would work,
> since it was a DMA timeout that would crash it.

This was what I was wondering about the clock speed for the CPU.
The sun3's run at 12/16/25(?) mhz, and the 4/260's are at around
25/30 somethihng?  What if you half clock the cpu?   Will that
allow enough time for the scsi to settle?  If that is the case,
does the code need a wait loop for a couple of instructions to
allow the scsi to catch up with the cpu?  Nothing fancy, but just
a millisecond or two.  I remember hand patching CP/M in the ancient
days with nops in critical places to get the floppies stable.
That scsi thing is indeed a black art.....(:+{{.... and those
sun vme crates must require Merlin's calibre of black art.

I am wondering if it is possible, assuming the sun3 code works,
to just borrow back that code into the sun4 port instead of the
later sparc code.  That would require keeping the sun3 and sun4
ports together and separate from the later sparc ports.  Oyyy,
another port to worry about.  But, if there are a few diehards like
us that really do want to run the old vme hardware, maybe that would
be a worthwhile thing to try.

>    The worst problem with SCSI is that it's a black art. I have had
> systems which would not operate if terminators were installed, which is
> kind of backward, and others that required terminators, which is at
> least expected. Some would only operate with particular cables in
> a particular order -- take the same cables and rearrange them and
> kablooey! And of course, just about anything will appear to operate for
> a little while, so you're left guessing whether a problem is systemic or
> just a fluke, and if it's systemic whether it's the controller, cables,
> disk, software, VME chassis...

I heard one fellow suggest that it was the db50 connectors that were
responsible.  Something about the electrical properties of them being
maybe good for scsi1 but later it could not handle well.  Connector
stray capacitance or insulation leakage maybe?  Anyone know for sure?

I can never seem to get two of the DB50 cables on-line in series on
the scsi bus.  One is fine, but the second one blows up.  I have been
thinking of changing the connectors off the scsi board from that DB50
thing to a centronics or Honda mini-50 and trying that.   I have also
thought of just making up one cable, and routing it off the board dip
header and not even using that backplane passthrough bus and cable.
Anyone ever tried something like that?  I sense all those bus connectors
between cables might cause instability in the bus operation.

>    (I have at least learned the great secret of VME chassis: rubber
> mallet! If you just slide a board in, it will appear to be seated but
> it's really not. It's easiest to demonstrate this in a middle slot of
> an empty chassis. If you just slide the board in, it looks OK, but
> notice that it requires essentially no force to slide it back out.
> However, if you slam the board in, it suddenly requires a good deal of
> force to pull out. Slamming it in by hand is easy enough in an empty
> chassis, but a nice rubber mallet is handy for seating cards in a full
> box. I just wish I'd learned this years ago.)

One comment on that, though,  you need to be very careful not to bend
a pin on the cards.  I had one that got bent over and flat inside the
connector, and it took me forever to find it.  It got bent from sliding
it in too fast, and having it be just off the hole enough to cause that
pin to fold.  I usually line the board up, then slide it about 3 inches
from seated, then slide it in with a low-speed push.  That seems to
give it enough mass acceleration to  seat well, and not crunch pins.

.....

RE the faq.   Someone else said they would try to get that together.
That is a goldmine of info, but probably needs a little updating and
adding-to here and there.  Lots of good karma in that info.

> .....I was at one time hoping to
> create a pretty printable postscript version of it, but like a lot of
> things I was hoping to do with it, that never happened.

Only so many hours in the day, and as the ol' bod pushes the greybearus
potbellius exhalted status, I can't seem to run 20 hour days, anymore.
Oh, well.....(:+}}...   This is supposed to be FUN... are we having
FUN, yet?  (:+}}...

Olde suntoyz be great fun.....(:+}}...

Bob