Skip site navigation (1)Skip section navigation (2)
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>