LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Patrick Ale" <patrick.ale@gmail.com>
To: "Adam J. Richter" <adam@yggdrasil.com>
Cc: Stephen.Clark@seclark.us, linux-kernel@vger.kernel.org
Subject: Re: hdparm for lib_pata
Date: Wed, 7 Feb 2007 12:47:23 +0100	[thread overview]
Message-ID: <8d158e1f0702070347n4398c878i1b591d09e9c25d48@mail.gmail.com> (raw)
In-Reply-To: <200702071055.l17AtrZf014135@freya.yggdrasil.com>

>         Do you know if these drives were advertising less capability
> than they were spec-ed at?  Do you recall if the IDE driver without
> kernel arguments printed its rationale for reverting to the slower
> setting?

I can only speak for myself of course.
On boot time the libsata driver detected my harddisks were capable of
UDMA100, and used it.

Then, after 2 hours, and resyncing RAID1 MD 1 devices, I started
seeing things like:
"Drive not ready"
"DMA timeout on ..."

After this, I saw a bus reset, the master disk (the one with problems)
reverted to UDMA/44 and the slave (no problems appearantly staid
(stayed?) at UDMA100.

Then, after literaly some minutes, same messages, "Drive not ready" ,
"DMA timeout". And it went to an even lower UDMA mode, till the point
it was out of UDMA modes, switched to PIO, and when it dropped to the
lowest PIO mode, it just said how it couldnt go any lower

>         I ask because I'd like to know if this sort of thing can ever
> happen with libata.  If so, then that is yet another reason to have
> the ability to override DMA settings from user level in libata.

Please note: I DID have problems, major ones, So yes, libsata does
fall back to slower transfer modes, but as far of my experience
concerned, not without a reason which should be addressed.


Patrick

  reply	other threads:[~2007-02-07 11:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-07 10:55 Adam J. Richter
2007-02-07 11:47 ` Patrick Ale [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-02-08  2:16 Adam J. Richter
     [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-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=8d158e1f0702070347n4398c878i1b591d09e9c25d48@mail.gmail.com \
    --to=patrick.ale@gmail.com \
    --cc=Stephen.Clark@seclark.us \
    --cc=adam@yggdrasil.com \
    --cc=linux-kernel@vger.kernel.org \
    --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).