[PATCH 1/3] Make the IDE DMA timeout modifiable

[PATCH 1/3] Make the IDE DMA timeout modifiable

[Suleiman Souhlal]

It can be changed via /proc/ide/hd?/settings.

Signed-off-by:	Ed Falk <efalk@google.com>

---
 drivers/ide/ide-dma.c |    3 ++-
 drivers/ide/ide.c     |    2 ++
 include/linux/ide.h   |    3 +++
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c
index 08e7cd0..a8da725 100644
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -579,7 +579,8 @@ EXPORT_SYMBOL_GPL(ide_dma_setup);
 static void ide_dma_exec_cmd(ide_drive_t *drive, u8 command)
 {
 	/* issue cmd to drive */
-	ide_execute_command(drive, command, &ide_dma_intr, 2*WAIT_CMD, dma_timer_expiry);
+	ide_execute_command(drive, command, &ide_dma_intr, drive->dma_timeout,
+	    dma_timer_expiry);
 }
 
 void ide_dma_start(ide_drive_t *drive)
diff --git a/drivers/ide/ide.c b/drivers/ide/ide.c
index b3c0818..ca841f2 100644
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -245,6 +245,7 @@ static void init_hwif_data(ide_hwif_t *h
 		drive->name[1]			= 'd';
 		drive->name[2]			= 'a' + (index * MAX_DRIVES) + unit;
 		drive->max_failures		= IDE_DEFAULT_MAX_FAILURES;
+		drive->dma_timeout		= WAIT_DMA;
 		drive->using_dma		= 0;
 		drive->vdma			= 0;
 		INIT_LIST_HEAD(&drive->list);
@@ -1197,6 +1198,7 @@ void ide_add_generic_settings (ide_drive
 	__ide_add_setting(drive,	"init_speed",		SETTING_RW,					-1,			-1,			TYPE_BYTE,	0,	70,				1,		1,		&drive->init_speed,		NULL,		0);
 	__ide_add_setting(drive,	"current_speed",	SETTING_RW,					-1,			-1,			TYPE_BYTE,	0,	70,				1,		1,		&drive->current_speed,		set_xfer_rate,	0);
 	__ide_add_setting(drive,	"number",		SETTING_RW,					-1,			-1,			TYPE_BYTE,	0,	3,				1,		1,		&drive->dn,			NULL,		0);
+	__ide_add_setting(drive,	"dma_timeout",		SETTING_RW,					-1,			-1,			TYPE_INT,	0,	2000000000,			1,		1,		&drive->dma_timeout,		NULL,		0);
 }
 
 /**
diff --git a/include/linux/ide.h b/include/linux/ide.h
index 79c0282..3861753 100644
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -183,6 +183,7 @@ #define WAIT_READY	(5*HZ)		/* 5sec - som
 #define WAIT_PIDENTIFY	(10*HZ)	/* 10sec  - should be less than 3ms (?), if all ATAPI CD is closed at boot */
 #define WAIT_WORSTCASE	(30*HZ)	/* 30sec  - worst case when spinning up */
 #define WAIT_CMD	(10*HZ)	/* 10sec  - maximum wait for an IRQ to happen */
+#define WAIT_DMA	(20*HZ)	/* 20sec  - maximum wait for an IRQ to happen */
 #define WAIT_MIN_SLEEP	(2*HZ/100)	/* 20msec - minimum sleep time */
 
 /*
@@ -638,6 +639,8 @@ typedef struct ide_drive_s {
 	unsigned int	drive_data;	/* use by tuneproc/selectproc */
 	unsigned int	failures;	/* current failure count */
 	unsigned int	max_failures;	/* maximum allowed failure count */
+	int		dma_timeout;	/* number of jiffies to wait for a
+					  dma to complete */
 	u64		probed_capacity;/* initial reported media capacity (ide-cd only currently) */
 
 	u64		capacity64;	/* total number of sectors */

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Bartlomiej Zolnierkiewicz]

On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:
> It can be changed via /proc/ide/hd?/settings.

