From owner-cvs-all Mon Oct 12 12:36:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA22278 for cvs-all-outgoing; Mon, 12 Oct 1998 12:36:54 -0700 (PDT) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA22253; Mon, 12 Oct 1998 12:36:42 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id NAA26254; Mon, 12 Oct 1998 13:36:19 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810121936.NAA26254@panzer.plutotech.com> Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c In-Reply-To: <199810121927.MAA16373@apollo.backplane.com> from Matthew Dillon at "Oct 12, 98 12:27:30 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 12 Oct 1998 13:36:19 -0600 (MDT) Cc: mike@smith.net.au, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Matthew Dillon wrote... > cache-sync is such a fundamental command, I can't imagine any drive > not doing the right thing with it, especially drives which support tagged > commands. The command is tightly integrated into the disk cache paradigm > as given by the SCSI-II standard. > > But I guess there could be a few... even so, I think we have to support > it. It's just too important a command, especially in larger RAID SCSI > systems which have huge write caches. Consider a UPS signalling a machine > that it's about to die and the machine trying to flush everything out and > shut down. Better to get the cache flushed to disk (non-volatile or not) > before power goes poof. Good example. > Have there been any specific reports of problems with the use of > the command other then the vague micropolis report in the first > email (first email that I got, anyway) ? Well, basically Tom Jackson has three Fujitsu drives, two of them are the M2954's that are quirked in the da driver now. He sent one of those drives to Justin this summer, and we figured out that it was returning the cache sync command with an illegal request sense key. That isn't really a big problem, since we just ignore the error. It looks like his other drive (slightly different version of the same model) hangs when it gets the cache sync command. I'm not sure that's what is happening, but it seems to be the case. Eventually, I think, the command timeout should hit and the machine should reboot, though. The reason he didn't see this before my most recent changes is because the drive in question is his boot drive, and for some reason wasn't getting final close. The shutdown hook I put in does a cache sync for all da devices that haven't seen final close already. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message