scsi negotiation problem on aic79xx (39320A) in 2.6.14

scsi negotiation problem on aic79xx (39320A) in 2.6.14

[Michael Stone]

At some point between 2.6.11 and 2.6.14 something seems to have killed
the scsi performance for one of our disk arrays. Prior to the upgrade it
could transfer a full 120MB/s to cache and sustain upwards of 100MB/s
from disk. On 2.6.14 I saw more like 2.5MB/s to/from the array. From the
array side the key difference was that the speed was reported as "async"
rather than "160". The bootup messages from the kernel are different
also:

2.6.11:

Nov 14 21:40:07 ormal kernel: ACPI: PCI interrupt 0000:03:06.0[A] -> GSI 24 (level, low) -> IRQ 24          
Nov 14 21:40:07 ormal kernel: ACPI: PCI interrupt 0000:03:06.1[B] -> GSI 25 (level, low) -> IRQ 25          
Nov 14 21:40:07 ormal kernel: scsi2 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.11                     
Nov 14 21:40:07 ormal kernel:         <Adaptec 39320A Ultra320 SCSI adapter>                                
Nov 14 21:40:07 ormal kernel:         aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512    SCBs                                                                                                       
Nov 14 21:40:07 ormal kernel:                                                                               
Nov 14 21:40:07 ormal kernel: scsi3 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.11                     
Nov 14 21:40:07 ormal kernel:         <Adaptec 39320A Ultra320 SCSI adapter>                                
Nov 14 21:40:07 ormal kernel:         aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512    SCBs                                                                                                       
Nov 14 21:40:07 ormal kernel:                                                                               
Nov 14 21:40:07 ormal kernel: (scsi3:A:0): 160.000MB/s transfers (80.000MHz DT, 16bit)                      
Nov 14 21:40:07 ormal kernel:   Vendor: IFT       Model: IFT-7250F Rev: 231T                        
Nov 14 21:40:07 ormal kernel:   Type:   Direct-Access ANSI SCSI revision: 04           
Nov 14 21:40:07 ormal kernel: scsi3:A:0:0: Tagged Queuing enabled.  Depth 32                                
Nov 14 21:40:07 ormal kernel: SCSI device sdf: 2938208256 512-byte hdwr sectors (1504363 MB)                
Nov 14 21:40:07 ormal kernel: SCSI device sdf: drive cache: write through                                   


2.6.14:

Nov 14 20:50:52 ormal kernel: ACPI: PCI Interrupt 0000:03:06.0[A] -> GSI 24 (level, low) -> IRQ 23          
Nov 14 20:50:52 ormal kernel: scsi2 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.11                     
Nov 14 20:50:52 ormal kernel:         <Adaptec 39320A Ultra320 SCSI adapter>                                
Nov 14 20:50:52 ormal kernel:         aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512    SCBs                                                                                                       
Nov 14 20:50:52 ormal kernel:                                                                               
Nov 14 20:50:52 ormal kernel:   Vendor: IFT       Model: IFT-7250F Rev: 231T                        
Nov 14 20:50:52 ormal kernel:   Type:   Direct-Access ANSI SCSI revision: 04           
Nov 14 20:50:52 ormal kernel:  target2:0:0: asynchronous.                                                   
Nov 14 20:50:52 ormal kernel: scsi2:A:0:0: Tagged Queuing enabled.  Depth 32                                
Nov 14 20:50:52 ormal kernel:  target2:0:0: Beginning Domain Validation                                     
Nov 14 20:50:52 ormal kernel:  target2:0:0: wide asynchronous.                                              
Nov 14 20:50:52 ormal kernel:  target2:0:0: Domain Validation skipping write tests                          
Nov 14 20:50:52 ormal kernel:  target2:0:0: Ending Domain Validation                                        
Nov 14 20:50:52 ormal kernel: SCSI device sdf: 2938208256 512-byte hdwr sectors (1504363 MB)                
Nov 14 20:50:52 ormal kernel: SCSI device sdf: drive cache: write through                                   

Note that there's no "160.000MB/s transfers" message in 2.6.14, instead
there's an "asynchronous".  (In the course of diagnosing this I switched
from one port on the scsi controller to the other, but the results were
the same.) Is this a known issue? Is there a workaround? 

Mike Stone

