lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