All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Robert Hancock <hancockr@shaw.ca>
Cc: Stephen.Clark@seclark.us, Patrick Ale <patrick.ale@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: hdparm for lib_pata
Date: Tue, 06 Feb 2007 12:44:41 -0500	[thread overview]
Message-ID: <45C8BE89.9000705@tmr.com> (raw)
In-Reply-To: <45C51A80.3050308@shaw.ca>

Robert Hancock wrote:
> 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


> 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.
> 
I think deciding to turn off DMA which works fine in old kernels 
qualifies as a "serious driver problem," which is why it should be under 
user control.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot


  reply	other threads:[~2007-02-06 18:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.L/RjDlo6Njb5Jt7/9ENZuiASoV0@ifi.uio.no>
2007-02-03 19:14 ` hdparm for lib_pata Robert Hancock
2007-02-03 23:15   ` Stephen Clark
2007-02-03 23:28     ` Robert Hancock
2007-02-06 17:44       ` Bill Davidsen [this message]
2007-02-06 18:45         ` Mark Lord
2007-02-06 21:05         ` Jeff Garzik
2007-02-06 23:45         ` Robert Hancock
2007-02-03 23:44     ` Patrick Ale
2007-02-04  0:11       ` Stephen Clark
2007-02-04  0:18         ` Patrick Ale
2007-02-05 11:00           ` Patrick Ale
2007-02-05 14:23             ` Robert Hancock
2007-02-05 16:21               ` Patrick Ale
2007-02-05 18:15   ` Mark Lord
2007-02-06 17:49     ` Bill Davidsen
2007-02-08  2:16 Adam J. Richter
  -- strict thread matches above, loose matches on Subject: below --
2007-02-07 10:55 Adam J. Richter
2007-02-07 11:47 ` Patrick Ale
2007-02-03  8:41 Patrick Ale
2007-02-03  8:55 ` Patrick Ale
2007-02-03 12:07   ` Rene Rebe
2007-02-05 18:13 ` Mark Lord
2007-02-05 19:09   ` Alan
2007-02-05 21:19     ` Jeff Garzik
2007-02-05 19:21   ` Patrick Ale

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45C8BE89.9000705@tmr.com \
    --to=davidsen@tmr.com \
    --cc=Stephen.Clark@seclark.us \
    --cc=hancockr@shaw.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patrick.ale@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.