re: scsi negotiation problem on aic79xx (39320A) in 2.6.14

[Alan D. Brunelle]

This sounds very much like the issue I just posted (regarding an MPT 
adapter - U320 SCSI negotiation problem in Linux 2.6.13 and later 
implementations on LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT 
Dual Ultra320 SCSI (rev 08)) - perhaps the AIC79xx driver has a similar 
issue where it doesn't handle some new parallel capabilities being shown 
by 2.6.13 (and later) kernels?

Alan D. Brunelle

Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14

[Michael Stone]

The negotiation for this configuration is still broken in 2.6.16.

On Mon, Nov 14, 2005 at 05:45:12PM -0500, you wrote:
>At some point between 2.6.11 and 2.6.14 something seems to have killed
>the scsi performance for one of our disk arrays. Prior to the upgrade it
>could transfer a full 120MB/s to cache and sustain upwards of 100MB/s
>from disk. On 2.6.14 I saw more like 2.5MB/s to/from the array. From the
>array side the key difference was that the speed was reported as "async"
>rather than "160". The bootup messages from the kernel are different
>also:
>
>2.6.11:
>
>Nov 14 21:40:07 ormal kernel: ACPI: PCI interrupt 0000:03:06.0[A] -> GSI 24 
>(level, low) -> IRQ 24          Nov 14 21:40:07 ormal kernel: ACPI: PCI 
>interrupt 0000:03:06.1[B] -> GSI 25 (level, low) -> IRQ 25          Nov 14 
>21:40:07 ormal kernel: scsi2 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 
>1.3.11                     Nov 14 21:40:07 ormal kernel:         <Adaptec 
>39320A Ultra320 SCSI adapter>                                Nov 14 
>21:40:07 ormal kernel:         aic7902: Ultra320 Wide Channel A, SCSI Id=7, 
>PCI-X 101-133Mhz, 512    SCBs                                               
>Nov 14 21:40:07 ormal kernel:                                               
>Nov 14 21:40:07 ormal kernel: scsi3 : Adaptec AIC79XX PCI-X SCSI HBA 
>DRIVER, Rev 1.3.11                     Nov 14 21:40:07 ormal kernel:        
><Adaptec 39320A Ultra320 SCSI adapter>                                Nov 
>14 21:40:07 ormal kernel:         aic7902: Ultra320 Wide Channel B, SCSI 
>Id=7, PCI-X 101-133Mhz, 512    SCBs                                         
>Nov 14 21:40:07 ormal kernel:                                               
>Nov 14 21:40:07 ormal kernel: (scsi3:A:0): 160.000MB/s transfers (80.000MHz 
>DT, 16bit)                      Nov 14 21:40:07 ormal kernel:   Vendor: IFT 
>Model: IFT-7250F Rev: 231T                        Nov 14 21:40:07 ormal 
>kernel:   Type:   Direct-Access ANSI SCSI revision: 04           Nov 14 
>21:40:07 ormal kernel: scsi3:A:0:0: Tagged Queuing enabled.  Depth 32       
>Nov 14 21:40:07 ormal kernel: SCSI device sdf: 2938208256 512-byte hdwr 
>sectors (1504363 MB)                Nov 14 21:40:07 ormal kernel: SCSI 
>device sdf: drive cache: write through                                   
>
>2.6.14:
>
>Nov 14 20:50:52 ormal kernel: ACPI: PCI Interrupt 0000:03:06.0[A] -> GSI 24 
>(level, low) -> IRQ 23          Nov 14 20:50:52 ormal kernel: scsi2 : 
>Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.11                     Nov 
>14 20:50:52 ormal kernel:         <Adaptec 39320A Ultra320 SCSI adapter>    
>Nov 14 20:50:52 ormal kernel:         aic7902: Ultra320 Wide Channel A, 
>SCSI Id=7, PCI-X 101-133Mhz, 512    SCBs                                    
>Nov 14 20:50:52 ormal kernel:                                               
>Nov 14 20:50:52 ormal kernel:   Vendor: IFT       Model: IFT-7250F Rev: 
>231T                        Nov 14 20:50:52 ormal kernel:   Type:   
>Direct-Access ANSI SCSI revision: 04           Nov 14 20:50:52 ormal 
>kernel:  target2:0:0: asynchronous.                                         
>Nov 14 20:50:52 ormal kernel: scsi2:A:0:0: Tagged Queuing enabled.  Depth 
>32                                Nov 14 20:50:52 ormal kernel:  
>target2:0:0: Beginning Domain Validation                                    
>Nov 14 20:50:52 ormal kernel:  target2:0:0: wide asynchronous.              
>Nov 14 20:50:52 ormal kernel:  target2:0:0: Domain Validation skipping 
>write tests                          Nov 14 20:50:52 ormal kernel:  
>target2:0:0: Ending Domain Validation                                       
>Nov 14 20:50:52 ormal kernel: SCSI device sdf: 2938208256 512-byte hdwr 
>sectors (1504363 MB)                Nov 14 20:50:52 ormal kernel: SCSI 
>device sdf: drive cache: write through                                   
>Note that there's no "160.000MB/s transfers" message in 2.6.14, instead
>there's an "asynchronous".  (In the course of diagnosing this I switched
>from one port on the scsi controller to the other, but the results were
>the same.) Is this a known issue? Is there a workaround? 
>
>Mike Stone

Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14

