I have been corresponding with Doug privately about the possibility that
this is related to the same issues within the NCR driver that keep the
RZ56 and other such devices from functioning properly.  Basically, as
the NCR code sits in -current at the moment, the driver code doesn't
handle raising the ATN signal properly when it receives a message it
doesn't want to deal with. Instead of raising it and waiting for the
current handshake to complete, it "flashes" the line quickly.  This is
completely non-standard behaviour and the reaction of the device being
so signaled is completely undefined.

Hypothetically: If the TK50 has asked the VAX running under NetBSD for
some action the NCR driver doesn't support, the ATN line could get
cycled quickly, the corresponding REJECT message is never sent from the
driver code, and the TK50 may enter an unknown state or issue an
irrelavent sense code based on this non-standard response to the
request.

Applying the suggested patch will not in anyway affect other devices
other than possibly speed up the discovery process since proper REJECT
messages will be sent in response to synchronous data tranfer requests
and other unsupported SCSI requests.

My experience thus far in life has been that DEC tended to be very
intolerant of non-standard hardware behaviour (non-standard from DEC's
viewpoint anyway) and did not tend to code for that eventuality.  Of
course, YMMV.


--
Jon Grubbs
jgrubbs@megsinet.net

----- Original Message -----

> 
> I can confirm this problem exists with TK50-GA on the VAXstation 
> 3100/30.
> Mine also works just dandy under VMS.  I get the exact same SENSE 
> errors.Is this possibly an issue of the drive being SCSI-I and not 
> returningthe SENSE and other extended info that SCSI-II does?  
> FreeBSD suffers
> from this problem -- basically you can't use many SCSI-I devices under
> FreeBSD due to the fact that they've mostly abandoned any support
> for "quirky" old devices (Those that don't return SENSE, or don't
> handle LUN probing, etc).
> 
> I'd really like to see NetBSD continue to accomodate this hardware 
> myself.Considering VMS deals with it, there clearly isn't a 
> hardware malfunction,
> aside from possible SCSI-II expectations.  I haven't looked at the 
> tapedriver yet, but perhaps if we aren't recognising TK quirks (or 
> aren'tmaking provisions for such) we could address them.
> 
> Cheers,
> -skots
> --
> Scott G. Akmentins-Taylor     InterNet: staylor@mrynet.com
> MRY Systems			        staylor@mrynet.lv
>    (Skots Gregorijs Akmentins-Teilors -- just call me "Skots")
>        ----- Labak miris neka sarkans -----
>