Why do we need to change IDE DMA timeout dynamically?

BTW /proc/ide/hd?/settings is obsoleted

> Signed-off-by:	Ed Falk <efalk@google.com>
> 
> ---
>  drivers/ide/ide-dma.c |    3 ++-
>  drivers/ide/ide.c     |    2 ++
>  include/linux/ide.h   |    3 +++
>  3 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c
> index 08e7cd0..a8da725 100644
> --- a/drivers/ide/ide-dma.c
> +++ b/drivers/ide/ide-dma.c
> @@ -579,7 +579,8 @@ EXPORT_SYMBOL_GPL(ide_dma_setup);
>  static void ide_dma_exec_cmd(ide_drive_t *drive, u8 command)
>  {
>  	/* issue cmd to drive */
> -	ide_execute_command(drive, command, &ide_dma_intr, 2*WAIT_CMD, dma_timer_expiry);
> +	ide_execute_command(drive, command, &ide_dma_intr, drive->dma_timeout,
> +	    dma_timer_expiry);
>  }
>  
>  void ide_dma_start(ide_drive_t *drive)
> diff --git a/drivers/ide/ide.c b/drivers/ide/ide.c
> index b3c0818..ca841f2 100644
> --- a/drivers/ide/ide.c
> +++ b/drivers/ide/ide.c
> @@ -245,6 +245,7 @@ static void init_hwif_data(ide_hwif_t *h
>  		drive->name[1]			= 'd';
>  		drive->name[2]			= 'a' + (index * MAX_DRIVES) + unit;
>  		drive->max_failures		= IDE_DEFAULT_MAX_FAILURES;
> +		drive->dma_timeout		= WAIT_DMA;
>  		drive->using_dma		= 0;
>  		drive->vdma			= 0;
>  		INIT_LIST_HEAD(&drive->list);
> @@ -1197,6 +1198,7 @@ void ide_add_generic_settings (ide_drive
>  	__ide_add_setting(drive,	"init_speed",		SETTING_RW,					-1,			-1,			TYPE_BYTE,	0,	70,				1,		1,		&drive->init_speed,		NULL,		0);
>  	__ide_add_setting(drive,	"current_speed",	SETTING_RW,					-1,			-1,			TYPE_BYTE,	0,	70,				1,		1,		&drive->current_speed,		set_xfer_rate,	0);
>  	__ide_add_setting(drive,	"number",		SETTING_RW,					-1,			-1,			TYPE_BYTE,	0,	3,				1,		1,		&drive->dn,			NULL,		0);
> +	__ide_add_setting(drive,	"dma_timeout",		SETTING_RW,					-1,			-1,			TYPE_INT,	0,	2000000000,			1,		1,		&drive->dma_timeout,		NULL,		0);
>  }
>  
>  /**
> diff --git a/include/linux/ide.h b/include/linux/ide.h
> index 79c0282..3861753 100644
> --- a/include/linux/ide.h
> +++ b/include/linux/ide.h
> @@ -183,6 +183,7 @@ #define WAIT_READY	(5*HZ)		/* 5sec - som
>  #define WAIT_PIDENTIFY	(10*HZ)	/* 10sec  - should be less than 3ms (?), if all ATAPI CD is closed at boot */
>  #define WAIT_WORSTCASE	(30*HZ)	/* 30sec  - worst case when spinning up */
>  #define WAIT_CMD	(10*HZ)	/* 10sec  - maximum wait for an IRQ to happen */
> +#define WAIT_DMA	(20*HZ)	/* 20sec  - maximum wait for an IRQ to happen */
>  #define WAIT_MIN_SLEEP	(2*HZ/100)	/* 20msec - minimum sleep time */
>  
>  /*
> @@ -638,6 +639,8 @@ typedef struct ide_drive_s {
>  	unsigned int	drive_data;	/* use by tuneproc/selectproc */
>  	unsigned int	failures;	/* current failure count */
>  	unsigned int	max_failures;	/* maximum allowed failure count */
> +	int		dma_timeout;	/* number of jiffies to wait for a
> +					  dma to complete */
>  	u64		probed_capacity;/* initial reported media capacity (ide-cd only currently) */
>  
>  	u64		capacity64;	/* total number of sectors */
> 
> 

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Suleiman Souhlal]

