Date: Thu, 21 Jan 1999 01:20:04 +0100 From: Bernd Walter <ticso@cicely.de> To: "Jeroen C. van Gelderen" <gelderen@mediaport.org>, "Kenneth D. Merry" <ken@plutotech.com>, Greg Lehey <grog@lemis.com> Cc: roberto@keltia.freenix.fr, freebsd-scsi@FreeBSD.ORG Subject: Re: Disk dying (Conner CFP and Tagged Queueing Probs) Message-ID: <19990121012004.07728@cicely.de> In-Reply-To: <03c601be44a5$e9937400$0d79eb0a@deskfix.local>; from Jeroen C. van Gelderen on Wed, Jan 20, 1999 at 07:51:38PM %2B0100 References: <03c601be44a5$e9937400$0d79eb0a@deskfix.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 20, 1999 at 07:51:38PM +0100, Jeroen C. van Gelderen wrote: > >SYNCCACHE shouldn't be a problem. > >I have lots of drives rejecting it - it's more an informational thing. > > Then why does the Conner behave like this? It has run for a year without a > hitch (except for the SYNCHRONIZE CACHE problem which I patched in my > previous kernel). Only now I'm running a -CURRENT kernel (which I forgot to > patch) and only after I rebooted the machine thrice I am getting these > problems. It seems logical to blame the SYNCHRONIZE CACHE command. > > If this doesn't sound too ridiculous, I propose a quirk enty that disables > the SYNCHRONIZE CACHE command *and* limits the tagged openings to 30. I'll > simply dump the system more often... > One of my hosts have 25 HDDs nearly all of them can't handle the SYNCCACHE Operation - but I never had any problem with them except of this Fujitsu drive. But nevertheless eaven this drive never caused any data loos. Checking for avaiability of an command by simply trying is a usual way under SCSI. Disabling it for all drives which are not able to understand this command would result in an enourmous large table. My Conner drive also worked for a long time under WinNT without any problems. But before FreeBSD CAM I never saw an operating system realy 'using' a drive, so I'm not surprised that there are problems shown up which sleeped silendly. In fact in my case and as shown by other persons disabling tagged queueing disables the problem with these drives. The point is to check which firmware releases are broken and how to safely enable this feature on broken drives - I usualy like to get as much out of my hardware as possible. Even if I don't use it... > > Cheers, > Jeroen > -- B.Walter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990121012004.07728>