From owner-freebsd-hackers Mon Jun 7 11:54:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (unknown [209.179.127.11]) by hub.freebsd.org (Postfix) with ESMTP id 4B62C14C57 for ; Mon, 7 Jun 1999 11:54:21 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.conference.usenix.org [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id LAA00571; Mon, 7 Jun 1999 11:51:43 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199906071851.LAA00571@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Chris D. Faulhaber" Cc: Junichi Satoh , hackers@freebsd.org Subject: Re: wfd.c and ATAPI Zip In-reply-to: Your message of "Mon, 07 Jun 1999 11:19:55 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Jun 1999 11:51:43 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 8 Jun 1999, Junichi Satoh wrote: > > > Hmm... > > > > I have an ATAPI ZIP drive: > > ======================================================================== > > wdc0: unit 1 (atapi): , removable, intr, iordis > > wfd1: medium type unknown (no disk) > > wfd1: buggy Zip drive, 64-block transfer limit set > > ======================================================================== > > > > It does not work with your patch. It's a buggy drive. > > > > Probably, using only strcmp() is not enough. > > We shoud distinguish buggy or not using revision number. > > > > #I don't know how many revisions are available. :-) > > --- > > Junichi Satoh junichi@junichi.org > > junichi@jp.FreeBSD.ORG > > > > 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. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message