A few weeks ago I posted a query gere regarding the following errors I was
receiving when running NetBSD on a Syquest removable with a Quadra 605.

}Mar  6 13:39:40  /netbsd: dmaintr: discarded 32 b (last transfer was
}1008b).
}Mar  6 13:39:40  /netbsd: esp0: !TC [intr 10, stat 87, step 4] prevphase
}0, resid 3f0

(A bug report was subsequently filed--bin/5133).

Two things I'd like to do here.  1) Personally thank everyone who responded
to my post (much appreciated!!). and also to 2) follow up with the details
on how it all turned out.

>From what I was able to gather the eps0: errors were most prone to occur
when using removable media with NetBSD, although there was a report or two
of problems of those using slower hard drives.  After exchanging a bunch of
messages, I decided to follow Colin Wood's theory--"It just doesn't like
removables".  I dug up the 160 meg IBM dirve that's been sitting in the
back of my closet for some months now, ordered an enclosure, waited a week
for it to come, then installed the drive and gave NetBSD another go.

Running from a non-removable...works great, not a single re-occurence of
the error messages.  Daily checks with fsck tell me that it's staying
healthy too--not experiencing the file corruption I was getting with the EZ
drive.

Next objective: mount the cart which contained the old filesystem and try a
few tests, something which would involve the transfer of a fair amount of
data.  When booting from the EZ drive, redirecting the output of ls -lR
would land me in the debugger in roughly 3 out of 4 cases.  Redirecting ls
-lR to a file on the syquest now will typically bring about a few
dmaintr/esp messages (2-3), but I wasn't able to make it crash.  (Resultant
file size was around 800-900 kilobytes).

A few other things I noticed:

	* Drive speed may or may not be too much of an issue.  The hard drive
I'm using now is fairly slow.  3600 rpm.  In the past I've benchmarked it
against the Syquest, and it actually lost by a narrow margin.

	* When booting from the Syquest, dmaintr/esp0 messages would occur
sporadiacly when in single user-mode, chronically when in multi-user.
Could this have something to do with the system's attempt at accessing swap
space?

	* Compiling source code on the syquest?  Might not be a bad test...
I'll have to try this out in the next few days.

	In a nutshell, the more the drive was accessed, the more frequently
problems occured.  (Makes sense).  Also, FWIW, from what I've heard from
others, these symptoms affect other models of Syquest drives in addition to
the EZ135.  Zip drives appear to share much of the same maladies.

Professionally, I'm a recording engineer.  In addition to shuttling 2" tape
and pushing faders, I've spent a good deal of time in front of digital
audio workstations.  One of the things this has taught me --SCSI voodoo is
REAL.  Probably arising partially out of the evolution of the SCSI specs
over time, and manufacturers varying degrees of implementation of modes,
flags, and commands.  I've seen drives that absolutely would not work
reliably with system A, run fine with system B.  Others would work to a
point and then buckle.  (The ability of a drive to play back 8 channels of
44.1 kHz/16 bit aoudio was always a good benchmark in my book.)

	Then of course, there's always the issue of T-cal (especially in older
drives), cables, termination, and the degree of oxidization present on the
connector contacts.  I'm surprised at how many times a can of Electro-Wash
proved to be a solution.  So much for Voodoo....

	Could there be something along the lines of parameters unique to
removables that esp0 simply does not like?  (In all honesty, I wish I knew
more in this area than I do).

	My motive for setting up BSD was to use it as a learning environment for
both Unix and sysadmin tasks (yeah, I'm a 'noodler').  Once I get a little
more settled in I'd like to try modifying and compiling some kernels, but
for the time being, I'm just going to let it sit.  Again, thanks to  those
who took the time out to offer advice and suggestions.  Hopefully something
here will be useful to others.

Steve Revilak
revilak@umbsky.cc.umb.edu