libata pata_pdc2027x success on sparc64

libata pata_pdc2027x success on sparc64

[Mikael Pettersson]

Alan & Albert,

I just tried the patch-2.6.17-ide1.gz libata PATA patch
on a sparc64 box in which I had put an Ultra133TX2 PCI
card (pdc20269) and an old 80GB IBM Deskstar disk. The
results were excellent: did lots of I/O with no kernel
errors, and I got about 45MB/s read speed at udma5.

(A minor nit: the patch kit doesn't have a config option
for pata_pdc2027x, so I had to hack one in. See below.)

In contrast, the old IDE pdc202xx_new driver had lots
of problems with CRC errors causing it to disable DMA.
I wasn't able to manually tune it above udma3 without
getting more errors. This isn't sparc64-specific: I've
had similar negative experience with the old IDE Promise
drivers in a PowerMac.

/Mikael

--- linux-2.6.17/drivers/scsi/Kconfig.~1~	2006-07-17 23:30:25.000000000 +0200
+++ linux-2.6.17/drivers/scsi/Kconfig	2006-07-17 23:39:25.000000000 +0200
@@ -843,6 +843,10 @@ config SCSI_PATA_PDC_OLD
 
 	  If unsure, say N.
 
+config SCSI_PATA_PDC_NEW
+	tristate "Newer Promise PATA controller support (Raving Lunatic)"
+	depends on SCSI_SATA && PCI && EXPERIMENTAL
+
 config SCSI_PATA_QDI
 	tristate "QDI VLB PATA support"
 	depends on SCSI_SATA
--- linux-2.6.17/drivers/scsi/Makefile.~1~	2006-07-17 23:30:25.000000000 +0200
+++ linux-2.6.17/drivers/scsi/Makefile	2006-07-17 23:40:06.000000000 +0200
@@ -161,6 +161,7 @@ obj-$(CONFIG_SCSI_PATA_OPTI)	+= libata.o
 obj-$(CONFIG_SCSI_PATA_OPTIDMA)	+= libata.o pata_optidma.o
 obj-$(CONFIG_SCSI_PATA_PCMCIA)	+= libata.o pata_pcmcia.o
 obj-$(CONFIG_SCSI_PATA_PDC_OLD)	+= libata.o pata_pdc202xx_old.o
+obj-$(CONFIG_SCSI_PATA_PDC_NEW)	+= libata.o pata_pdc2027x.o
 obj-$(CONFIG_SCSI_PATA_QDI)	+= libata.o pata_qdi.o
 obj-$(CONFIG_SCSI_PATA_RADISYS)	+= libata.o pata_radisys.o
 obj-$(CONFIG_SCSI_PATA_RZ1000)	+= libata.o pata_rz1000.o

Re: libata pata_pdc2027x success on sparc64

[Sergei Shtylyov]

Hello.

Mikael Pettersson wrote:

> In contrast, the old IDE pdc202xx_new driver had lots
> of problems with CRC errors causing it to disable DMA.

    Hm, from my experience it usually falls back to UltraDMA/44 and then the 
thing startrt working...

> I wasn't able to manually tune it above udma3 without
> getting more errors. This isn't sparc64-specific: I've
> had similar negative experience with the old IDE Promise
> drivers in a PowerMac.

    This happens because the "old" driver misses the PLL calibration code.
    You may want to try these Albert's patches:

http://marc.theaimsgroup.com/?t=110992452800002&r=1&w=2
http://marc.theaimsgroup.com/?t=110992471500002&r=1&w=2
http://marc.theaimsgroup.com/?t=110992490100002&r=1&w=2
http://marc.theaimsgroup.com/?t=111019238400003&r=1&w=2

    It looks like they were never considered for accepting into the kernel
while they succesfully solve this issue. Maybe Albert could try pushing them 
into -mm tree once more?

WBR, Sergei

Re: libata pata_pdc2027x success on sparc64

[Albert Lee]

