public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Mark Hahn <hahn@coffee.psychology.mcmaster.ca>
Cc: andre@linux-ide.org, alan@lxorguk.ukuu.org.uk,
	linux-kernel@vger.kernel.org
Subject: Re: [patch]: ide dma timeout retry in pio
Date: Mon, 28 May 2001 22:37:33 +0200	[thread overview]
Message-ID: <20010528223733.O9102@suse.de> (raw)
In-Reply-To: <20010528203421.N9102@suse.de> <Pine.LNX.4.10.10105281533400.25183-100000@coffee.psychology.mcmaster.ca>
In-Reply-To: <Pine.LNX.4.10.10105281533400.25183-100000@coffee.psychology.mcmaster.ca>; from hahn@coffee.psychology.mcmaster.ca on Mon, May 28, 2001 at 03:39:00PM -0400

On Mon, May 28 2001, Mark Hahn wrote:
> > request, when we hit a dma timout. In this case, what we really want to
> > do is retry the request in pio mode and revert to normal dma operations
> > later again.
> 
> really?  do we know the nature of the DMA engine problem well enough?
> is there a reason to believe that it'll work better "later"?
> I guess I was surprised at resorting to PIO - couldn't we just
> break the request up into smaller chunks, still using DMA?

That is indeed possible, it will require some surgery to the dma request
path though. IDE has no concept of doing part of a request for dma
currently, it's an all-or-nothing approach. That's why it falls back to
pio right now.

> I seem to recall Andre saying that the problem arises when the 
> ide DMA engine looses PCI arbitration during a burst.  shorter 
> bursts would seem like the best workaround if this is the problem...

It's worth a shot. My patch was not meant as the end-all solution,
however we need something _now_. Loosing sectors is not funny.
Dynamically limiting general request size for to make dma work is a
piece of cake, that'll be about a one-liner addition to the current
patch. So the logic could be something of the order of:

	- 1st dma timeout
	- scale max size down from 128kB (127.5kB really) to half that
	...
	- things aren't working, 2nd dma timeout. Scale down to 32kB.

and so forth, revert to pio and reset full size if it's really no good.
If limiting transfer sizes solves the problem, this would be the way to
go. I'll do another version that does this.

Testers? Who has frequent ide dma timeout problems??

> resorting to PIO would be such a shame, not only because it eats
> CPU so badly, but also because it has no checksum like UDMA...

Look at the patch -- we resort to pio for _one_ hunk. That's 8 sectors
tops, then back to dma. Hardly a big issue.

-- 
Jens Axboe


  parent reply	other threads:[~2001-05-28 20:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-28 18:34 [patch]: ide dma timeout retry in pio Jens Axboe
2001-05-28 19:39 ` Mark Hahn
2001-05-28 20:13   ` Christopher B. Liebman
2001-05-28 20:37   ` Jens Axboe [this message]
2001-05-28 22:15     ` Andre Hedrick
2001-05-28 22:26       ` Jens Axboe
2001-05-29  0:09         ` Andre Hedrick
2001-05-29  0:30           ` Jens Axboe
2001-05-28 21:12   ` Alan Cox
2001-05-28 22:11     ` James Turinsky
2001-05-29  6:18     ` Larry McVoy
2001-05-28 22:20       ` Alan Cox
2001-05-28 22:56       ` Meelis Roos
2001-05-29  7:11         ` Larry McVoy
  -- strict thread matches above, loose matches on Subject: below --
2001-05-30 21:09 Diefenbaugh, Paul S

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010528223733.O9102@suse.de \
    --to=axboe@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andre@linux-ide.org \
    --cc=hahn@coffee.psychology.mcmaster.ca \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox