* Controlling PATA access speeds
@ 2006-06-01 17:25 John Treubig
2006-06-01 18:52 ` Jeff Garzik
0 siblings, 1 reply; 10+ messages in thread
From: John Treubig @ 2006-06-01 17:25 UTC (permalink / raw)
To: linux-scsi, linux-ide
We are currently using Promise Ultra133 TX2 (PDC20269 chip; pata_pdc2027x
driver, kernel version 2.6.15) to test and access PATA drives. If my
understanding is correct, during boot, a drive is queryied to determine it's
maximum access speed and the driver sets the access speed to be no higher
than the drive can handle. This is not speed testing the drive, but just
the drive firmware reporting it's maximum designed transfer rate. Due to
design constraints of the cabling to the drives, we need to force the access
speed lower than what the Drive reponds. Is there a mechanism to tell the
driver/LibATA to set the access speed to go no higher than a value I supply?
This can be a static setting that is set at boot, as it does not need to
be a dynamic setting.
Best wishes,
John Treubig
VT Miltope Corporation
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Controlling PATA access speeds
2006-06-01 17:25 Controlling PATA access speeds John Treubig
@ 2006-06-01 18:52 ` Jeff Garzik
2006-06-01 18:59 ` James Bottomley
2006-06-01 20:35 ` John Treubig
0 siblings, 2 replies; 10+ messages in thread
From: Jeff Garzik @ 2006-06-01 18:52 UTC (permalink / raw)
To: John Treubig; +Cc: linux-scsi, linux-ide
On Thu, Jun 01, 2006 at 12:25:45PM -0500, John Treubig wrote:
> We are currently using Promise Ultra133 TX2 (PDC20269 chip; pata_pdc2027x
> driver, kernel version 2.6.15) to test and access PATA drives. If my
> understanding is correct, during boot, a drive is queryied to determine
> it's maximum access speed and the driver sets the access speed to be no
> higher than the drive can handle. This is not speed testing the drive, but
> just the drive firmware reporting it's maximum designed transfer rate. Due
> to design constraints of the cabling to the drives, we need to force the
> access speed lower than what the Drive reponds. Is there a mechanism to
> tell the driver/LibATA to set the access speed to go no higher than a value
> I supply? This can be a static setting that is set at boot, as it does not
> need to be a dynamic setting.
The driver includes code to do cable detect. Is this insufficient for
some reason?
Jeff
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Controlling PATA access speeds
2006-06-01 18:52 ` Jeff Garzik
@ 2006-06-01 18:59 ` James Bottomley
2006-06-01 20:35 ` John Treubig
1 sibling, 0 replies; 10+ messages in thread
From: James Bottomley @ 2006-06-01 18:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: John Treubig, linux-scsi, linux-ide
On Thu, 2006-06-01 at 14:52 -0400, Jeff Garzik wrote:
> The driver includes code to do cable detect. Is this insufficient for
> some reason?
Fortunately PATA cables are shorter than SCSI ones, but for SCSI the
answer's "yes", which is why SPI tries to use domain validation (which
also doesn't fully detect all the issues, and why we sometimes have to
resort to "try reducing the transfer parameters down to X").
I have to believe, that even with shorter cable lengths and fewer
devices, PATA still runs into some (many) of the SPI issues.
James
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Controlling PATA access speeds
2006-06-01 18:52 ` Jeff Garzik
2006-06-01 18:59 ` James Bottomley
@ 2006-06-01 20:35 ` John Treubig
2006-06-01 21:21 ` Doug Maxey
2006-06-01 22:01 ` Sergei Shtylyov
1 sibling, 2 replies; 10+ messages in thread
From: John Treubig @ 2006-06-01 20:35 UTC (permalink / raw)
To: jeff; +Cc: linux-scsi, linux-ide
Jeff,
You bring up a good point in the fact that I believe your refering to
detecting 80 wire vs. 40 wire. We've not tried to use this to our
advantage, but it could have some merrit. What does the driver do if it
encounters a 40 wire cable and the drive says it's capable of DMA5?
Best wishes,
John
From: Jeff Garzik <jeff@garzik.org>
To: John Treubig <jtreubig@hotmail.com>
CC: linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: Controlling PATA access speeds
Date: Thu, 1 Jun 2006 14:52:44 -0400
On Thu, Jun 01, 2006 at 12:25:45PM -0500, John Treubig wrote:
> We are currently using Promise Ultra133 TX2 (PDC20269 chip; pata_pdc2027x
> driver, kernel version 2.6.15) to test and access PATA drives. If my
> understanding is correct, during boot, a drive is queryied to determine
> it's maximum access speed and the driver sets the access speed to be no
> higher than the drive can handle. This is not speed testing the drive,
but
> just the drive firmware reporting it's maximum designed transfer rate.
Due
> to design constraints of the cabling to the drives, we need to force the
> access speed lower than what the Drive reponds. Is there a mechanism to
> tell the driver/LibATA to set the access speed to go no higher than a
value
> I supply? This can be a static setting that is set at boot, as it does
not
> need to be a dynamic setting.
The driver includes code to do cable detect. Is this insufficient for
some reason?
Jeff
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Controlling PATA access speeds
2006-06-01 20:35 ` John Treubig
@ 2006-06-01 21:21 ` Doug Maxey
2006-06-02 15:31 ` John Treubig
2006-06-02 20:37 ` John Treubig
2006-06-01 22:01 ` Sergei Shtylyov
1 sibling, 2 replies; 10+ messages in thread
From: Doug Maxey @ 2006-06-01 21:21 UTC (permalink / raw)
To: John Treubig; +Cc: jeff, linux-scsi, linux-ide
On Thu, 01 Jun 2006 15:35:23 CDT, "John Treubig" wrote:
>Jeff,
>
>You bring up a good point in the fact that I believe your refering to
>detecting 80 wire vs. 40 wire. We've not tried to use this to our
>advantage, but it could have some merrit. What does the driver do if it
>encounters a 40 wire cable and the drive says it's capable of DMA5?
>
The presence of a 40 wire cable limits the device to UDMA2 - 33mhz.
See the ATA6 or later on t13.org.
JS20 blades are lackinging the strapping to indicate the devices hanging
off the amd8111 are on the equivalent of 80 wire - 4 inch trace on mb.
In the JS20 case, a quirk will be necessary to run at speeds higher than UDMA2.
++doug
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Controlling PATA access speeds
2006-06-01 21:21 ` Doug Maxey
@ 2006-06-02 15:31 ` John Treubig
2006-06-02 20:37 ` John Treubig
1 sibling, 0 replies; 10+ messages in thread
From: John Treubig @ 2006-06-02 15:31 UTC (permalink / raw)
To: dwm; +Cc: jeff, linux-scsi, linux-ide
The 40 wire detect (forcing the host to DMA2) is a good start. I am
researching the implications to our setup. Thanks for the help
Best wishes,
John
From: Doug Maxey <dwm@austin.ibm.com>
To: "John Treubig" <jtreubig@hotmail.com>
CC: jeff@garzik.org, linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: Controlling PATA access speeds
Date: Thu, 01 Jun 2006 16:21:58 -0500
On Thu, 01 Jun 2006 15:35:23 CDT, "John Treubig" wrote:
>Jeff,
>
>You bring up a good point in the fact that I believe your refering to
>detecting 80 wire vs. 40 wire. We've not tried to use this to our
>advantage, but it could have some merrit. What does the driver do if it
>encounters a 40 wire cable and the drive says it's capable of DMA5?
>
The presence of a 40 wire cable limits the device to UDMA2 - 33mhz.
See the ATA6 or later on t13.org.
JS20 blades are lackinging the strapping to indicate the devices hanging
off the amd8111 are on the equivalent of 80 wire - 4 inch trace on mb.
In the JS20 case, a quirk will be necessary to run at speeds higher than
UDMA2.
++doug
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Controlling PATA access speeds
2006-06-01 21:21 ` Doug Maxey
2006-06-02 15:31 ` John Treubig
@ 2006-06-02 20:37 ` John Treubig
2006-06-02 21:10 ` Doug Maxey
2006-06-02 22:33 ` Mark Lord
1 sibling, 2 replies; 10+ messages in thread
From: John Treubig @ 2006-06-02 20:37 UTC (permalink / raw)
To: dwm; +Cc: jeff, linux-scsi, linux-ide
Because of my setup, I have had to pull pin 34 (PDIAG) high at the Promise
to make the Promise think I have a 40 pin cable. At boot, the Promise
thinks I have a 40 wire cable installed and gives me a warning, yet when I
run my program that measures transfer rate in Linux, I still see the same
data rates as with an 80 wire cable (pin 34 shorted). Is there any other
item that I'm missing besides having Pin 34 pulled high? Does the drive's
echoing that it is UDMA5 capable have anything to do with it? Is the fact
that I'm not carrying pin 34 all the way to the drive causing my problem?
Best wishes,
John
From: Doug Maxey <dwm@austin.ibm.com>
To: "John Treubig" <jtreubig@hotmail.com>
CC: jeff@garzik.org, linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: Controlling PATA access speeds
Date: Thu, 01 Jun 2006 16:21:58 -0500
On Thu, 01 Jun 2006 15:35:23 CDT, "John Treubig" wrote:
>Jeff,
>
>You bring up a good point in the fact that I believe your refering to
>detecting 80 wire vs. 40 wire. We've not tried to use this to our
>advantage, but it could have some merrit. What does the driver do if it
>encounters a 40 wire cable and the drive says it's capable of DMA5?
>
The presence of a 40 wire cable limits the device to UDMA2 - 33mhz.
See the ATA6 or later on t13.org.
JS20 blades are lackinging the strapping to indicate the devices hanging
off the amd8111 are on the equivalent of 80 wire - 4 inch trace on mb.
In the JS20 case, a quirk will be necessary to run at speeds higher than
UDMA2.
++doug
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Controlling PATA access speeds
2006-06-02 20:37 ` John Treubig
@ 2006-06-02 21:10 ` Doug Maxey
2006-06-02 22:33 ` Mark Lord
1 sibling, 0 replies; 10+ messages in thread
From: Doug Maxey @ 2006-06-02 21:10 UTC (permalink / raw)
To: John Treubig; +Cc: jeff, linux-scsi, linux-ide
On Fri, 02 Jun 2006 15:37:51 CDT, "John Treubig" wrote:
>Because of my setup, I have had to pull pin 34 (PDIAG) high at the Promise
>to make the Promise think I have a 40 pin cable. At boot, the Promise
>thinks I have a 40 wire cable installed and gives me a warning, yet when I
>run my program that measures transfer rate in Linux, I still see the same
>data rates as with an 80 wire cable (pin 34 shorted). Is there any other
>item that I'm missing besides having Pin 34 pulled high? Does the drive's
>echoing that it is UDMA5 capable have anything to do with it? Is the fact
>that I'm not carrying pin 34 all the way to the drive causing my problem?
>
What type of drive do you have? A 2.5 laptop type? 26 meg/sec is
about what you will see. :-/
++doug
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Controlling PATA access speeds
2006-06-02 20:37 ` John Treubig
2006-06-02 21:10 ` Doug Maxey
@ 2006-06-02 22:33 ` Mark Lord
1 sibling, 0 replies; 10+ messages in thread
From: Mark Lord @ 2006-06-02 22:33 UTC (permalink / raw)
To: John Treubig; +Cc: dwm, jeff, linux-scsi, linux-ide
John Treubig wrote:
> Because of my setup, I have had to pull pin 34 (PDIAG) high at the
> Promise to make the Promise think I have a 40 pin cable. At boot, the
> Promise thinks I have a 40 wire cable installed and gives me a warning,
> yet when I run my program that measures transfer rate in Linux, I still
> see the same data rates as with an 80 wire cable (pin 34 shorted).
What data rate is that? If it's less than 25MB/sec (or so),
then the udma mode won't make much of a difference either way.
Cheers
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Controlling PATA access speeds
2006-06-01 20:35 ` John Treubig
2006-06-01 21:21 ` Doug Maxey
@ 2006-06-01 22:01 ` Sergei Shtylyov
1 sibling, 0 replies; 10+ messages in thread
From: Sergei Shtylyov @ 2006-06-01 22:01 UTC (permalink / raw)
To: John Treubig; +Cc: jeff, linux-scsi, linux-ide
Hello.
John Treubig wrote:
> Jeff,
>
> You bring up a good point in the fact that I believe your refering to
> detecting 80 wire vs. 40 wire. We've not tried to use this to our
> advantage, but it could have some merrit. What does the driver do if it
> encounters a 40 wire cable and the drive says it's capable of DMA5?
Obviously, it limits the speped to UDMA2.
MBR, Sergei
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-06-02 22:33 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-01 17:25 Controlling PATA access speeds John Treubig
2006-06-01 18:52 ` Jeff Garzik
2006-06-01 18:59 ` James Bottomley
2006-06-01 20:35 ` John Treubig
2006-06-01 21:21 ` Doug Maxey
2006-06-02 15:31 ` John Treubig
2006-06-02 20:37 ` John Treubig
2006-06-02 21:10 ` Doug Maxey
2006-06-02 22:33 ` Mark Lord
2006-06-01 22:01 ` Sergei Shtylyov
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).