Sergei Shtylyov wrote:
> Hello.
> 
> Mikael Pettersson wrote:
> 
>> In contrast, the old IDE pdc202xx_new driver had lots
>> of problems with CRC errors causing it to disable DMA.
> 
> 
>    Hm, from my experience it usually falls back to UltraDMA/44 and then
> the thing startrt working...
> 
>> I wasn't able to manually tune it above udma3 without
>> getting more errors. This isn't sparc64-specific: I've
>> had similar negative experience with the old IDE Promise
>> drivers in a PowerMac.
> 
> 
>    This happens because the "old" driver misses the PLL calibration code.
>    You may want to try these Albert's patches:
> 
> http://marc.theaimsgroup.com/?t=110992452800002&r=1&w=2
> http://marc.theaimsgroup.com/?t=110992471500002&r=1&w=2
> http://marc.theaimsgroup.com/?t=110992490100002&r=1&w=2
> http://marc.theaimsgroup.com/?t=111019238400003&r=1&w=2
> 
>    It looks like they were never considered for accepting into the kernel
> while they succesfully solve this issue. Maybe Albert could try pushing
> them into -mm tree once more?
> 

Hi,

The libata version has three improvements compared to the IDE version.

1. The PLL calibration patches in the above URLs (for IDE)
still need more improvement as done in the pdc_read_counter()
of the libata version.

2. The Promise 2027x adapters check the "set features - xfer mode"
   and set the timing register automatically. However, the automatically
   set values are not correct under 133MHz. Libata has a hook
   pdc2027x_post_set_mode() to set the values back by software.

3. ATAPI DMA is supported (please see pdc2027x_check_atapi_dma()).
   Maybe we also need to add this to the IDE version.

Currently I have no time to update the IDE pdc202xx_new driver.
Also as Alan said, we have no maintainer for the IDE layer at this time.
So, if ok, please try to use the libata-based driver.

Thanks,

Albert

Re: libata pata_pdc2027x success on sparc64

[Sergei Shtylyov]

Hello.

Albert Lee wrote:

>>>In contrast, the old IDE pdc202xx_new driver had lots
>>>of problems with CRC errors causing it to disable DMA.

>>   Hm, from my experience it usually falls back to UltraDMA/44 and then
>>the thing startrt working...

>>>I wasn't able to manually tune it above udma3 without
>>>getting more errors. This isn't sparc64-specific: I've
>>>had similar negative experience with the old IDE Promise
>>>drivers in a PowerMac.

>>   This happens because the "old" driver misses the PLL calibration code.
>>   You may want to try these Albert's patches:

>>http://marc.theaimsgroup.com/?t=110992452800002&r=1&w=2
>>http://marc.theaimsgroup.com/?t=110992471500002&r=1&w=2
>>http://marc.theaimsgroup.com/?t=110992490100002&r=1&w=2
>>http://marc.theaimsgroup.com/?t=111019238400003&r=1&w=2

>>   It looks like they were never considered for accepting into the kernel
>>while they succesfully solve this issue. Maybe Albert could try pushing
>>them into -mm tree once more?

> The libata version has three improvements compared to the IDE version.

> 1. The PLL calibration patches in the above URLs (for IDE)
> still need more improvement as done in the pdc_read_counter()
> of the libata version.

    Indeed. When backporting your patches to 2.6.10, I've added alike 
function, so can generate an extra patch against those.

> 2. The Promise 2027x adapters check the "set features - xfer mode"
>    and set the timing register automatically. However, the automatically
>    set values are not correct under 133MHz. Libata has a hook
>    pdc2027x_post_set_mode() to set the values back by software.

    You probably forgot -- the last mentioned patch was all about it. :-)

> 3. ATAPI DMA is supported (please see pdc2027x_check_atapi_dma()).
>    Maybe we also need to add this to the IDE version.

    Wouldn't hurt. :-)

