[PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVD drive connected to mptspi driver

[PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVD drive connected to mptspi driver

[Doug Chapman]

Patch for: http://bugzilla.kernel.org/show_bug.cgi?id=8426

A recent code cleanup that moved code from mptscsih to mptspi
inadvertently change the order some code was called.  This caused
a massive slowdown (of 150x to 300x) on the CD/DVD drive on the
high-end HP Integrity servers.

Signed-off-by: Doug Chapman <doug.chapman@hp.com>




diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
index 85f21b5..2eb5741 100644
--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -726,13 +726,15 @@ static int mptspi_slave_configure(struct scsi_device *sdev)
 	struct _MPT_SCSI_HOST *hd =
 		(struct _MPT_SCSI_HOST *)sdev->host->hostdata;
 	VirtTarget *vtarget = scsi_target(sdev)->hostdata;
-	int ret = mptscsih_slave_configure(sdev);
+	int ret;
+
+	mptspi_initTarget(hd, vtarget, sdev);
+
+	ret = mptscsih_slave_configure(sdev);
 
 	if (ret)
 		return ret;
 
-	mptspi_initTarget(hd, vtarget, sdev);
-
 	ddvprintk((MYIOC_s_INFO_FMT "id=%d min_period=0x%02x"
 		" max_offset=0x%02x max_width=%d\n", hd->ioc->name,
 		sdev->id, spi_min_period(scsi_target(sdev)),

Re: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVD drive connected to mptspi driver

[Doug Chapman]

Eric,

Any feedback on this?  From looking at the code I am pretty sure I have
only restored things to the order where they were before the cleanup
patch but you obviously know the code better than I possibly could.

As this is a regression I would like to get this resolved before long.

thanks,

- Doug

On Mon, 2007-05-07 at 15:59 -0400, Doug Chapman wrote:
> Patch for: http://bugzilla.kernel.org/show_bug.cgi?id=8426
> 
> A recent code cleanup that moved code from mptscsih to mptspi
> inadvertently change the order some code was called.  This caused
> a massive slowdown (of 150x to 300x) on the CD/DVD drive on the
> high-end HP Integrity servers.
> 
> Signed-off-by: Doug Chapman <doug.chapman@hp.com>
> 
> 
> 
> 
> diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
> index 85f21b5..2eb5741 100644
> --- a/drivers/message/fusion/mptspi.c
> +++ b/drivers/message/fusion/mptspi.c
> @@ -726,13 +726,15 @@ static int mptspi_slave_configure(struct scsi_device *sdev)
>  	struct _MPT_SCSI_HOST *hd =
>  		(struct _MPT_SCSI_HOST *)sdev->host->hostdata;
>  	VirtTarget *vtarget = scsi_target(sdev)->hostdata;
> -	int ret = mptscsih_slave_configure(sdev);
> +	int ret;
> +
> +	mptspi_initTarget(hd, vtarget, sdev);
> +
> +	ret = mptscsih_slave_configure(sdev);
>  
>  	if (ret)
>  		return ret;
>  
> -	mptspi_initTarget(hd, vtarget, sdev);
> -
>  	ddvprintk((MYIOC_s_INFO_FMT "id=%d min_period=0x%02x"
>  		" max_offset=0x%02x max_width=%d\n", hd->ioc->name,
>  		sdev->id, spi_min_period(scsi_target(sdev)),
> 
> 

Re: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVD drive connected to mptspi driver

[Doug Chapman]

Eric,

Sorry to bother you on this again, I realize you are very busy.

>From our off-list email and from your comments to Chip Coldwell in
redhat BZ 225177 it sounded like you were prepared to ACK this.  Any
chance you could send your official ACK so this can be committed?

much appreciated,

- Doug


On Mon, 2007-05-07 at 15:59 -0400, Doug Chapman wrote:
> Patch for: http://bugzilla.kernel.org/show_bug.cgi?id=8426
> 
> A recent code cleanup that moved code from mptscsih to mptspi
> inadvertently change the order some code was called.  This caused
> a massive slowdown (of 150x to 300x) on the CD/DVD drive on the
> high-end HP Integrity servers.
> 
> Signed-off-by: Doug Chapman <doug.chapman@hp.com>
> 
> 
> 
> 
> diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
> index 85f21b5..2eb5741 100644
> --- a/drivers/message/fusion/mptspi.c
> +++ b/drivers/message/fusion/mptspi.c
> @@ -726,13 +726,15 @@ static int mptspi_slave_configure(struct scsi_device *sdev)
>  	struct _MPT_SCSI_HOST *hd =
>  		(struct _MPT_SCSI_HOST *)sdev->host->hostdata;
>  	VirtTarget *vtarget = scsi_target(sdev)->hostdata;
> -	int ret = mptscsih_slave_configure(sdev);
> +	int ret;
> +
> +	mptspi_initTarget(hd, vtarget, sdev);
> +
> +	ret = mptscsih_slave_configure(sdev);
>  
>  	if (ret)
>  		return ret;
>  
> -	mptspi_initTarget(hd, vtarget, sdev);
> -
>  	ddvprintk((MYIOC_s_INFO_FMT "id=%d min_period=0x%02x"
>  		" max_offset=0x%02x max_width=%d\n", hd->ioc->name,
>  		sdev->id, spi_min_period(scsi_target(sdev)),
> 
> 

Re: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVD drive connected to mptspi driver

[James Bottomley]

On Tue, 2007-05-22 at 14:25 -0600, Doug Chapman wrote:
> Eric,
> 
> Sorry to bother you on this again, I realize you are very busy.
> 
> >From our off-list email and from your comments to Chip Coldwell in
> redhat BZ 225177 it sounded like you were prepared to ACK this.  Any
> chance you could send your official ACK so this can be committed?
> 
> much appreciated,

Actually I'd like a little analysis of why first, please Eric.

It seems to me, with the current wrong ordering in the initialisation
results in a large queue depth being given to the DVD (which are
habitually very low queue depth ... or even untagged beasts).  So does
the slowdown result from the fusion accepting N commands for the DVD and
then rejecting N-1 of them resulting in ping pong between the mid-layer
and driver?

If so, we probably want to fix the command throttling in the driver.

James

RE: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVDdrive connected to mptspi driver

[Moore, Eric]

On Tuesday, May 22, 2007 3:27 PM, James Bottomley wrote:

> On Tue, 2007-05-22 at 14:25 -0600, Doug Chapman wrote:
> > Eric,
> > 
> > Sorry to bother you on this again, I realize you are very busy.
> > 
> > >From our off-list email and from your comments to Chip Coldwell in
> > redhat BZ 225177 it sounded like you were prepared to ACK this.  Any
> > chance you could send your official ACK so this can be committed?
> > 
> > much appreciated,
> 
> Actually I'd like a little analysis of why first, please Eric.
> 
> It seems to me, with the current wrong ordering in the initialisation
> results in a large queue depth being given to the DVD (which are
> habitually very low queue depth ... or even untagged beasts).  So does
> the slowdown result from the fusion accepting N commands for 
> the DVD and
> then rejecting N-1 of them resulting in ping pong between the 
> mid-layer
> and driver?
> 
> If so, we probably want to fix the command throttling in the driver.
> 

James - Sorry, for delay, somehow I missed this email.

I approve the patch that was submitted by Doug Chapman.      Here is the
reasoning:   The DVD device that Doug is using is either a SCSI_1
device, or it doesn't support Q-tags.  The problem is the driver is
setting the Queue depth to 32, when it should of been 1.   With the
queue depth set larger than one,  this device doesn't work properly.

This bug came about when I reorganized some spi functions by moving them
from mptscsih.c over to mptspi.c.   When I did that, there were some
flags not set correctly in mptscsih_change_queue_depth.  The function
that sets these flags is mptspi_setTargetNegoParms.    Prior to
reorganizing the code, I was calling mptscsi_setTargetNegoParms before I
set the queue depth, the current code does it after.    If you accept
this patch, then it sets the flags properly.   

Eric

RE: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVDdrive connected to mptspi driver

[James Bottomley]

On Tue, 2007-05-29 at 15:40 -0600, Moore, Eric wrote:
> On Tuesday, May 22, 2007 3:27 PM, James Bottomley wrote:
> 
> > On Tue, 2007-05-22 at 14:25 -0600, Doug Chapman wrote:
> > > Eric,
> > > 
> > > Sorry to bother you on this again, I realize you are very busy.
> > > 
> > > >From our off-list email and from your comments to Chip Coldwell in
> > > redhat BZ 225177 it sounded like you were prepared to ACK this.  Any
> > > chance you could send your official ACK so this can be committed?
> > > 
> > > much appreciated,
> > 
> > Actually I'd like a little analysis of why first, please Eric.
> > 
> > It seems to me, with the current wrong ordering in the initialisation
> > results in a large queue depth being given to the DVD (which are
> > habitually very low queue depth ... or even untagged beasts).  So does
> > the slowdown result from the fusion accepting N commands for 
> > the DVD and
> > then rejecting N-1 of them resulting in ping pong between the 
> > mid-layer
> > and driver?
> > 
> > If so, we probably want to fix the command throttling in the driver.
> > 
> 
> James - Sorry, for delay, somehow I missed this email.
> 
> I approve the patch that was submitted by Doug Chapman.      Here is the
> reasoning:   The DVD device that Doug is using is either a SCSI_1
> device, or it doesn't support Q-tags.  The problem is the driver is
> setting the Queue depth to 32, when it should of been 1.   With the
> queue depth set larger than one,  this device doesn't work properly.

The device is presumably returning BUSY when you try to send a second
command when it's already processing the first ... that should be
propagated back to the mid-layer causing it to throttle the queue ... it
seems this wasn't happening for some reason to get such a massive
slowdown.  Is this a more generic problem in the fusion or is it a
simple issue only affecting the untagged case? 

> This bug came about when I reorganized some spi functions by moving them
> from mptscsih.c over to mptspi.c.   When I did that, there were some
> flags not set correctly in mptscsih_change_queue_depth.  The function
> that sets these flags is mptspi_setTargetNegoParms.    Prior to
> reorganizing the code, I was calling mptscsi_setTargetNegoParms before I
> set the queue depth, the current code does it after.    If you accept
> this patch, then it sets the flags properly.   

James

RE: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVDdriveconnected to mptspi driver

[Moore, Eric]

On Tuesday, May 29, 2007 4:03 PM,  James Bottomley wrote:

> The device is presumably returning BUSY when you try to send a second
> command when it's already processing the first ... that should be
> propagated back to the mid-layer causing it to throttle the 
> queue ... it
> seems this wasn't happening for some reason to get such a massive
> slowdown.  Is this a more generic problem in the fusion or is it a
> simple issue only affecting the untagged case? 
> 

Right, probably SELECTION_TIMEOUT.  Or command timeout with error
handling threads getting called.   Either way, the customer hasn't
provided a dmesg log or scsi bus trace, so we don't know for sure. But
is this analysis really required?     Dont' you think the driver should
return that it doens't support queued commands when
sdev->tagged_supported (look at scsi_scan.c function scsi_add_lun) is
set to zero?      It appears that is what other drivers in the kernel
tree do.    When I reorganized the code in a patch I provided back in
February,  I moved analyzing the sdev->tagged_supported flag to after I
set the queue depth, not before.

Eric  

RE: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVDdriveconnected to mptspi driver

[Moore, Eric]

[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]

James -   I obtained a log from Doug (attached), and the firmware is
returning BUSY, so your correct.  That will end up as a ADD_TO_MLQUEUE
disposition.   Does the mid-layer throttle back the queue when a device
returns busy, I don't know?    I still believe that the lld shouldn't
report that a device supports tagged when it really doesn't.    I hope
you will consider this patch, if not, let me know how to proceed.

Eric



Eric Moore wrote: 
> On Tuesday, May 29, 2007 4:03 PM,  James Bottomley wrote:
> 
> > The device is presumably returning BUSY when you try to 
> send a second
> > command when it's already processing the first ... that should be
> > propagated back to the mid-layer causing it to throttle the 
> > queue ... it
> > seems this wasn't happening for some reason to get such a massive
> > slowdown.  Is this a more generic problem in the fusion or is it a
> > simple issue only affecting the untagged case? 
> > 
> 
> Right, probably SELECTION_TIMEOUT.  Or command timeout with error
> handling threads getting called.   Either way, the customer hasn't
> provided a dmesg log or scsi bus trace, so we don't know for sure. But
> is this analysis really required?     Dont' you think the 
> driver should
> return that it doens't support queued commands when
> sdev->tagged_supported (look at scsi_scan.c function scsi_add_lun) is
> set to zero?      It appears that is what other drivers in the kernel
> tree do.    When I reorganized the code in a patch I provided back in
> February,  I moved analyzing the sdev->tagged_supported flag 
> to after I
> set the queue depth, not before.
> 


[-- Attachment #2: dmesg_while_reading_dvd.txt --]
[-- Type: text/plain, Size: 11014 bytes --]

ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=30720 bufflen=30720 xfer_cnt=0
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 11 00 00 0f 00
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=32768 bufflen=32768 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=49152 bufflen=49152 xfer_cnt=0
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 48 00 00 28 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 70 00 00 10 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 a8 00 00 18 00
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=32768 bufflen=32768 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 70 00 00 10 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 48 00 00 28 00
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=32768 bufflen=32768 xfer_cnt=0
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 70 00 00 10 00
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=2048 bufflen=2048 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=14336 bufflen=14336 xfer_cnt=0
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 e8 00 00 28 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 10 00 00 28 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 38 00 00 01 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 39 00 00 07 00
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=2048 bufflen=2048 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 38 00 00 01 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 10 00 00 28 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 86 e8 00 00 28 00
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=2048 bufflen=2048 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=49152 bufflen=49152 xfer_cnt=0
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 10 00 00 28 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 38 00 00 01 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 68 00 00 18 00
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=2048 bufflen=2048 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 38 00 00 01 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 10 00 00 28 00
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=2048 bufflen=2048 xfer_cnt=0
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 38 00 00 01 00
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=2048 bufflen=2048 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=14336 bufflen=14336 xfer_cnt=0
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 a8 00 00 28 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 d0 00 00 28 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 f8 00 00 01 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 f9 00 00 07 00
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=2048 bufflen=2048 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 f8 00 00 01 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 d0 00 00 28 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 a8 00 00 28 00
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=2048 bufflen=2048 xfer_cnt=0
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 d0 00 00 28 00
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 f8 00 00 01 00
mptscsih_io_done: [0:0:1:0] cmd=0x28 result=0x00000008
	iocstatus=0x0000 scsi_state=0x00 scsi_status=0x08 loginfo=0x00000000
mptscsih_io_done: [0:0:1:0] resid=81920 bufflen=81920 xfer_cnt=0
sr 0:0:1:0: [sr0] Done: MLQUEUE
sr 0:0:1:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK
sr 0:0:1:0: [sr0] CDB: Read(10): 28 00 00 0e 87 d0 00 00 28 00

RE: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVDdriveconnected to mptspi driver

[James Bottomley]

On Thu, 2007-05-31 at 09:40 -0600, Moore, Eric wrote:
> James -   I obtained a log from Doug (attached), and the firmware is
> returning BUSY, so your correct.  That will end up as a ADD_TO_MLQUEUE
> disposition.   Does the mid-layer throttle back the queue when a device
> returns busy, I don't know?    I still believe that the lld shouldn't
> report that a device supports tagged when it really doesn't.    I hope
> you will consider this patch, if not, let me know how to proceed.

Sorry, yes ... I should have said that the patch is correct and I'll put
it in 2.6.22

However, since we have such a wonderful example of the failing case, I'd
like to try to correct the root cause, if I may.  Doug, would you be
amenable to testing out a few patches for me?

James