Messages in this thread | | | Date | Thu, 06 Feb 2003 20:28:55 -0800 | From | "Martin J. Bligh" <> | Subject | Re: Broken SCSI code in the BK tree (was: 2.5.59-mm8) |
| |
>> 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/
| |