From owner-freebsd-hackers Sun Jun 6 6:35:14 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 1B47714F12 for ; Sun, 6 Jun 1999 06:35:03 -0700 (PDT) (envelope-from jedgar@fxp.org) Received: (qmail 7750 invoked by uid 1003); 6 Jun 1999 13:35:02 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Jun 1999 13:35:02 -0000 Date: Sun, 6 Jun 1999 09:35:02 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: jedgar@pawn.primelocation.net To: hackers@freebsd.org Subject: wfd.c and ATAPI Zip 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 I have two boxes with ATAPI Zip Drives: Box1: wdc1: unit 1 (atapi): , removable, intr, iordis wfd0: medium type unknown (no disk) Box2: wdc1: unit 0 (atapi): , removable, intr, iordis wfd0: medium type unknown (no disk) wfd0: buggy Zip drive, 64-block transfer limit set The drive on Box1 gets timeouts when reading/writing; the drive on Box2 works fine. After checking out /sys/i386/isa/wfd.c, I changed the block transfer limit to that of buggy drives (64) and the timeouts disappeared. I tried setting the block transfer limit to unlimited (0) as is used with non-buggy hardware, no timeouts occurred on Box2. Comparing the model names with wfd.c's comparison, I see that any model different that Box2's is *not* buggy: if (!strcmp(ap->model, "IOMEGA ZIP 100 ATAPI")) { since strcmp returns 0 if the strings match. On my drives, however, the opposite seems the case. My thoughts now are: 1) My two drive are somewhat 'rogue' in that they don't conform to the driver's expectations. 2) When the driver was written, the '!strcmp' should be 'strcmp' since strcmp returns 0 when equal (-1 or 1 when < or >), in which case my patch makes sense: --- /sys/i386/isa/wfd.c.orig Thu Feb 18 17:06:08 1999 +++ /sys/i386/isa/wfd.c Tue Jun 6 08:59:59 1999 @@ -247,7 +247,7 @@ * is known to lock up if transfers > 64 blocks are * requested. */ - if (!strcmp(ap->model, "IOMEGA ZIP 100 ATAPI")) { + if (strcmp(ap->model, "IOMEGA ZIP 100 ATAPI")) { printf("wfd%d: buggy Zip drive, 64-block transfer limit set\n", t->lun); t->maxblks = 64; 3) I've just plain lost it :) Can anyone else with an ATAPI Zip Drive confirm this? Regards, Chris ----- 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