> Currently I have no time to update the IDE pdc202xx_new driver.

    I'll probably take this on then, starting with pushing this half-buried 
stuff into -mm tree.

> Also as Alan said, we have no maintainer for the IDE layer at this time.
> So, if ok, please try to use the libata-based driver.

WBR, Sergei

Re: libata pata_pdc2027x success on sparc64

[Mikael Pettersson]

Albert Lee writes:
 > Sergei Shtylyov wrote:
 > > Hello.
 > > 
 > > Mikael Pettersson wrote:
 > > 
 > >> In contrast, the old IDE pdc202xx_new driver had lots
 > >> of problems with CRC errors causing it to disable DMA.
 > > 
 > > 
 > >    Hm, from my experience it usually falls back to UltraDMA/44 and then
 > > the thing startrt working...
 > > 
 > >> I wasn't able to manually tune it above udma3 without
 > >> getting more errors. This isn't sparc64-specific: I've
 > >> had similar negative experience with the old IDE Promise
 > >> drivers in a PowerMac.
 > > 
 > > 
 > >    This happens because the "old" driver misses the PLL calibration code.
 > >    You may want to try these Albert's patches:
 > > 
 > > http://marc.theaimsgroup.com/?t=110992452800002&r=1&w=2
 > > http://marc.theaimsgroup.com/?t=110992471500002&r=1&w=2
 > > http://marc.theaimsgroup.com/?t=110992490100002&r=1&w=2
 > > http://marc.theaimsgroup.com/?t=111019238400003&r=1&w=2
 > > 
 > >    It looks like they were never considered for accepting into the kernel
 > > while they succesfully solve this issue. Maybe Albert could try pushing
 > > them into -mm tree once more?
 > > 
 > 
 > Hi,
 > 
 > The libata version has three improvements compared to the IDE version.
 > 
 > 1. The PLL calibration patches in the above URLs (for IDE)
 > still need more improvement as done in the pdc_read_counter()
 > of the libata version.
 > 
 > 2. The Promise 2027x adapters check the "set features - xfer mode"
 >    and set the timing register automatically. However, the automatically
 >    set values are not correct under 133MHz. Libata has a hook
 >    pdc2027x_post_set_mode() to set the values back by software.
 > 
 > 3. ATAPI DMA is supported (please see pdc2027x_check_atapi_dma()).
 >    Maybe we also need to add this to the IDE version.

Do you know how large the difference is between the 20267 (old driver)
and the 20269 (new driver) in the areas touched by these patches?
Long ago I tried a 20267 PCI card in my PowerMac, and it had the same
issues that the 20269 card had. So I'm interested in porting the
calibration/timing fixes to pdc202xx_old.c.

/Mikael

Re: libata pata_pdc2027x success on sparc64

[Sergei Shtylyov]

Hello.

Mikael Pettersson wrote:

>  > The libata version has three improvements compared to the IDE version.
>  > 
>  > 1. The PLL calibration patches in the above URLs (for IDE)
>  > still need more improvement as done in the pdc_read_counter()
>  > of the libata version.
>  > 
>  > 2. The Promise 2027x adapters check the "set features - xfer mode"
>  >    and set the timing register automatically. However, the automatically
>  >    set values are not correct under 133MHz. Libata has a hook
>  >    pdc2027x_post_set_mode() to set the values back by software.
>  > 
>  > 3. ATAPI DMA is supported (please see pdc2027x_check_atapi_dma()).
>  >    Maybe we also need to add this to the IDE version.

> Do you know how large the difference is between the 20267 (old driver)
> and the 20269 (new driver) in the areas touched by these patches?

    Immense. They belong to the different families, register compatibe only in 
the standard PCI/BM IDE regisrer set -- hence was the driver split.

> Long ago I tried a 20267 PCI card in my PowerMac, and it had the same
> issues that the 20269 card had. So I'm interested in porting the
> calibration/timing fixes to pdc202xx_old.c.

    They don't apply to this driver at all.  The "older" chip family didn't 