On Feb 20, 2007, at 5:44 PM, Bartlomiej Zolnierkiewicz wrote:

>
> On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:
>> It can be changed via /proc/ide/hd?/settings.
>
> Why do we need to change IDE DMA timeout dynamically?

I've used it to test error recovery (for example).

> BTW /proc/ide/hd?/settings is obsoleted

What's the preferred way of changing such settings, these days?

-- Suleiman

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Bartlomiej Zolnierkiewicz]

Hi,

On Wednesday 21 February 2007 03:13, Suleiman Souhlal wrote:
> 
> On Feb 20, 2007, at 5:44 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> >
> > On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:
> >> It can be changed via /proc/ide/hd?/settings.
> >
> > Why do we need to change IDE DMA timeout dynamically?
> 
> I've used it to test error recovery (for example).

Seems quite useable for developers but I would prefer not to
expose it in production kernels for end users.

> > BTW /proc/ide/hd?/settings is obsoleted
> 
> What's the preferred way of changing such settings, these days?

sysfs

ide.c:ide_dev_attrs[] for generic attributes valid for all devices

Thanks,
Bart

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Sergei Shtylyov]

Bartlomiej Zolnierkiewicz wrote:
>>On Feb 20, 2007, at 5:44 PM, Bartlomiej Zolnierkiewicz wrote:

>>>On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:

>>>>It can be changed via /proc/ide/hd?/settings.

>>>Why do we need to change IDE DMA timeout dynamically?

>>I've used it to test error recovery (for example).

> Seems quite useable for developers but I would prefer not to
> expose it in production kernels for end users.

    It seems that I have counter example of a customer asking if this timeout 
can be done configurable. :-)
    BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs, and if DMA is 
not complete or interrupt pending, it may wait 10 more secs...

> Thanks,
> Bart

MBR, Sergei

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Bartlomiej Zolnierkiewicz]

On Tuesday 12 June 2007, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
> >>On Feb 20, 2007, at 5:44 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> >>>On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:
> 
> >>>>It can be changed via /proc/ide/hd?/settings.
> 
> >>>Why do we need to change IDE DMA timeout dynamically?
> 
> >>I've used it to test error recovery (for example).
> 
> > Seems quite useable for developers but I would prefer not to
> > expose it in production kernels for end users.
> 
>     It seems that I have counter example of a customer asking if this timeout 
> can be done configurable. :-)

May I ask what was the rationale for this request?

I have no strong feelings about adding this /proc/ide/ setting but I worry
that it could be (mis)used just to (unreliably) work-around problems...

>     BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs, and if DMA is 
> not complete or interrupt pending, it may wait 10 more secs...

I really don't remember... :)

Maybe Mark or Alan could help with figuring this out.

Thanks,
Bart

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Sergei Shtylyov]

Hello.

Bartlomiej Zolnierkiewicz wrote:

>>>>On Feb 20, 2007, at 5:44 PM, Bartlomiej Zolnierkiewicz wrote:

>>>>>On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:

>>>>>>It can be changed via /proc/ide/hd?/settings.

>>>>>Why do we need to change IDE DMA timeout dynamically?

>>>>I've used it to test error recovery (for example).

>>>Seems quite useable for developers but I would prefer not to
>>>expose it in production kernels for end users.

>>    It seems that I have counter example of a customer asking if this timeout 
>>can be done configurable. :-)

> May I ask what was the rationale for this request?

    Their system seems to become unschedulable for this period of time (DMA 
timeouts happen from time to time) -- at least the keepalive daemon stopped 
replying during this period...

> I have no strong feelings about adding this /proc/ide/ setting but I worry
> that it could be (mis)used just to (unreliably) work-around problems...

