[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <45C51A80.3050308@shaw.ca>
Date: Sat, 03 Feb 2007 17:28:00 -0600
From: Robert Hancock <hancockr@...w.ca>
To: Stephen.Clark@...lark.us
Cc: Patrick Ale <patrick.ale@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: hdparm for lib_pata
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@...pamshaw.ca
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists