linux-kernel - Re: hdparm for lib

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8d158e1f0702051121w6e8a840dm1044ca73d3f6f47@mail.gmail.com>
Date:	Mon, 5 Feb 2007 20:21:11 +0100
From:	"Patrick Ale" <patrick.ale@...il.com>
To:	"Mark Lord" <lkml@....ca>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: hdparm for lib_pata

\
> 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
-
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/