scsi negotiation problem on aic79xx (39320A) in 2.6.14

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

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.

Quoted 7 lines · James Bottomley

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 :-)

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?

Quoted 2 lines · Hannes Reinecke

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 7 lines · James Bottomley

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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.

Quoted 3 lines · Denny Page

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?

Quoted 6 lines · James Bottomley

Quoted 3 lines · Denny Page

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