LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: hdparm for lib_pata
@ 2007-02-08  2:16 Adam J. Richter
  0 siblings, 0 replies; 25+ messages in thread
From: Adam J. Richter @ 2007-02-08  2:16 UTC (permalink / raw)
  To: adam, patrick.ale; +Cc: linux-kernel, Stephen.Clark

>>> = 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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-07 10:55 Adam J. Richter
@ 2007-02-07 11:47 ` Patrick Ale
  0 siblings, 0 replies; 25+ messages in thread
From: Patrick Ale @ 2007-02-07 11:47 UTC (permalink / raw)
  To: Adam J. Richter; +Cc: Stephen.Clark, linux-kernel

>         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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
@ 2007-02-07 10:55 Adam J. Richter
  2007-02-07 11:47 ` Patrick Ale
  0 siblings, 1 reply; 25+ messages in thread
From: Adam J. Richter @ 2007-02-07 10:55 UTC (permalink / raw)
  To: Stephen.Clark; +Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  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
  2 siblings, 0 replies; 25+ messages in thread
From: Robert Hancock @ 2007-02-06 23:45 UTC (permalink / raw)
  To: Bill Davidsen; +Cc: Stephen.Clark, Patrick Ale, linux-kernel

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 hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  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
  2 siblings, 0 replies; 25+ messages in thread
From: Jeff Garzik @ 2007-02-06 21:05 UTC (permalink / raw)
  To: Bill Davidsen; +Cc: Robert Hancock, Stephen.Clark, Patrick Ale, linux-kernel

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



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  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
  2 siblings, 0 replies; 25+ messages in thread
From: Mark Lord @ 2007-02-06 18:45 UTC (permalink / raw)
  To: Bill Davidsen; +Cc: Robert Hancock, Stephen.Clark, Patrick Ale, linux-kernel

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
 


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-05 18:15   ` Mark Lord
@ 2007-02-06 17:49     ` Bill Davidsen
  0 siblings, 0 replies; 25+ messages in thread
From: Bill Davidsen @ 2007-02-06 17:49 UTC (permalink / raw)
  To: Mark Lord; +Cc: Robert Hancock, Patrick Ale, linux-kernel

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 <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-03 23:28     ` Robert Hancock
@ 2007-02-06 17:44       ` Bill Davidsen
  2007-02-06 18:45         ` Mark Lord
                           ` (2 more replies)
  0 siblings, 3 replies; 25+ messages in thread
From: Bill Davidsen @ 2007-02-06 17:44 UTC (permalink / raw)
  To: Robert Hancock; +Cc: Stephen.Clark, Patrick Ale, linux-kernel

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 <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-05 19:09   ` Alan
@ 2007-02-05 21:19     ` Jeff Garzik
  0 siblings, 0 replies; 25+ messages in thread
From: Jeff Garzik @ 2007-02-05 21:19 UTC (permalink / raw)
  To: Alan; +Cc: Mark Lord, Patrick Ale, linux-kernel

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




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-05 18:13 ` Mark Lord
  2007-02-05 19:09   ` Alan
@ 2007-02-05 19:21   ` Patrick Ale
  1 sibling, 0 replies; 25+ messages in thread
From: Patrick Ale @ 2007-02-05 19:21 UTC (permalink / raw)
  To: Mark Lord; +Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  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
  1 sibling, 1 reply; 25+ messages in thread
From: Alan @ 2007-02-05 19:09 UTC (permalink / raw)
  To: Mark Lord; +Cc: Patrick Ale, linux-kernel

> 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.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-03 19:14 ` Robert Hancock
  2007-02-03 23:15   ` Stephen Clark
@ 2007-02-05 18:15   ` Mark Lord
  2007-02-06 17:49     ` Bill Davidsen
  1 sibling, 1 reply; 25+ messages in thread
From: Mark Lord @ 2007-02-05 18:15 UTC (permalink / raw)
  To: Robert Hancock; +Cc: Patrick Ale, linux-kernel

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-03  8:41 Patrick Ale
  2007-02-03  8:55 ` Patrick Ale
@ 2007-02-05 18:13 ` Mark Lord
  2007-02-05 19:09   ` Alan
  2007-02-05 19:21   ` Patrick Ale
  1 sibling, 2 replies; 25+ messages in thread
From: Mark Lord @ 2007-02-05 18:13 UTC (permalink / raw)
  To: Patrick Ale; +Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-05 14:23             ` Robert Hancock
