> On Tue, 8 Jun 1999, Junichi Satoh wrote: > > > Hmm... > > > > I have an ATAPI ZIP drive: > > ======================================================================== > > wdc0: unit 1 (atapi): <IOMEGA ZIP 100 ATAPI/23.D>, 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 juni...@junichi.org > > juni...@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. \\ msm...@freebsd.org \\ -- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