[James Bottomley]

On Thu, 2006-03-23 at 13:09 -0500, Michael Stone wrote:
> The negotiation for this configuration is still broken in 2.6.16.

Well, since the driver works normally for most people, it sounds like
there's some issue with this configuration.  First of all, look
in /sys/class/spi_transport/target2:0:0 and tell me what min_period,
max_offset and max_width are.  Then, if min_period is too high, echo
12.5 to it and 1 to revalidate.  Finally, see if you can set the period
yourself using the period file.  Also, what does /proc/scsi/aic79xx/2
say?  If none of that works, we can try debug the negotiation.

James

Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14

[Michael Stone]

On Thu, Mar 23, 2006 at 01:37:23PM -0500, James Bottomley wrote:
>Well, since the driver works normally for most people, it sounds like
>there's some issue with this configuration.  First of all, look
>in /sys/class/spi_transport/target2:0:0 and tell me what min_period,
>max_offset and max_width are.  Then, if min_period is too high, echo
>12.5 to it and 1 to revalidate.  Finally, see if you can set the period
>yourself using the period file.  Also, what does /proc/scsi/aic79xx/2
>say?  If none of that works, we can try debug the negotiation.

Thanks for the reply, it's finally working. The min_period was 6.5, 
changing it to 12.5 & revalidating made it properly negotiate 160MB/s 
instead of asynchronous. max_offset was 254 & max_width was 1. Is there 
a way to make that permenant beside setting the proc entries on each 
boot?

Mike Stone

Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14

[Hannes Reinecke]

Michael Stone wrote:
> On Thu, Mar 23, 2006 at 01:37:23PM -0500, James Bottomley wrote:
>> Well, since the driver works normally for most people, it sounds like
>> there's some issue with this configuration.  First of all, look
>> in /sys/class/spi_transport/target2:0:0 and tell me what min_period,
>> max_offset and max_width are.  Then, if min_period is too high, echo
>> 12.5 to it and 1 to revalidate.  Finally, see if you can set the period
>> yourself using the period file.  Also, what does /proc/scsi/aic79xx/2
>> say?  If none of that works, we can try debug the negotiation.
> 
> Thanks for the reply, it's finally working. The min_period was 6.5,
> changing it to 12.5 & revalidating made it properly negotiate 160MB/s
> instead of asynchronous. max_offset was 254 & max_width was 1. Is there
> a way to make that permenant beside setting the proc entries on each boot?
> 
Well, yes. You can limit the transfer speed in the BIOS for that device.
With the latest patches from scsi-misc we're finally picking them up :-)

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux Products GmbH		S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14

[Michael Stone]

On Fri, Mar 24, 2006 at 01:30:22PM +0100, Hannes Reinecke wrote:
>Well, yes. You can limit the transfer speed in the BIOS for that device.
>With the latest patches from scsi-misc we're finally picking them up :-)

I actually thought I had done that at one point when I was testing, but 
I'll double check next time I reboot at the console.

Mike Stone

Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14

[James Bottomley]

