Re: hdparm for lib_pata

[Robert Hancock <hancockr@shaw.ca>]

Stephen Clark wrote:
>> Only some of the hdparm functionality is supported in libata, which is 
>> partially by design. Presently there's no way to override the DMA 
>> settings in libata, it starts out at the fastest supported settings 
>> and falls back if it gets too many errors of certain types.
>>
>> You shouldn't be seeing errors like this unless you have bad IDE 
>> cables or are using 40-wire cables with high UDMA modes. Can you post 
>> the output you're seeing?
>>
> Ok,
> 
> But why are we taking away the users capability to control his/her own 
> hardware. Sounds like windows.
> 
> My $.02
> Steve Clark

A lot of those hdparm commands are legacy cruft from the old drivers/ide 
setup and just aren't needed with libata. For example, I think a major 
use for the enable/disable DMA option was for screwy distro setups where 
all the IDE drivers were built modular and the IDE core would load some 
generic support for the controller, then the device-specific driver 
module would get loaded and then you'd have to switch DMA on manually 
afterwards. (The old IDE drivers never really seemed to play well with 
being built as modules, probably a big reason why Red Hat/Fedora have 
always built them into the kernel.)

Support for that ioctl could likely be added, but these days I don't 
think there's much use for it. I can't see how anybody in their right 
mind would want to disable DMA on a modern drive, and if libata turns it 
off automatically then there's likely some serious hardware or driver 
problem that will end up biting you some other way if you force it back on.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/