>>    BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs, and if DMA is 
>>not complete or interrupt pending, it may wait 10 more secs...

> I really don't remember... :)

> Maybe Mark or Alan could help with figuring this out.

    They also have probably forgotten. :-)

> Thanks,
> Bart

MBR, Sergei

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Mark Lord]

Alan Cox wrote:
> O> >>    BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs, and if DMA is 
>>>> not complete or interrupt pending, it may wait 10 more secs...
>>> I really don't remember... :)
>>> Maybe Mark or Alan could help with figuring this out.
>>     They also have probably forgotten. :-)
> 
> Because that value seemed to work ok. Mark set the timeouts way back in
> history and I never touched most of them.

I've lost the original question from this thread, but the idea of the longish
timeouts was that drive *may* be spun down ("standby"), and thus have to spin
up again to complete media commands.  Back then, drives were much slower at
spinning up than nowadays, and the ATA spec says to allow up to 30 seconds.

So..

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Alan Cox]

O> >>    BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs, and if DMA is 
> >>not complete or interrupt pending, it may wait 10 more secs...
> 
> > I really don't remember... :)
> 
> > Maybe Mark or Alan could help with figuring this out.
> 
>     They also have probably forgotten. :-)

Because that value seemed to work ok. Mark set the timeouts way back in
history and I never touched most of them.

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Sergei Shtylyov]

Hello.

Mark Lord wrote:

>> O> >>    BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs, 
>> and if DMA is

>>>>> not complete or interrupt pending, it may wait 10 more secs...
>>>>
>>>> I really don't remember... :)
>>>> Maybe Mark or Alan could help with figuring this out.

>>>     They also have probably forgotten. :-)

>> Because that value seemed to work ok. Mark set the timeouts way back in
>> history and I never touched most of them.
> 
> 
> I've lost the original question from this thread, but the idea of the 

    The original question concerned specifically the DMA command timeout which 
is twice more than the usual one, WAIT_CMD (10 seconds).

> longish
> timeouts was that drive *may* be spun down ("standby"), and thus have to 
> spin
> up again to complete media commands.  Back then, drives were much slower at
> spinning up than nowadays, and the ATA spec says to allow up to 30 seconds.

    Well, that doesn't explain the DMA case.

MBR, Sergei

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Mark Lord]

Sergei Shtylyov wrote:
> Mark Lord wrote:
> 
>>> O> >>    BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs, 
>>> and if DMA is not complete or interrupt pending, it may wait 10 more secs...
..
>> I've lost the original question from this thread, but the idea of the 
> 
>    The original question concerned specifically the DMA command timeout 
> which is twice more than the usual one, WAIT_CMD (10 seconds).
> 
>> longish
>> timeouts was that drive *may* be spun down ("standby"), and thus have 
>> to spin
>> up again to complete media commands.  Back then, drives were much 
>> slower at
>> spinning up than nowadays, and the ATA spec says to allow up to 30 
>> seconds.
> 
>    Well, that doesn't explain the DMA case.

When a drive is in standby, we don't send it anything special to wake up.
So even DMA commands have to have a long enough timeout to allow
for spinning up.

Cheers

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Sergei Shtylyov]

Mark Lord wrote:

>>> I've lost the original question from this thread, but the idea of the 

>>    The original question concerned specifically the DMA command 
>> timeout which is twice more than the usual one, WAIT_CMD (10 seconds).

>>> longish
>>> timeouts was that drive *may* be spun down ("standby"), and thus have 
>>> to spin
>>> up again to complete media commands.  Back then, drives were much 
>>> slower at
>>> spinning up than nowadays, and the ATA spec says to allow up to 30 
>>> seconds.

>>    Well, that doesn't explain the DMA case.

> When a drive is in standby, we don't send it anything special to wake up.
> So even DMA commands have to have a long enough timeout to allow
> for spinning up.

    Yes, but why *twice* as long as the others?

> Cheers

MBR, Sergei

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Mark Lord]

Sergei Shtylyov wrote:
> Mark Lord wrote:
> 
>>>    The original question concerned specifically the DMA command 
>>> timeout which is twice more than the usual one, WAIT_CMD (10 seconds).
..
>> When a drive is in standby, we don't send it anything special to wake up.
>> So even DMA commands have to have a long enough timeout to allow
>> for spinning up.
> 
>    Yes, but why *twice* as long as the others?

I would guess simply because DMA has to transfer up to 256 sectors of data,
possibly with sector reallocations, in addition to waiting for the drive
to spin up.  Other commands don't.

At the time that was coded (?), I suspect that PIO READ/WRITE commands
were fed data as it became available to/from the drive.  This may or may
not still be the case, but it does imply that they don't need to hang
around as long on the timeouts as do DMA commands (which have to wait
for *everything* to be transferred).

I'm guessing that this was the original concern of mine,
way back in 1994 or whenever it was.

Cheers

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Sergei Shtylyov]

Mark Lord wrote:

>>>>    The original question concerned specifically the DMA command 
>>>> timeout which is twice more than the usual one, WAIT_CMD (10 seconds)...

>>> When a drive is in standby, we don't send it anything special to wake 
>>> up.
>>> So even DMA commands have to have a long enough timeout to allow
>>> for spinning up.

>>    Yes, but why *twice* as long as the others?

> I would guess simply because DMA has to transfer up to 256 sectors of data,
> possibly with sector reallocations, in addition to waiting for the drive
> to spin up.  Other commands don't.

    What?! PIO commands don't have to do this as well? :-)

> At the time that was coded (?), I suspect that PIO READ/WRITE commands
> were fed data as it became available to/from the drive.  This may or may

    I don't see *any* difference with the DMA commands here -- the drive has 
always been free to assert and deassert DMARQ at its well.

> not still be the case, but it does imply that they don't need to hang
> around as long on the timeouts as do DMA commands (which have to wait
> for *everything* to be transferred).

    Ah, that makes sense -- during PIO interrupts happen a lot more often.
20 secs still seem to be too much.

> Cheers

MBR, Sergei

PS: Your mail server still keeps bouncing me off. :-(

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Sergei Shtylyov]

Mark Lord wrote:

>>>> O> >>    BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 
>>>> secs, and if DMA is not complete or interrupt pending, it may wait 
>>>> 10 more secs...

> ..

>>> I've lost the original question from this thread, but the idea of the 

>>    The original question concerned specifically the DMA command 
>> timeout which is twice more than the usual one, WAIT_CMD (10 seconds).

>>> longish
>>> timeouts was that drive *may* be spun down ("standby"), and thus have 
>>> to spin
>>> up again to complete media commands.  Back then, drives were much 
>>> slower at
>>> spinning up than nowadays, and the ATA spec says to allow up to 30 
>>> seconds.

>>    Well, that doesn't explain the DMA case.

> When a drive is in standby, we don't send it anything special to wake up.

    Wait, aren't we sending IDLE on resume step 2 -- looking at 
ide-io.cide_start_power_step()?

> Cheers

MBR, Sergei

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Mark Lord]

Sergei Shtylyov wrote:
> Mark Lord wrote:
..
>> When a drive is in standby, we don't send it anything special to wake up.
> 
>    Wait, aren't we sending IDLE on resume step 2 -- looking at 
> ide-io.cide_start_power_step()?

Sure, for RESUME.

But now for a drive that just happens to have put itself into standby
due to expiration of the standby timer (hdparm -S).

Cheers

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Mark Lord]

Sergei Shtylyov wrote:
> Mark Lord wrote:
> ..
>> I would guess simply because DMA has to transfer up to 256 sectors of 
>> data,
>> possibly with sector reallocations, in addition to waiting for the drive
>> to spin up.  Other commands don't.
> 
>    What?! PIO commands don't have to do this as well? :-)

"Other commands" don't have to transfer up to 256 sectors before interrupting.

>> At the time that was coded (?), I suspect that PIO READ/WRITE commands
>> were fed data as it became available to/from the drive.  This may or may
> 
>    I don't see *any* difference with the DMA commands here -- the drive 
> has always been free to assert and deassert DMARQ at its well.

Yeah, but that's not what our software timeout is for.
The timeout is for the next interrupt, which will only 
be given (for DMA) once the drive completes *all* transfers.

>> not still be the case, but it does imply that they don't need to hang
>> around as long on the timeouts as do DMA commands (which have to wait
>> for *everything* to be transferred).
> 
>    Ah, that makes sense -- during PIO interrupts happen a lot more often.
> 20 secs still seem to be too much.

I don't think so, even for modern drives.
Figure 8-10 seconds max for spin-up,
plus 6-9 seconds to do a sector re-assignment
or retries on a bad block (a measured *real-life* value).

That adds up to 14-19 seconds, so 20 seconds is probably good.

Still, this does need to be adjustable for faster (CF) devices,
and slower (optical/tape) devices, rather than just a single
set of fixed timeout values.

Cheers

> PS: Your mail server still keeps bouncing me off. :-(

PS: your mail server still looks like a spammer, because it is
(1) missing a reverse DNS entry for 63.81.120.155,
and (2) is not RFC compliant on the SMTP "HELO" message
(bad hostname given there).

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Mark Lord]

Mark Lord wrote:
> Sergei Shtylyov wrote:
>> Mark Lord wrote:
> ..
>>> When a drive is in standby, we don't send it anything special to wake 
>>> up.
>>
>>    Wait, aren't we sending IDLE on resume step 2 -- looking at 
>> ide-io.cide_start_power_step()?
> 
> Sure, for RESUME.
> 
> But now for a drive that just happens to have put itself into standby
> due to expiration of the standby timer (hdparm -S).

That should have said:

But *not* for a drive ...

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Rogier Wolff]

On Fri, Jul 13, 2007 at 05:00:18PM -0400, Mark Lord wrote:
> >   Ah, that makes sense -- during PIO interrupts happen a lot more often.
> >20 secs still seem to be too much.
> 
> I don't think so, even for modern drives.
> Figure 8-10 seconds max for spin-up,
> plus 6-9 seconds to do a sector re-assignment
> or retries on a bad block (a measured *real-life* value).
> 
> That adds up to 14-19 seconds, so 20 seconds is probably good.
> 
> Still, this does need to be adjustable for faster (CF) devices,
> and slower (optical/tape) devices, rather than just a single
> set of fixed timeout values.

In real life, with real bad blocks on real harddrives, some harddrives
take more than the DMA TIMEOUT time to read a single block, even without
having to spin up. 

The current code then resets the drive, on which the drive reports
"busy, not ready for command", and things go downhill from there. 

	Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ

Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

[Sergei Shtylyov]

Hello.

Rogier Wolff wrote:

>>>  Ah, that makes sense -- during PIO interrupts happen a lot more often.
>>>20 secs still seem to be too much.

>>I don't think so, even for modern drives.
>>Figure 8-10 seconds max for spin-up,
>>plus 6-9 seconds to do a sector re-assignment
>>or retries on a bad block (a measured *real-life* value).

>>That adds up to 14-19 seconds, so 20 seconds is probably good.

>>Still, this does need to be adjustable for faster (CF) devices,
>>and slower (optical/tape) devices, rather than just a single
>>set of fixed timeout values.

> In real life, with real bad blocks on real harddrives, some harddrives
> take more than the DMA TIMEOUT time to read a single block, even without
> having to spin up. 

   Yeah, "shit happens".

> The current code then resets the drive, on which the drive reports
> "busy, not ready for command", and things go downhill from there. 

    You are clearly mixing things: this message is a result of retrying 
command in PIO mode (that fails because the drive is still busy), and then the 
drives are actually reset. If they keep being busy *after* that, all I'd say 
is dump them ASAP. ;-)

> 	Roger. 

MBR, Sergei