Hi guys,
Me again, sorry.
Is it possible to make hdparm work with libata?
I have some drives that for some reason fall back to lower UDMA
settings (like UDMA/44) while the drive is UDMA/100. I blame the way I
set-up my raid arrays for this and the bus not being able to handle
all the data that goes trough it but that isnt really the case now.
Anyway, I used to be able to force the drive back with using hdparm
-X68 -d 1 /dev/sdk
But with the new lib_pata drivers I get "Inappropriate iotcl for
device" and HD_IO_DRIVE_CMD Input/Output errors.
Or! Is there some other way to force the drive not to failback to
lower UDMA settings? (Yep, I know, if this is answer, it's my risk, I
cant and wont blame you for destructing my pr0n or severe trauma I
suffer from losing data)
Patrick
Hi,
The problem is even worse, the drive falls back to PIO mode and there
is no way I can get it back to dma mode (like I could by using
hdparm). The only thing i can do is reboot the machine so it will see
the drive is UDMA capable.
If there is some beta/gamma software around or something you'd like to
have tested, you can mail me directly, my machine is your private
prostitute at the moment, it's not like i have something important to
do with the machine anyway (not related to this problem):)
Patrick
On Saturday 03 February 2007 09:55:52 Patrick Ale wrote:
> Hi,
>
> The problem is even worse, the drive falls back to PIO mode and there
> is no way I can get it back to dma mode (like I could by using
> hdparm). The only thing i can do is reboot the machine so it will see
> the drive is UDMA capable.
>
> If there is some beta/gamma software around or something you'd like to
> have tested, you can mail me directly, my machine is your private
> prostitute at the moment, it's not like i have something important to
> do with the machine anyway (not related to this problem):)
The libata expoted disls have a SCSI ioctl interface, sdparm should
work on those.
--
Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
+49 (0)30 / 255 897 45
> Hi guys,
>
> Me again, sorry.
>
> Is it possible to make hdparm work with libata?
> I have some drives that for some reason fall back to lower UDMA
> settings (like UDMA/44) while the drive is UDMA/100. I blame the way I
> set-up my raid arrays for this and the bus not being able to handle
> all the data that goes trough it but that isnt really the case now.
>
> Anyway, I used to be able to force the drive back with using hdparm
> -X68 -d 1 /dev/sdk
> But with the new lib_pata drivers I get "Inappropriate iotcl for
> device" and HD_IO_DRIVE_CMD Input/Output errors.
>
> Or! Is there some other way to force the drive not to failback to
> lower UDMA settings? (Yep, I know, if this is answer, it's my risk, I
> cant and wont blame you for destructing my pr0n or severe trauma I
> suffer from losing data)
Only some of the hdparm functionality is supported in libata, which is
partially by design. Presently there's no way to override the DMA
settings in libata, it starts out at the fastest supported settings and
falls back if it gets too many errors of certain types.
You shouldn't be seeing errors like this unless you have bad IDE cables
or are using 40-wire cables with high UDMA modes. Can you post the
output you're seeing?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Robert Hancock wrote:
>>Hi guys,
>>
>>Me again, sorry.
>>
>>Is it possible to make hdparm work with libata?
>>I have some drives that for some reason fall back to lower UDMA
>>settings (like UDMA/44) while the drive is UDMA/100. I blame the way I
>>set-up my raid arrays for this and the bus not being able to handle
>>all the data that goes trough it but that isnt really the case now.
>>
>>Anyway, I used to be able to force the drive back with using hdparm
>>-X68 -d 1 /dev/sdk
>>But with the new lib_pata drivers I get "Inappropriate iotcl for
>>device" and HD_IO_DRIVE_CMD Input/Output errors.
>>
>>Or! Is there some other way to force the drive not to failback to
>>lower UDMA settings? (Yep, I know, if this is answer, it's my risk, I
>>cant and wont blame you for destructing my pr0n or severe trauma I
>>suffer from losing data)
>>
>>
>
>Only some of the hdparm functionality is supported in libata, which is
>partially by design. Presently there's no way to override the DMA
>settings in libata, it starts out at the fastest supported settings and
>falls back if it gets too many errors of certain types.
>
>You shouldn't be seeing errors like this unless you have bad IDE cables
>or are using 40-wire cables with high UDMA modes. Can you post the
>output you're seeing?
>
>
>
Ok,
But why are we taking away the users capability to control his/her own
hardware. Sounds like windows.
My $.02
Steve Clark
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
Stephen Clark wrote:
>> Only some of the hdparm functionality is supported in libata, which is
>> partially by design. Presently there's no way to override the DMA
>> settings in libata, it starts out at the fastest supported settings
>> and falls back if it gets too many errors of certain types.
>>
>> You shouldn't be seeing errors like this unless you have bad IDE
>> cables or are using 40-wire cables with high UDMA modes. Can you post
>> the output you're seeing?
>>
> Ok,
>
> But why are we taking away the users capability to control his/her own
> hardware. Sounds like windows.
>
> My $.02
> Steve Clark
A lot of those hdparm commands are legacy cruft from the old drivers/ide
setup and just aren't needed with libata. For example, I think a major
use for the enable/disable DMA option was for screwy distro setups where
all the IDE drivers were built modular and the IDE core would load some
generic support for the controller, then the device-specific driver
module would get loaded and then you'd have to switch DMA on manually
afterwards. (The old IDE drivers never really seemed to play well with
being built as modules, probably a big reason why Red Hat/Fedora have
always built them into the kernel.)
Support for that ioctl could likely be added, but these days I don't
think there's much use for it. I can't see how anybody in their right
mind would want to disable DMA on a modern drive, and if libata turns it
off automatically then there's likely some serious hardware or driver
problem that will end up biting you some other way if you force it back on.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On 2/4/07, Stephen Clark <[email protected]> wrote:
> Robert Hancock wrote:
> But why are we taking away the users capability to control his/her own
> hardware. Sounds like windows.
I wouldn't go as far as making that comparsion, most of all cause it's
totaly invalid, with all respect.
In my opinion the new pata drivers are work in progress, they only
appear in the latest kernel and snapshots so please, let's allow the
drivers to evolve, I am no kernel hacker or coder, nor does my
interest lay here at the moment to be honest, I am a system
administrator working with Unix and Linux and am interested in helping
out where I can. By using the new pata drivers in favor of the old IDE
drivers I took a risk, well calculated and with the very thought of
encountering these kind of problems and reporting them to make things
better.
However, I do have to agree with the point that if the drivers/kernel,
for whatever reason they might have, to switch to a lower UDMA mode,
and when none is left, even to PIO mode, I should have at least the
chance to switch back to a higher level of datatransfer speed.
How it looks now is that the kernel and its drivers treat the devices
as ATA devices with their features, but the userland programs like
hdparm and sdparm and blkutil see the devices as SCSI/SATA devices,
and dont allow the ioctl commands which are valid for ATA drives.
Just my two euros/canadian dollars/croatian kunas in the pocket :)
Patrick
Patrick Ale wrote:
>On 2/4/07, Stephen Clark <[email protected]> wrote:
>
>
>>Robert Hancock wrote:
>>
>>
>
>
>
>>But why are we taking away the users capability to control his/her own
>>hardware. Sounds like windows.
>>
>>
>
>I wouldn't go as far as making that comparsion, most of all cause it's
>totaly invalid, with all respect.
>
>In my opinion the new pata drivers are work in progress, they only
>appear in the latest kernel and snapshots so please, let's allow the
>drivers to evolve, I am no kernel hacker or coder, nor does my
>interest lay here at the moment to be honest, I am a system
>administrator working with Unix and Linux and am interested in helping
>out where I can. By using the new pata drivers in favor of the old IDE
>drivers I took a risk, well calculated and with the very thought of
>encountering these kind of problems and reporting them to make things
>better.
>
>However, I do have to agree with the point that if the drivers/kernel,
>for whatever reason they might have, to switch to a lower UDMA mode,
>and when none is left, even to PIO mode, I should have at least the
>chance to switch back to a higher level of datatransfer speed.
>
>How it looks now is that the kernel and its drivers treat the devices
>as ATA devices with their features, but the userland programs like
>hdparm and sdparm and blkutil see the devices as SCSI/SATA devices,
>and dont allow the ioctl commands which are valid for ATA drives.
>
>Just my two euros/canadian dollars/croatian kunas in the pocket :)
>
>Patrick
>
>
>
My point is that the driver can't be tested on every combination of
hardware, so if the user
doesn't have the capability to override assumptions the driver makes
then he is stuck.
I have had two different laptops that had to have boot time command line
overrides to get the
driver to allow the hardware work at what it was spec-ed at.
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
On 2/4/07, Stephen Clark <[email protected]> wrote:
> I have had two different laptops that had to have boot time command line
> overrides to get the
> driver to allow the hardware work at what it was spec-ed at.
Well, I am sure that someone will at least take the problem I have
serious and will give me a good alternative to get things working,
which isnt always the case with mickeysoft :D
But again, yes, I do agree that if someone/something decides to reduce
my transferspeed I should have an option to override that decision or
tell the thing not to make that decision.
Patrick
Good morning all,
About the reason as of why it drops to PIO mode, I might have found
the reason for this, I am just not sure if what i found is related.
When I opened my Athlon XP machine, took the cables out and replaced
them for new cables, I found out that my southbridge fan wasnt
spinning anymore, at all.
So my guess is that this chip is overheated at some point and starts
causing problems.
Now, it was always my comprehension that the southbridge does indeed
control the ATA controller but only the onboard one, so even if the
chip is having heat problems, my PCI add-on cards should still work on
full UDMA100 speed, right?
I am re-assembling my athlon board again today, and as soon as I get
the falling back to PIO mode errors again in dmesg I'll forward you
the messages, like you asked :)
If someone could shine a light on my question about the southbridge,
I'd really appriciate it, email me privately if you prefer.
Thanks!
Patrick
Patrick Ale wrote:
> Good morning all,
>
> About the reason as of why it drops to PIO mode, I might have found
> the reason for this, I am just not sure if what i found is related.
>
> When I opened my Athlon XP machine, took the cables out and replaced
> them for new cables, I found out that my southbridge fan wasnt
> spinning anymore, at all.
>
> So my guess is that this chip is overheated at some point and starts
> causing problems.
> Now, it was always my comprehension that the southbridge does indeed
> control the ATA controller but only the onboard one, so even if the
> chip is having heat problems, my PCI add-on cards should still work on
> full UDMA100 speed, right?
The southbridge usually runs the PCI bus connected to the slots, so it's
possible that PCI bus issues were causing problems..
>
> I am re-assembling my athlon board again today, and as soon as I get
> the falling back to PIO mode errors again in dmesg I'll forward you
> the messages, like you asked :)
>
> If someone could shine a light on my question about the southbridge,
> I'd really appriciate it, email me privately if you prefer.
>
> Thanks!
>
> Patrick
>
On 2/5/07, Robert Hancock <[email protected]> wrote:
> Patrick Ale wrote:
> The southbridge usually runs the PCI bus connected to the slots, so it's
> possible that PCI bus issues were causing problems..
Explains a lot then yeah... okay, if the error occures again I will
let you know, I am booting up as we speak :)
Patrick Ale wrote:
> Hi guys,
>
> Me again, sorry.
>
> Is it possible to make hdparm work with libata?
It already works fine with libata.
..
> Anyway, I used to be able to force the drive back with using hdparm
> -X68 -d 1 /dev/sdk
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 (?).
Cheers
Robert Hancock wrote:
>..
> Only some of the hdparm functionality is supported in libata,
That's not true. MOST hdparm functionality is supported in libata.
Only a very few things are not supported, including -d and -X,
for reasons already pointed out.
Nearly everything else works.
-ml
> Userspace PIO mode changes are NOT a good idea,
I would disagree there, but they are not high priority. We do need to
allow set_features/xfer but we need to snoop it and mode set properly
around it. There are cases you want to control this, more so admittedly
for DMA speeds.
\
> 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
Alan wrote:
>> Userspace PIO mode changes are NOT a good idea,
>
> I would disagree there, but they are not high priority. We do need to
> allow set_features/xfer but we need to snoop it and mode set properly
> around it. There are cases you want to control this, more so admittedly
> for DMA speeds.
*Bingo*
That's the entire reason why libata does not support hdparm changing
modes, etc.: there is a lot involved in allowing random SET FEATURES -
XFER MODE commands from userspace. In some cases you have to stop all
traffic on ports B,C,D,... in order to change the speed on port A.
Jeff
Mark Lord wrote:
> Robert Hancock wrote:
>> ..
>> Only some of the hdparm functionality is supported in libata,
>
> That's not true. MOST hdparm functionality is supported in libata.
> Only a very few things are not supported, including -d and -X,
> for reasons already pointed out.
>
> Nearly everything else works.
>
Agreed, I've already had problems typing faster than I think, twice, as
as I hit ENTER saying "wait, that's a SCSI device" and then "wow, it
worked anyway!" Nice job on the whole, but setting transfer modes is
desirable, still.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
Robert Hancock wrote:
> Stephen Clark wrote:
>>> Only some of the hdparm functionality is supported in libata, which
>>> is partially by design. Presently there's no way to override the DMA
>>> settings in libata, it starts out at the fastest supported settings
>>> and falls back if it gets too many errors of certain types.
>>>
>>> You shouldn't be seeing errors like this unless you have bad IDE
>>> cables or are using 40-wire cables with high UDMA modes. Can you post
>>> the output you're seeing?
>>>
>> Ok,
>>
>> But why are we taking away the users capability to control his/her own
>> hardware. Sounds like windows.
>>
>> My $.02
>> Steve Clark
> Support for that ioctl could likely be added, but these days I don't
> think there's much use for it. I can't see how anybody in their right
> mind would want to disable DMA on a modern drive, and if libata turns it
> off automatically then there's likely some serious hardware or driver
> problem that will end up biting you some other way if you force it back on.
>
I think deciding to turn off DMA which works fine in old kernels
qualifies as a "serious driver problem," which is why it should be under
user control.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
re: hdparm -d
>> Support for that ioctl could likely be added, but these days I don't
>> think there's much use for it. I can't see how anybody in their right
>> mind would want to disable DMA on a modern drive, and if libata turns
>> it off automatically then there's likely some serious hardware or
>> driver problem that will end up biting you some other way if you force
>> it back on.
>>
> I think deciding to turn off DMA which works fine in old kernels
> qualifies as a "serious driver problem," which is why it should be under
> user control.
Fair enough.
The original reason for that functionality in the drivers/ide stuff,
was that I wanted a way to be able to continue to test the IDE driver
in PIO mode, despite all of my own devices having good DMA support.
If there's no way to force the driver to use a particular transfer
method, then it becomes difficult to (re)test the driver over time.
Cheers
Bill Davidsen wrote:
> I think deciding to turn off DMA which works fine in old kernels
> qualifies as a "serious driver problem," which is why it should be under
> user control.
For PATA, perhaps.
For SATA, turning off DMA can often -cause- additional problems.
Jeff
Bill Davidsen wrote:
>> Support for that ioctl could likely be added, but these days I don't
>> think there's much use for it. I can't see how anybody in their right
>> mind would want to disable DMA on a modern drive, and if libata turns
>> it off automatically then there's likely some serious hardware or
>> driver problem that will end up biting you some other way if you force
>> it back on.
>>
> I think deciding to turn off DMA which works fine in old kernels
> qualifies as a "serious driver problem," which is why it should be under
> user control.
Point is, if the DMA's not working such that the system decides to turn
it off, it's obviously having some issues, and thus turning it back on
without fixing the problem could cause problems or even cause data
corruption.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On 2007-02-04 Stephen Clark wrote:
>I have had two different laptops that had to have boot time command line
>overrides to get the
>driver to allow the hardware work at what it was spec-ed at.
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 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.
Adam Richter
> 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
>>> = Stephen Clark
>> = Adam Richter
> = Patrick Ale
>> 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?
[...]
>Then, after 2 hours, and resyncing RAID1 MD 1 devices, I started
>seeing things like:
>"Drive not ready"
>"DMA timeout on ..."
I was not asking about Patrick's desktop computer, which was already
established to be hardware problem that was fixed by replacing a
broken fan. I was asking about Stephen Clark's two laptop computers,
which seemed like they might be examples of a need for user level
hdparm DMA setting, which is why I prefaced my question with the
following quotation:
>>On 2007-02-04 Stephen Clark wrote:
>>>I have had two different laptops that had to have boot time command line
>>>overrides to get the
>>>driver to allow the hardware work at what it was spec-ed at.
Adam Richter