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>