[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8d158e1f0702070347n4398c878i1b591d09e9c25d48@mail.gmail.com>
Date: Wed, 7 Feb 2007 12:47:23 +0100
From: "Patrick Ale" <patrick.ale@...il.com>
To: "Adam J. Richter" <adam@...drasil.com>
Cc: Stephen.Clark@...lark.us, linux-kernel@...r.kernel.org
Subject: Re: hdparm for lib_pata
> 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
-
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