Date: Mon, 07 Jun 1999 12:28:54 -0700 From: Mike Smith <mike@smith.net.au> To: "Chris D. Faulhaber" <jedgar@fxp.org> Cc: Mike Smith <mike@smith.net.au>, Junichi Satoh <junichi@junichi.org>, hackers@freebsd.org Subject: Re: wfd.c and ATAPI Zip Message-ID: <199906071928.MAA01207@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 07 Jun 1999 15:04:33 EDT." <Pine.BSF.4.10.9906071458370.15515-100000@pawn.primelocation.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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: > <IOMEGA ZIP 100 ATAPI Floppy/12.A> > which does have buggy firmware; I also have another one with: > <IOMEGA ZIP 100 ATAPI/13.A> > 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. Gotcha, and that's definitely a good idea. > 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? No evidence suggesting that any revision ever worked or would work; the simplest and safest technique is just to cap transfers at 32k - in reality it doesn't affect performance at all, so there's no real need to be extra-picky. -- \\ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906071928.MAA01207>