Is there a limit on the number of Promise Ultra133TX2 (PDC20269
 chip) PATA interface cards that can be present on a system?  

Judging from my efforts to get a test PC running with the
configuration below, it would appear that there is a maximum 
of two cards that can be installed.  After much trial and error, 
I have determined that the errors listed below occur only on 
UDMA(100) drives that are connected to ide6 and later (that 
is, the 3rd card).  Master/slave jumper settings have no 
visible effect.

I tried using three Highpoint Rocket 133 cards to see if they 
performed any better, and they were not vulnerable to the DMA 
limitation, but I must have gotten a bad card or two since they 
left the drives in an unstable condition (/var/log/messages 
grew to 343M!).  

Steps to reproduce:
1) Set up a system with at least 3 Promise Ultra133TX2 cards in 
addition to having on-board primary and secondary IDE enabled.
2) Populate the primary master of the third controller with a 
drive supporting UDMA 5 or better.  It appears to have no 
bearing whether or not the first two controllers are populated 
or not.  
3) Check dmesg for errors akin to the ones below.

This dmesg output is from 2.6.7, but the problem also exists 
in 2.6.11-rc4.  

Oh, and before anyone asks me why in the world I would have a 
need for a system capable of addressing 16 drives attached to 
one PC, the machine's entire purpose is stressing the IDE drives 
to the limit before they are declared safe for production use.  
Ordinarily, I would say this isn't much of a problem, but during 
one of the stress runs, these problems force the drives to drop 
to PIO mode, thereby killing any resemblance of speed.  

Thanks for any help!

Drew Winstel

Hi, 

  Maybe the PLL on the 3rd pdc20269 adapter not initialized by the firmware.

Could you help to test it with the attached libata pdc2027x driver patch with kernel 2.6.10 or above?

When configuring the kernel, please select "N" for pdc202xx_new driver and
select "Y" for the attached pata_pdc2027x driver instead. Thanks.


Albert