Subject: Re: Iomega ZIP drive
To: Joachim Thiemann <email@example.com>
From: NoRM <N.R.McBride@city.ac.uk>
Date: 07/07/1997 16:37:17
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
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
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
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 firstname.lastname@example.org (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 <email@example.com>) 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...