NetBSD Problem Report #5175

Received: (qmail 10954 invoked from network); 19 Mar 1998 06:01:13 -0000
Message-Id: <l03110700b1360d4d91b5@[158.121.9.43]>
Date: Wed, 18 Mar 1998 18:54:39 -0500
From: Steve Revilak <revilak@umbsky.cc.umb.edu>
To: port-mac68k mailing list <port-mac68k@NetBSD.org>
Subject: esp0/dmaintr follow-up  (`bin/5133')

>Number:         5175
>Category:       port-mac68k
>Synopsis:       esp0/dmaintr follow-up  (`bin/5133')
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-mac68k-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 19 07:05:01 +0000 1998
>Closed-Date:    Tue Oct 09 15:38:08 +0000 2001
>Last-Modified:  Tue Oct 09 15:38:08 +0000 2001
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:

Responsible-Changed-From-To: gnats-admin->gnats-admin
Responsible-Changed-By: mikel
Responsible-Changed-When: Thu Apr 23 23:05:52 1998
Responsible-Changed-Why:
category changed from 'pending'

Responsible-Changed-From-To: gnats-admin->port-mac68k-maintainer 
Responsible-Changed-By: fair 
Responsible-Changed-When: Mon Dec 28 09:38:10 PST 1998 
Responsible-Changed-Why:  
This PR is the responsibility of the portmaster, 
not the GNATS database administrator. 
State-Changed-From-To: open->closed 
State-Changed-By: chs 
State-Changed-When: Tue Oct 9 08:37:06 PDT 2001 
State-Changed-Why:  
copied additional info to PR 5133. 
there's not a new bug reported here, so no need for multiple PRs. 
>Unformatted:
 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

Home	PR Database Search