From owner-cvs-all Mon Oct 12 11:26:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA08841 for cvs-all-outgoing; Mon, 12 Oct 1998 11:26:42 -0700 (PDT) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from feral.com (hat4.ppp.lmi.net [208.25.88.72]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA08804; Mon, 12 Oct 1998 11:26:27 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.6/8.8.6) with SMTP id LAA12551; Mon, 12 Oct 1998 11:25:19 -0700 Date: Mon, 12 Oct 1998 11:25:19 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Mike Smith cc: Kenneth Merry , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c In-Reply-To: <199810121809.LAA07119@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk I'm not quite sure I agree. It's a judgement call as to what the state overall of the existing population of devices there are out there. Nearly all SCSI-2 devices out there will sensibly support this command (actually, I didn't see any test within scsi_da to actually *not* try this with < SCSI2 support- that probably ought to be fixed for the (still somewhat large) population of CCS disks out there), or return some sensible kind of error. As far as I recall with the early f/w version of the Micropolis drive that I put in as a quirk for NetBSD, this drive just wandered into the weeds- but that is very likely the exception. Also the case *where* the quirks apply makes some difference. In this case, the quirk entries are for close/shutdown cases (rarely executed), and are definitely for older devices. I would, for example, be a bit more worried about the current "run the number of tagged commands up until where you get a QFULL condition and then back off" than this case. That said, I agree with you "in principle", but not "in this specific case". -matt On Mon, 12 Oct 1998, Mike Smith wrote: > > I think what this is telling us is that attempting to use anything other > than the least common denominator as the default is a Bad Idea. > > Don't kid yourselves folks; you're not going to manage to add quirk > entries for all the drives and firmware revisions that screw up royally > when you try to do fancy things to them. Better to add quirk entries > for the drives that get it _right_. > > Shipping a release with this sort of dangerous behaviour enabled is > going to be a support _nightmare_. I realise you folks aren't in the > support firing line, but for the sake of those that are, not to mention > the extremely negative publicity this sort of problem will cause, please > consider turning it off. > > > ken 1998/10/12 10:16:47 PDT > > > > Modified files: > > sys/cam/scsi scsi_da.c > > Log: > > Add quirk entries to disable the synchronize cache command for Micropolis > > 2217's (reported by Matthew Jacob in NetBSD PR kern/6027) and Fujitsu > > M2954's (reported by Tom Jackson). > > > > Some of the Fujitsus at least hang when they get a cache sync command. > > (Others just return illegal request.) > > > > Also, make error printing in dashutdown() a little more selective. Don't > > print any error when the sense key is illegal request. Drives that don't > > support the synchronize cache command usually return illegal request. > > Also, make sure the scsi status is check condition before going into > > scsi_sense_print(). > > > > Reviewed by: gibbs > > > > Revision Changes Path > > 1.9 +28 -10 src/sys/cam/scsi/scsi_da.c > > > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message