[clue-tech] 2.6.18 (CentOS 5.x) kernel initialize IDE drives in UDMA2 mode?

[Jim Ockers]

Hi Dave,

Thanks for responding! :)

David L. Anselmi wrote:
> Jim Ockers wrote:
>> Hi CLUEbies,
>>
>> For various very important reasons we have to run our Linux systems 
>> with CentOS 5.x with all IDE drives in UDMA2 (or slower) mode.  Of 
>> course the 2.6 kernel IDE device driver, the chipset on our 
>> motherboard, and the drives, all support UDMA5 or UDMA6 and 
>> autonegotiate the fastest speed they support when the driver 
>> initializes the drive.
>
> For such a specific (and rare, as in most people say "who cares?") 
> configuration it might be worth standardizing on hardware that works.
Our hardware works pretty well except not faster than UDMA2.  It has to 
do with the old removal drive carriers and receivers, of which we have 
several million dollars worth.  It does make this a fairly specific 
configuration though.
>
> It might be worth offering money to a kernel hacker to fix it.  It 
> might be worth asking Red Hat to support your needs and then switching 
> to RHEL.
I wound up commenting out some lines from ide-timing.h which forces it 
to return UDMA2 or lower (ATA33 DMA modes).  With this change the driver 
won't init the drive in anything faster than ATA33.  Of course this is 
effectively crippling the kernel and preventing faster DMA modes but if 
it turns out to be reliable it might solve this particular problem.
>
>> When we try to use hdparm to change it back to UDMA2 (hdparm -d 1 -X 
>> udma2 /dev/hdX) we occasionally get errors.
> ...
>> AND THEN DMA IS DISABLED WHICH IS REALLY BAD FOR OUR SYSTEMS.
>
> Can you use hdparm to enable it again, at least?
Sometimes the hdparm command trying to re-enable DMA fails also.  The 
whole thing is a mess, and whenever the drive rejects/fails a command, 
the dmesg messages look like a drive failure which makes our health 
monitoring systems start to twitch and alarm that the drive might be 
failing.  In fact the drive is probably fine.
>
> If you *have* to run in UDMA2 then you *have* to pitch the systems 
> that don't work.
>
>> I think that trying to set the DMA mode after initialization is maybe 
>> not a good idea.  
> ...
>> By the way the IDE driver in the CentOS 5.x kernel (2.6.18) is not a 
>> module.  My googling has not turned up anything and there is no 
>> kernel command line option for the IDE driver that does this.
>
> I don't know which version it's for, but this:
>
> http://www.kernel.org/doc/Documentation/kernel-parameters.txt
>
> says you can use libata.force to set UDMA 2.  Doesn't it?
The unified multi-platform E-IDE driver does not accept arguments or 
options intended for libata.  Since our drives are IDE not SATA we have 
to live with using only arguments that start with ide=.  I actually 
tried libata stuff before figuring out that a) our devices were not 
using any libata driver, and b) libata is a module and you have to give 
it module options, and putting arguments for libata on the kernel 
command line won't work.

Thanks,
Jim