@ 2007-02-05 16:21               ` Patrick Ale
  0 siblings, 0 replies; 25+ messages in thread
From: Patrick Ale @ 2007-02-05 16:21 UTC (permalink / raw)
  To: Robert Hancock; +Cc: Stephen.Clark, linux-kernel

On 2/5/07, Robert Hancock <hancockr@shaw.ca> 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 :)

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-05 11:00           ` Patrick Ale
@ 2007-02-05 14:23             ` Robert Hancock
  2007-02-05 16:21               ` Patrick Ale
  0 siblings, 1 reply; 25+ messages in thread
From: Robert Hancock @ 2007-02-05 14:23 UTC (permalink / raw)
  To: Patrick Ale; +Cc: Stephen.Clark, linux-kernel

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
> 

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-04  0:18         ` Patrick Ale
@ 2007-02-05 11:00           ` Patrick Ale
  2007-02-05 14:23             ` Robert Hancock
  0 siblings, 1 reply; 25+ messages in thread
From: Patrick Ale @ 2007-02-05 11:00 UTC (permalink / raw)
  To: Stephen.Clark; +Cc: Robert Hancock, linux-kernel

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-04  0:11       ` Stephen Clark
@ 2007-02-04  0:18         ` Patrick Ale
  2007-02-05 11:00           ` Patrick Ale
  0 siblings, 1 reply; 25+ messages in thread
From: Patrick Ale @ 2007-02-04  0:18 UTC (permalink / raw)
  To: Stephen.Clark; +Cc: Robert Hancock, linux-kernel

On 2/4/07, Stephen Clark <Stephen.Clark@seclark.us> 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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-03 23:44     ` Patrick Ale
@ 2007-02-04  0:11       ` Stephen Clark
  2007-02-04  0:18         ` Patrick Ale
  0 siblings, 1 reply; 25+ messages in thread
From: Stephen Clark @ 2007-02-04  0:11 UTC (permalink / raw)
  To: Patrick Ale; +Cc: Robert Hancock, linux-kernel

Patrick Ale wrote:

>On 2/4/07, Stephen Clark <Stephen.Clark@seclark.us> 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)




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-03 23:15   ` Stephen Clark
  2007-02-03 23:28     ` Robert Hancock
@ 2007-02-03 23:44     ` Patrick Ale
  2007-02-04  0:11       ` Stephen Clark
  1 sibling, 1 reply; 25+ messages in thread
From: Patrick Ale @ 2007-02-03 23:44 UTC (permalink / raw)
  To: Stephen.Clark; +Cc: Robert Hancock, linux-kernel

On 2/4/07, Stephen Clark <Stephen.Clark@seclark.us> 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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-03 23:15   ` Stephen Clark
@ 2007-02-03 23:28     ` Robert Hancock
  2007-02-06 17:44       ` Bill Davidsen
  2007-02-03 23:44     ` Patrick Ale
  1 sibling, 1 reply; 25+ messages in thread
From: Robert Hancock @ 2007-02-03 23:28 UTC (permalink / raw)
  To: Stephen.Clark; +Cc: Patrick Ale, linux-kernel

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 hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-03 19:14 ` Robert Hancock
@ 2007-02-03 23:15   ` Stephen Clark
  2007-02-03 23:28     ` Robert Hancock
  2007-02-03 23:44     ` Patrick Ale
  2007-02-05 18:15   ` Mark Lord
  1 sibling, 2 replies; 25+ messages in thread
From: Stephen Clark @ 2007-02-03 23:15 UTC (permalink / raw)
  To: Robert Hancock; +Cc: Patrick Ale, linux-kernel

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)




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
       [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-05 18:15   ` Mark Lord
  0 siblings, 2 replies; 25+ messages in thread
From: Robert Hancock @ 2007-02-03 19:14 UTC (permalink / raw)
  To: Patrick Ale; +Cc: linux-kernel

> 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 hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  2007-02-03  8:55 ` Patrick Ale
@ 2007-02-03 12:07   ` Rene Rebe
  0 siblings, 0 replies; 25+ messages in thread
From: Rene Rebe @ 2007-02-03 12:07 UTC (permalink / raw)
  To: Patrick Ale; +Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: hdparm for lib_pata
  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
  1 sibling, 1 reply; 25+ messages in thread
From: Patrick Ale @ 2007-02-03  8:55 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* hdparm for lib_pata
@ 2007-02-03  8:41 Patrick Ale
  2007-02-03  8:55 ` Patrick Ale
  2007-02-05 18:13 ` Mark Lord
  0 siblings, 2 replies; 25+ messages in thread
From: Patrick Ale @ 2007-02-03  8:41 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2007-02-08  2:28 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-08  2:16 hdparm for lib_pata Adam J. Richter
  -- strict thread matches above, loose matches on Subject: below --
2007-02-07 10:55 Adam J. Richter
2007-02-07 11:47 ` Patrick Ale
     [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

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).