On Fri, 2006-03-24 at 07:27 -0500, Michael Stone wrote:
> Thanks for the reply, it's finally working. The min_period was 6.5, 
> changing it to 12.5 & revalidating made it properly negotiate 160MB/s 
> instead of asynchronous. max_offset was 254 & max_width was 1. Is there 
> a way to make that permenant beside setting the proc entries on each 
> boot?

Yes ... put it in the bios of the aic card.  However, it also indicates
some issue with the array.  It must be responding to a 6.25 negotiation
request with an async response.

James

Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14

[Stephen Degler]

Note that Hannes' patch specific to observing the bios defaults applies 
cleanly to 2.6.14.x mainline.

skd

Michael Stone wrote:

> On Fri, Mar 24, 2006 at 01:30:22PM +0100, Hannes Reinecke wrote:
>
>> Well, yes. You can limit the transfer speed in the BIOS for that device.
>> With the latest patches from scsi-misc we're finally picking them up :-)
>
>
> I actually thought I had done that at one point when I was testing, 
> but I'll double check next time I reboot at the console.
>
> Mike Stone
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14

[Denny Page]

James,

The problem that Michael describes appears to be identical to the problem
that I had reported with the HP-460 tape drives.  Same 6.5 min period, fixed
by echo 12.5 and validating.  Perhaps the problem is specific to the card
rather than with the array and tape drive?

Setting the xfer speed in the bios does not appear to affect the result with
the 2.6.16 kernel.

Denny


Michael Stone wrote:
> On Thu, Mar 23, 2006 at 01:37:23PM -0500, James Bottomley wrote:
>> Well, since the driver works normally for most people, it sounds like
>> there's some issue with this configuration.  First of all, look
>> in /sys/class/spi_transport/target2:0:0 and tell me what min_period,
>> max_offset and max_width are.  Then, if min_period is too high, echo
>> 12.5 to it and 1 to revalidate.  Finally, see if you can set the period
>> yourself using the period file.  Also, what does /proc/scsi/aic79xx/2
>> say?  If none of that works, we can try debug the negotiation.
>
> Thanks for the reply, it's finally working. The min_period was 6.5, 
> changing it to 12.5 & revalidating made it properly negotiate 160MB/s 
> instead of asynchronous. max_offset was 254 & max_width was 1. Is 
> there a way to make that permenant beside setting the proc entries on 
> each boot?
>
> Mike Stone
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14

[James Bottomley]

On Fri, 2006-05-19 at 22:10 -0700, Denny Page wrote:
> The problem that Michael describes appears to be identical to the
> problem
> that I had reported with the HP-460 tape drives.  Same 6.5 min period,
> fixed
> by echo 12.5 and validating.  Perhaps the problem is specific to the
> card
> rather than with the array and tape drive?
> 
> Setting the xfer speed in the bios does not appear to affect the
> result with
> the 2.6.16 kernel.

That's odd ... the code to recognise the BIOS settings went into 2.6.16.
What does /proc/scsi/aic79xx/<n> say?

James


> 

Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14

[James Bottomley]

On Sat, 2006-05-20 at 08:51 -0500, James Bottomley wrote:
> On Fri, 2006-05-19 at 22:10 -0700, Denny Page wrote:
> > Setting the xfer speed in the bios does not appear to affect the
> > result with
> > the 2.6.16 kernel.
> 
> That's odd ... the code to recognise the BIOS settings went into 2.6.16.
> What does /proc/scsi/aic79xx/<n> say?

Oh ... actually, I should have traversed the tree rather than going by
commit date.  Apparently the BIOS code didn't make it in until post
2.6.16, so if you check 2.6.17-rc4, it should work.

James

Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14

[Denny Page]

Ok, thanks.  It will be a couple of days before I can do the test.

Denny


James Bottomley wrote:
> On Sat, 2006-05-20 at 08:51 -0500, James Bottomley wrote:
>> On Fri, 2006-05-19 at 22:10 -0700, Denny Page wrote:
>>> Setting the xfer speed in the bios does not appear to affect the
>>> result with
>>> the 2.6.16 kernel.
>> That's odd ... the code to recognise the BIOS settings went into 2.6.16.
>> What does /proc/scsi/aic79xx/<n> say?
> 
> Oh ... actually, I should have traversed the tree rather than going by
> commit date.  Apparently the BIOS code didn't make it in until post
> 2.6.16, so if you check 2.6.17-rc4, it should work.
> 
> James
> 
>