* scsi negotiation problem on aic79xx (39320A) in 2.6.14
@ 2005-11-14 22:45 Michael Stone
2006-03-23 18:09 ` Michael Stone
0 siblings, 1 reply; 13+ messages in thread
From: Michael Stone @ 2005-11-14 22:45 UTC (permalink / raw)
To: linux-scsi
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14
2005-11-14 22:45 scsi negotiation problem on aic79xx (39320A) in 2.6.14 Michael Stone
@ 2006-03-23 18:09 ` Michael Stone
2006-03-23 18:37 ` James Bottomley
0 siblings, 1 reply; 13+ messages in thread
From: Michael Stone @ 2006-03-23 18:09 UTC (permalink / raw)
To: linux-scsi
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14
2006-03-23 18:09 ` Michael Stone
@ 2006-03-23 18:37 ` James Bottomley
2006-03-24 12:27 ` Michael Stone
0 siblings, 1 reply; 13+ messages in thread
From: James Bottomley @ 2006-03-23 18:37 UTC (permalink / raw)
To: Michael Stone; +Cc: linux-scsi
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14
2006-03-23 18:37 ` James Bottomley
@ 2006-03-24 12:27 ` Michael Stone
2006-03-24 12:30 ` Hannes Reinecke
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Michael Stone @ 2006-03-24 12:27 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-scsi
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14
2006-03-24 12:27 ` Michael Stone
@ 2006-03-24 12:30 ` Hannes Reinecke
2006-03-24 12:32 ` Michael Stone
2006-03-24 13:50 ` James Bottomley
2006-05-20 5:10 ` Denny Page
2 siblings, 1 reply; 13+ messages in thread
From: Hannes Reinecke @ 2006-03-24 12:30 UTC (permalink / raw)
To: Michael Stone; +Cc: linux-scsi
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14
2006-03-24 12:30 ` Hannes Reinecke
@ 2006-03-24 12:32 ` Michael Stone
2006-03-24 18:05 ` Stephen Degler
0 siblings, 1 reply; 13+ messages in thread
From: Michael Stone @ 2006-03-24 12:32 UTC (permalink / raw)
To: Hannes Reinecke; +Cc: linux-scsi
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14
2006-03-24 12:32 ` Michael Stone
@ 2006-03-24 18:05 ` Stephen Degler
0 siblings, 0 replies; 13+ messages in thread
From: Stephen Degler @ 2006-03-24 18:05 UTC (permalink / raw)
To: Michael Stone; +Cc: Hannes Reinecke, linux-scsi
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
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14
2006-03-24 12:27 ` Michael Stone
2006-03-24 12:30 ` Hannes Reinecke
@ 2006-03-24 13:50 ` James Bottomley
2006-05-20 5:10 ` Denny Page
2 siblings, 0 replies; 13+ messages in thread
From: James Bottomley @ 2006-03-24 13:50 UTC (permalink / raw)
To: Michael Stone; +Cc: linux-scsi
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14
2006-03-24 12:27 ` Michael Stone
2006-03-24 12:30 ` Hannes Reinecke
2006-03-24 13:50 ` James Bottomley
@ 2006-05-20 5:10 ` Denny Page
2006-05-20 13:51 ` James Bottomley
2 siblings, 1 reply; 13+ messages in thread
From: Denny Page @ 2006-05-20 5:10 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-scsi
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
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14
2006-05-20 5:10 ` Denny Page
@ 2006-05-20 13:51 ` James Bottomley
2006-05-20 14:20 ` James Bottomley
0 siblings, 1 reply; 13+ messages in thread
From: James Bottomley @ 2006-05-20 13:51 UTC (permalink / raw)
To: Denny Page; +Cc: linux-scsi
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
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14
2006-05-20 13:51 ` James Bottomley
@ 2006-05-20 14:20 ` James Bottomley
2006-05-20 17:12 ` Denny Page
0 siblings, 1 reply; 13+ messages in thread
From: James Bottomley @ 2006-05-20 14:20 UTC (permalink / raw)
To: Denny Page; +Cc: linux-scsi
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: scsi negotiation problem on aic79xx (39320A) in 2.6.14
2006-05-20 14:20 ` James Bottomley
@ 2006-05-20 17:12 ` Denny Page
0 siblings, 0 replies; 13+ messages in thread
From: Denny Page @ 2006-05-20 17:12 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-scsi
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
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* re: scsi negotiation problem on aic79xx (39320A) in 2.6.14
@ 2005-11-16 21:09 Alan D. Brunelle
0 siblings, 0 replies; 13+ messages in thread
From: Alan D. Brunelle @ 2005-11-16 21:09 UTC (permalink / raw)
To: linux-scsi; +Cc: mstone
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2006-05-20 17:12 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-14 22:45 scsi negotiation problem on aic79xx (39320A) in 2.6.14 Michael Stone
2006-03-23 18:09 ` Michael Stone
2006-03-23 18:37 ` James Bottomley
2006-03-24 12:27 ` Michael Stone
2006-03-24 12:30 ` Hannes Reinecke
2006-03-24 12:32 ` Michael Stone
2006-03-24 18:05 ` Stephen Degler
2006-03-24 13:50 ` James Bottomley
2006-05-20 5:10 ` Denny Page
2006-05-20 13:51 ` James Bottomley
2006-05-20 14:20 ` James Bottomley
2006-05-20 17:12 ` Denny Page
-- strict thread matches above, loose matches on Subject: below --
2005-11-16 21:09 Alan D. Brunelle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).