From owner-freebsd-hackers Mon Jun 7 12: 4:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with SMTP id A65C5157E1 for ; Mon, 7 Jun 1999 12:04:38 -0700 (PDT) (envelope-from jedgar@fxp.org) Received: (qmail 15531 invoked by uid 1003); 7 Jun 1999 19:04:33 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Jun 1999 19:04:33 -0000 Date: Mon, 7 Jun 1999 15:04:33 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: jedgar@pawn.primelocation.net To: Mike Smith Cc: Junichi Satoh , hackers@freebsd.org Subject: Re: wfd.c and ATAPI Zip In-Reply-To: <199906071851.LAA00571@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 7 Jun 1999, Mike Smith wrote: > > 12.A, 21.*, and 23.* are known to be buggy...13.A doesn't appear to be. > > Since the current method of sorting out the revisions doesn't seem to > > be perfect, would it be acceptible to consider them all buggy unless known > > not to be (i.e. compare ap->revision instead of ap->model)? > > Uh, that's what the code does; if it's a Zip drive, it's considered to > be buggy regardless of revision. If the string compare isn't matching > a drive in the field, it means that Iomega have changed the string and > we need to know what the new drives are calling themselves. > I have an off-brand (NEC) Zip Drive with: which does have buggy firmware; I also have another one with: that has no problem when I remove the 64 block limitation. In this case, I would use strncmp instead of strcmp to test the first 27 characters. So what you are saying is that we are limiting all Zip drives instead of being based solely on firmware revision? Any reason for that? ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message