Re: Broken SCSI code in the BK tree (was: 2.5.59-mm8)

[Doug Ledford]

On Thu, Feb 06, 2003 at 06:25:02PM -0800, Patrick Mansfield wrote:
> On Thu, Feb 06, 2003 at 06:01:06PM -0800, Martin J. Bligh wrote:
> > 
> > Curious. I've no idea why the changes brought this out then ... I've done
> > hundreds and hundreds of reboots on 2.5 on all sorts of different kernels,
> > and never, ever seen this. Yet in 2.5.59-bk I see it every single time.
> > Very odd.
> > 
> > M.
> 
> Okay:
> 
> 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).

-- 
  Doug Ledford <[e-mail]>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606