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
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
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
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
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
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? :-)
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
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
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
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
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
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
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
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. :-)
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. :-)
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
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. :-)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 <[EMAIL PROTECTED]>
>
> ---
> drivers/ide/ide-dma.c |
It can be changed via /proc/ide/hd?/settings.
Signed-off-by: Ed Falk <[EMAIL PROTECTED]>
---
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
It can be changed via /proc/ide/hd?/settings.
Signed-off-by: Ed Falk [EMAIL PROTECTED]
---
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
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 [EMAIL PROTECTED]
---
drivers/ide/ide-dma.c |3 ++-
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
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
40 matches
Mail list logo
