For the record, another data point for problems with Zip drives. 
I'm telling the whole story below; the short executive summary is that
the Zip drive would silently corrupt my data with the NCR driver and
the SBC driver seems to have fixed that. 

Long version: 

I originally managed to time my entry into the NetBSD world very
badly: I downloaded about half of 1.2 and a complete 1.1 at about the
time when 1.2 was being released. (1.2 was not available from any of
the mirrors yet but I did get it from the US site. Since all the
documentation on the Web sites etc still talked about 1.1, I figured
it would make sense to get 1.1 just in case :-)
  Well, the Zip cartridge I had used for the downloads (on a networked
Win95/Linux PC at work with a borrowed PC Zip drive) was partly
corrupt when I came home; I have since seen reports of similar
problems with PC-formatted disks and the Mac's PC reader software. 
I ended up installing 1.1 (which was miraculously readable from the
Zip) until I could get it working well enough to actually grab the raw
data off the Zip on the NetBSD side. (Maybe I re-downloaded part or
all of it -- I can't remember exactly which pieces I managed to
salvage but I'm proud I did get a few. I know for a fact that at least
Bash and Mtools come from files I reconstructed from the raw sector
data. These in turn helped me enough to get most of the rest of what I
got off the drive.)
  As far as I can tell, the Zip was working fine with NetBSD 1.1. But
I upgraded to 1.2 around New Year's eve, and then, about a month ago,
I was tight enough on disk space to manage to screw up my Emacs
installation in a hasty maneuver to free up some idle space on the
drive. No problem, sez I, just download Emacs again onto the Zip
drive, extract, and install. It compiled out of the box in less than
two hours last time.
  Uh-huh. I ended up discovering that +none+ of the data on any of the
Zips was remaining consistent; with annoying regularity every file
bigger than 15873 bytes would get really wild errors in it. I spent
the whole weekend downloading multiple copies of the Emacs
distribution over my blazing 14400, and figuring out whether the
problem was with the actual Zip cartridge, with my file system
formatting (still a newbie here, folks), or with something else.
  Well, you can guess the rest. I have now lived for one month without
my removable (but I did manage to squeeze Emacs back in somehow), and
finally decided to try the SBC driver. 
  It seems to work OK now. Whew. Knock on wood.

Question: Is there anybody who doesn't think the NCR driver doesn't
work with Zip drives? Wouldn't this be something to mention in the
"known problems" part of the FAQ? I know it would have saved me
literally days of extra work and anguish. 

Any other comments? 

/* era */

Facts: Basic IIcx, 20 meg of ram, 40 meg of swap, two practically full
hard drives (a 150 meg partition of my primary and an old 80-megger I
hooked up as secondary, used entirely for MacBSD. The IIcx doesn't
really have room for two internal drives so I run with the lid
slightly open. :-)
  No difference whether I'd hook up the Zip on SCSI 5 or SCSI 6.
  Previously (i.e. with the old GENERIC#1 kernel) attempting to mount
the drive e.g. when su:ed from my own account (as opposed to actually
originally logged in as root) would dump me into the kernel debugger
and the point of no return ... I'm not sure about the exact
circumstances; anyway, I ended up switching to single-user to do any
mounting or unmounting just to be safe.
  I also consistently got these whenever first attempting to read the
Zip after reboot or unmounting (indented && wrapped for readability): 
    Mar 16 10:22:05 hello /netbsd: sd2: sd2(ncrscsi0:6:0): illegal
      request, data = 00 00 01 02 8f 01 00 b6 db 6d b6 db 6d b6 db 6d b6
    Mar 16 10:22:05 hello /netbsd: sd2: could not mode sense (4); using
      fictitious geometry
I'd spuriously get these "for no apparent reason" but in general I'd
get them when a cartridge was accessed for the first time.

The kernel I use now is (wrapped again for legibility):
 $ uname -a
 NetBSD hello 1.2C NetBSD 1.2C (GENERICSBC) #25: Wed Feb 26 12:47:51 CST 1997
   scottr@spot:/usr/src/sys/arch/mac68k/compile/GENERICSBC mac68k

... and I just got my first kernel panic with the new kernel when I
tried uname -a from within Emacs. Not sure why -- obviously, it worked
OK now, the second time. (I didn't have enough disk space for the kernel
core, sorry. And I don't think I'll actively try to reproduce this :-)

-- 
Defin-i-t-e-ly. Sep-a-r-a-te. Gram-m-a-r.  <http://www.iki.fi/~era/>
 * Enjoy receiving spam? Register at <http://www.iki.fi/~era/spam.html>