[ All of this seems to be relevant -- forgive the long inclusion. ]

Jason Thorpe sez:
/*
 * On Thu, 15 Feb 96 10:13:44 PST 
 *  jgraham@defender.VAS.viewlogic.com (James Graham - Systems Anarchist) wrote:
 * 
 * [ I'm not trying to be rude, but I get really frustrated with the "my
 *   SPARCstation SCSI doesn't work" messages that contain flamage and
 *   no other helpful/useful information. ]

Quite right, I lost my temper again.  I really should learn the meaning of
the word "tact".  No rudeness taken -- mea culpa.

 * 
 *  > I must concur.  My NetBSD/sparc 1+ can't do JACK with a tape drive.
 * 
 * While I sympathize that your tape drive might not be working properly, I 
 * just have to ask "Then why haven't you helped Paul, et al find the bloody 
 * bug?"

Because right now, my time available to dive in and hack is somewhat
limited by my "real" job (sysadmin) and my wife and 2.5 kids.  Yes, I
know I'm not the only one.  Yes, I know this is a volunteer effort, and
before my previous upstarts eclipse my gratitude, I must express my
appreciation for even the availability of such an OS.  I guess I took a
lot for granted.  I'm just not sure what to do when I say 'mt -f
/dev/nrst0 st' and it comes back 'mt: Unknown tape drive type 7'.  (It's
an Archive Python 4mm (DAT), BTW.).  Are the registers implemented
correctly?  Should I send-pr indicating the necessary configuration?
Would stealing 4 lines of code from a Sun .h file be considered
copyright infringement?

 * If any of my SPARC systems had this problem (SS1 and SS2 systems 
 * at work, 4/260 at home; different SCSI controller), then I would 
 * certainly try to help.  I'm sure Paul would too.  Or anyone else that 
 * might know how to fix it.  But, if we can't reproduce the problem on our 
 * end, then it's REALLY difficult to fix it.  You could certainly turn on 
 * SCSIDEBUG and/or litter esp.c with printf()s and calls to Debugger() at 
 * the failure points.  Also, saying "SS1+" doesn't provide enough info.  
 * There are a b'zillion different flavors of the NCR53c94 (the SCSI chip 
 * used in the SPARCstation).  Which revision is it?  Note, "ESP100A" might 
 * not be enough.  I have an SS1 with an "ESP100A" in it, which has an 
 * Emulex version of the chip, and my SS2 with an "ESP100A" has a genuine 
 * NCR chip.

I should check that out, too.  Unfortunately, I am sufficiently unfamiliar
with how SCSI ought to work to be of much use.  (Of course all the
stuff in the .h file should be of some help :-).

 * 
 * Simply saying "My NetBSD/sparc 1+ can't do JACK with a tape drive" isn't 
 * going to help anyone solve the problem.  Details do.

Yep, indeed.  See paragraph 1 above.

 * 
 *  > Where the _hell_ is the st support?  And a properly working 'mt'?
 *  > They've been missing WAY too long!  I want to be able to back my
 *  > machine up to a LOCAL tape drive (some of us can't afford more than one
 *  > machine -- should we be punished?).
 * 
 * "st" support and a working "mt" have been here a long time!  Because they 
 * fail on some revisions of a SCSI controller chip doesn't mean that 
 * overall support is broken.

Point taken.  The point I was trying to make above is that if it IS still
broken, it needs to be fixed, and I should not have to use a second known
working _remote_ machine to do something which is better done locally.

Your point, of course, is that I need to be more concise in my definition
of "broken", and you're right.

 * So, to re-cap: my tapes/cdroms work, other people's do, too.

Ah, now CD-ROMs are another jar of cookies.  _They_ work; just the tape
unit seems to be farschmelt.

 * Yours, and 
 * some others', doesn't.  Please help those who are brave enough to hack on 
 * the SCSI code find the bug by providing some useful "mode of failure" 
 * information; you might be surprised at the results.

I thought I had, some time back.  Maybe I should try again and resend.

To Paul and everyone else who's put in work on this:  I'm sorry for the
flamage.  I'll try to be more constructive, and I'll let y'all know when
I know what I'm talking about.

[I seem to have this problem that when I feel on top of the world, I do
 and say really stupid things.  The top of the world is sometimes the
 worst place to be.  It can get one fired if one is not careful... ]

 * 
 * --------------------------------------------------------------------------
 * Jason R. Thorpe                                       thorpej@nas.nasa.gov
 * NASA Ames Research Center                               Home: 408.866.1912
 * NAS: M/S 258-6                                          Work: 415.604.0935
 * Moffett Field, CA 94035                                Pager: 415.428.6939
 */





				--*greywolf;
--
D.A.R.E* to keep Microsoft off computers.
(* Diskette Abuse Resistance Education)