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

[Angelo Bertolli]

Jim Ockers wrote:
> 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.

Well I guess the way you're SUPPOSED to do it is by editing hdparm.conf, 
but I'm not sure that gets you what you want since you want the kernel 
to do it automatically on boot.  But if you haven't done that already, 
it's worth a try since it's quick and who knows--maybe it's magic.

Angelo