>> There were some bk scsi changes that ignored the queue depth (qlogicisp
>> sets them all to one).
>>
>> Current bk (I just pulled and checked) has a fix, the cleaner shinier
>> better scsi_lib.c scsi_request_fn now has this code:
>>
>> if (sdev->device_busy >= sdev->queue_depth)
>> break;
>>
>> So the oops has to do with the isp handling multiple requests in a row or
>> in quick succession.
>>
>> Hopefully going to the latest bk will fix your oops.
>
> It might, but please understand this. The qlogicisp driver does things to
> the scsi mid layer that the scsi mid layer does not protect itself against
> and as a result is the biggest pile of steaming, unsupportable, crap code
> in the universe! The scsi mid layer was designed from day one to think
> that the host->can_queue, sdev->queue_depth, and host->sg_tablesize items
> were *static* on a given host/device unless specifically changed by
> calling into the adjustment routines (scsi_adjust_queue_depth). The
> qlogicisp driver violates those principles and I make no warranty of any
> kind that said driver will continue to operate properly unless someone
> takes the time to actually audit the qlogicisp_queuecommand() and
> qlogicisp_irq() routine to make sure it is actually doing the right thing
> when making those changes!
>
> If I understand correctly, Matthew Jacob's latest isp driver set drives
> *all* qlogic hardware (or at least all the older stuff like the qlogicisp
> driver drives). I would much prefer that people simply test out Matthew's
> driver and use it instead. In fact, if it's ready for 2.5 kernel use, I
> would strongly recommend that it be considered as a possible replacement
> in the linux kernel for the default driver on all qlogic cards not handled
> by the new qla2x00 driver version 6 (DaveM may have objections to that
> related to sparc if Matthew's driver isn't sparc friendly, but I don't
> know of any other reason not to switch over).
If you can send me a patch, I'll willingly test it .... I have plenty of
these cards on very racy machines ;-)
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 07 2003 - 22:00:22 EST