I have two boxes with ATAPI Zip Drives:
Box1:
wdc1: unit 1 (atapi): <IOMEGA ZIP 100 ATAPI Floppy/12.A>,
removable, intr, iordis
wfd0: medium type unknown (no disk)
Box2:
wdc1: unit 0 (atapi): <IOMEGA ZIP 100 ATAPI/13.A>, 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 <jed...@fxp.org> | 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 majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
