Just incase you  (or anyone else for that matter :)  wants to be able to
use a ZIP drive on a sparc, here's a work-around I got from David Brownlee
<abs@anim.dreamworks.com>.

You need to compile a new kernel, and disable disconnect/reselect on the
SCSI ID of the drive.  Mine's set to 5, so in the kernel configuration
line:

	esp0    at sbus0 slot ? offset ? flags 0xff0f           # sun4c

gets changed to 

	esp0    at sbus0 slot ? offset ? flags 0xff2f           # sun4c

There's some comments above the line which explain in more detail what's
going on.


I've not exhaustively tested it, but it _seems_ to be working happily now 
:)


Norman R. McBride                                http://www.city.ac.uk/norm/
Computing Services, City University, England          norm@city.ac.uk (MIME)

"...the extreme case best illustrates the norm..."              Stephen King

On Thu, 19 Jun 1997, Joachim Thiemann wrote:

> 
> > Has anyone used one of these successfully under NetBSD 1.2 or 1.2.1?  I
> > find after a short while that it just refuses to work.  If fsck's and
> > mounts okay, then you can transfer a couple of megabytes back and forth.
> > But all of a sudden:
> > 
> >     esp0: RESELECT: 7 bytes in FIFO!
> >     sd3(esp0:5:0): unit attention, data = 04 35 01 02 ac 00 40 00 00 05 
> >     43 00 00 07 01 00 00
> 
> > If anyone could shed some light, I'd be grateful.  It works fine on my
> > Slowaris machine at work.  I was hoping that upgrading to 1.2.1 would fix
> > things, but naaaah.
> 
> Yeah, I feel for you: I've lived with the problem for a while now. pk
> (Paul Kranenburg <pk@cs.few.eur.nl>) is apparently working on
> it... IIRC it's a buggy SCSI chip or something. (I have been
> using the ZIP drive on my NetBSD-amiga for the time being)
> 
> It's my major peeve about my Sparc so far (mainly 'cause I am
> chronically short od diskspace, aren't we all...), and of course the
> %$*%^ zs0a: fifo overruns....
> 
> Sadly, I know too little about netbsd and the SCSI protocol, never
> mind the chip, to contribute anything...
> 
> Joe.
>