Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Jun 1996 11:21:40 -0400 (EDT)
From:      "matthew c. mead" <mmead@Glock.COM>
To:        se@zpr.uni-koeln.de (Stefan Esser)
Cc:        hackers@freebsd.org
Subject:   Re: ST43400N
Message-ID:  <199606121521.LAA01393@Glock.COM>
In-Reply-To: <199606112010.AA13884@Sisyphos> from "Stefan Esser" at Jun 11, 96 10:10:41 pm

next in thread | previous in thread | raw e-mail | index | archive | help
Stefan Esser writes:

	Well, I know this is a second reply, but while I was
asleep last night the thing started doing those ccb timeouts
again.  The system still worked, but it took me 5 minutes to log
in and reboot it the kernel was so busy with the disk errors.
I'm gonna try some of the sugeestions below:

> } > If you are running a -current kernel, then please try
> } > one built with "options FAILSAFE". This will disable
> } > use of tagged command queues, which are the most likely
> } > cause of the problem you report.

> } > If the drive works with tags disabled, then I'll send 
> } > further directions to find out whether it is possible 
> } > to work around that problem. (You may comment out the
> } > call to scsi_start_unit() in /sys/scsi/sd.c for a test.)

> } 	Do the above two paragraphs apply to a 2.1.0-RELEASE
> } kernel as well?  This drive is on a 2.1.0-R system.

> Look at /sys/pci/ncr.c (line 6242 in -stable):

> 	ncr_setmaxtags (tp, SCSI_NCR_MAX_TAGS);

> Change this into:

> 	ncr_setmaxtags (tp, 0);

> This is part of what FAILSAFE does in current kernels ...

	Ok, I did this.

> The paragraph about scsi_start_unit() applies to 2.1.0R.

	If things don't work this way I'll remove that next.
Thanks for the suggestions.



-matt

-- 
Matthew C. Mead

mmead@goof.com
http://www.goof.com/~mmead/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606121521.LAA01393>