Date: Mon, 12 Oct 1998 11:25:19 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Mike Smith <mike@smith.net.au> Cc: Kenneth Merry <ken@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c Message-ID: <Pine.LNX.4.02.9810121115390.12175-100000@feral-gw> In-Reply-To: <199810121809.LAA07119@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.02.9810121115390.12175-100000>