>> 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?
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
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
