From owner-freebsd-scsi Fri Aug 30 14:02:22 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA22214 for freebsd-scsi-outgoing; Fri, 30 Aug 1996 14:02:22 -0700 (PDT) Received: from FileServ1.MI.Uni-Koeln.DE (FileServ1.MI.Uni-Koeln.DE [134.95.212.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA22201 for ; Fri, 30 Aug 1996 14:02:18 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr3-15.slip.Uni-Koeln.DE) by FileServ1.MI.Uni-Koeln.DE with SMTP id AA23715 (5.67b/IDA-1.5 for ); Fri, 30 Aug 1996 23:01:57 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.7.5/8.6.9) id WAA07233; Fri, 30 Aug 1996 22:48:02 +0200 (MET DST) Date: Fri, 30 Aug 1996 22:48:02 +0200 (MET DST) Message-Id: <199608302048.WAA07233@x14.mi.uni-koeln.de> From: Stefan Esser To: "Justin T. Gibbs" Cc: Stefan Esser , Brian Wang , freebsd-scsi@FreeBSD.ORG Subject: Re: NCR0+IBM DORS-32160 WA0A 2 gigs HD - assertion "cp" failed In-Reply-To: <199608301636.JAA03192@freefall.freebsd.org> References: <199608301544.RAA02753@x14.mi.uni-koeln.de> <199608301636.JAA03192@freefall.freebsd.org> Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Justin T. Gibbs writes: > >Up to now, I always choose devices that did not > >fail, and it seems that the DORS is finally a drive > >that I can expect to show errors on my development > >system, giving me a chance to understand why a modern > >drive does not work correctly with tags ... > > > >Regards, STefan > > These errors are for the QUEUE FULL condition right? I think drives > are allowed to return this even if the cause is temporary. We'll have > to come up with a strategy for when to reduce maxtags on drives that > doesn't penalize drives that do this kind of thing occasionally. Well, the NCR driver tries to do the right thing (reduce the number of tags in case of a QUEUE FULL) but it would never use a higher number again, after it had to cut down on tags use. But as I said before, I'm not sure whether the code works as designed. If you manage to deal with this correctly in your new SCSI code, a better implementation might be possible ... We have the IBM 0662..0664 drives as prime example of a drive that might reject tagged commands in certain situations, but IIRC, they do not return a QUEUE FULL, but a "MIX of tagged and untagged commands" error status. I will be busy with non-BSD stuff again this weekend, so there will be no advances to the NCR driver integration. (Sorry ...) Did you consider putting your changes on a CVS branch in -current ? This would GREATLY reduce the amount of work it takes me to have a development source tree .. Regards, STefan