LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Patrick Ale" <patrick.ale@gmail.com>
To: "Mark Lord" <lkml@rtr.ca>
Cc: linux-kernel@vger.kernel.org
Subject: Re: hdparm for lib_pata
Date: Mon, 5 Feb 2007 20:21:11 +0100	[thread overview]
Message-ID: <8d158e1f0702051121w6e8a840dm1044ca73d3f6f47@mail.gmail.com> (raw)
In-Reply-To: <45C773D6.3010009@rtr.ca>

\
> Userspace PIO mode changes are NOT a good idea,
> and I doubt that libata would want to support that feature.
> The "-d" flag (enable/disable DMA) is currently not implemented
> by libata, though there may be a /sys/.. attribute for it (?).
>
Okay but... the driver itself does implement the calls, maybe in
another way but it does switch from DMA to PIO. At boot time it uses
UDMA100 and after some transfer speed downgrades even tells me how
there is no lower mode available (which means its running in PIO mode
1 I guess).

I agree that its not a good idea, and in normal cases, you wont even
need it cause your hardware works properly. I had a closer look at my
old kernel logs, and different from the old ata drivers, the new
libsata drivers probe every disk for its UDMA capabilities and sets
them per drive, also on a bus reset, rather than resetting the entire
bus and using the same transfer setting for all drives on that bus
(which is what i saw happening with my  promise IDE card and the old
IDE drivers.

So, with the new drivers, one failing disk doesnt drag the other disk
with him into PIO mode, at least, this is how I see things on my
screen and how I experience it.

The disk that does fall back to PIO mode probably does have  a serious
problem or, in my case, the entire southbridge is overheated causing
lots of PCI problems (thanks Robert, for the point out, I changed the
powersuply and the southbridge fan and all works great now).

So, yeah, in general I like the idea of being in control of my
machine, how dangerous that might be, but in the case of libsata and
my experience with the new pata drivers so far, the driver knows
what's best for me and acts like it and building some overriding
controls for userspace just will break things, if not totaly destroy
it.

Actually all problems I had so far with libsata were pointable to my
stupidity (hello CONFIG_DEV_SD) or hardware that was totaly failing.
So, I give two thumbs up to the new libsata/pata drivers, I really
like the way they work and I truely see advantages using them over the
old IDE drivers, not in the last place cause it is much easier to see
disk/bus problems now since I find the ATA messages in the kernel log
regarding what is done with my disks way more clear.

So Alan, Robert, everybody else who helped me with migrating to
libsata from the old IDE drivers, thanks a lot, your help was and is
highly appriciated.

Patrick

  parent reply	other threads:[~2007-02-05 19:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
     [not found] <fa.L/RjDlo6Njb5Jt7/9ENZuiASoV0@ifi.uio.no>
2007-02-03 19:14 ` Robert Hancock
2007-02-03 23:15   ` Stephen Clark
2007-02-03 23:28     ` Robert Hancock
2007-02-06 17:44       ` Bill Davidsen
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-07 10:55 Adam J. Richter
2007-02-07 11:47 ` Patrick Ale
2007-02-08  2:16 Adam J. Richter

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=8d158e1f0702051121w6e8a840dm1044ca73d3f6f47@mail.gmail.com \
    --to=patrick.ale@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@rtr.ca \
    --subject='Re: hdparm for lib_pata' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).