have the PLL to calibrate.  It must be some different issue.

> /Mikael

WBR, Sergei

Re: libata pata_pdc2027x success on sparc64

[Mikael Pettersson]

Sergei Shtylyov writes:
 > Hello.
 > 
 > Mikael Pettersson wrote:
 > 
 > >  > The libata version has three improvements compared to the IDE version.
 > >  > 
 > >  > 1. The PLL calibration patches in the above URLs (for IDE)
 > >  > still need more improvement as done in the pdc_read_counter()
 > >  > of the libata version.
 > >  > 
 > >  > 2. The Promise 2027x adapters check the "set features - xfer mode"
 > >  >    and set the timing register automatically. However, the automatically
 > >  >    set values are not correct under 133MHz. Libata has a hook
 > >  >    pdc2027x_post_set_mode() to set the values back by software.
 > >  > 
 > >  > 3. ATAPI DMA is supported (please see pdc2027x_check_atapi_dma()).
 > >  >    Maybe we also need to add this to the IDE version.
 > 
 > > Do you know how large the difference is between the 20267 (old driver)
 > > and the 20269 (new driver) in the areas touched by these patches?
 > 
 >     Immense. They belong to the different families, register compatibe only in 
 > the standard PCI/BM IDE regisrer set -- hence was the driver split.
 > 
 > > Long ago I tried a 20267 PCI card in my PowerMac, and it had the same
 > > issues that the 20269 card had. So I'm interested in porting the
 > > calibration/timing fixes to pdc202xx_old.c.
 > 
 >     They don't apply to this driver at all.  The "older" chip family didn't 
 > have the PLL to calibrate.  It must be some different issue.

OK, in that case let's forget about the 20267. It's not _that_ important :-)

Re: libata pata_pdc2027x success on sparc64

[Mikael Pettersson]

On Tue, 18 Jul 2006 22:07:44 +0400, Sergei Shtylyov wrote:
>> In contrast, the old IDE pdc202xx_new driver had lots
>> of problems with CRC errors causing it to disable DMA.
>
>    Hm, from my experience it usually falls back to UltraDMA/44 and then the 
>thing startrt working...
>
>> I wasn't able to manually tune it above udma3 without
>> getting more errors. This isn't sparc64-specific: I've
>> had similar negative experience with the old IDE Promise
>> drivers in a PowerMac.
>
>    This happens because the "old" driver misses the PLL calibration code.
>    You may want to try these Albert's patches:
>
>http://marc.theaimsgroup.com/?t=110992452800002&r=1&w=2
>http://marc.theaimsgroup.com/?t=110992471500002&r=1&w=2
>http://marc.theaimsgroup.com/?t=110992490100002&r=1&w=2
>http://marc.theaimsgroup.com/?t=111019238400003&r=1&w=2
>
>    It looks like they were never considered for accepting into the kernel
>while they succesfully solve this issue. Maybe Albert could try pushing them 
>into -mm tree once more?

Thank you for these links. After fixing up whitespace damage in
these four messages the patches applied OK and more importantly
eliminated _all_ misbehaviour from pdc202xx_new on both my sparc64
and my PowerMac.

These fixes belong in Linus' kernel, not some semi-obscure
mailing list archive.

/Mikael

Re: libata pata_pdc2027x success on sparc64

[Alan Cox]

On Wed, Jul 19, 2006 at 02:29:59AM +0200, Mikael Pettersson wrote:
> Thank you for these links. After fixing up whitespace damage in
> these four messages the patches applied OK and more importantly
> eliminated _all_ misbehaviour from pdc202xx_new on both my sparc64
> and my PowerMac.
> 
> These fixes belong in Linus' kernel, not some semi-obscure
> mailing list archive.

We've not had an IDE maintainer for some time unfortunately so stuff
got badly lost. I think these and the hpt ones both belong in -mm even if the
longer term goal is to exterminate drivers/ide