All of lore.kernel.org
 help / color / mirror / Atom feed
From: CASINO_E <CASINO_E@teleline.es>
To: Jens Axboe <axboe@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: SII SATA request size limit
Date: Mon, 15 Sep 2003 17:24:05 +0200	[thread overview]
Message-ID: <d95d2d93f8.d93f8d95d2@teleline.es> (raw)

Forgive me if I'm saying something stupid but, do you mean a special 
case for this controller in ide-dma.c:ide_build_dmatable()?

In this case, should not segment size and boundary be included in hwif 
so we can have a generic ide_build_dmatable() without dealing 
explicitly with special cases? We could initialize to the default for 
most controllers and set the values for the exceptions inside each 
particular driver.

----- Mensaje Original -----
De: Jens Axboe <axboe@suse.de>
Fecha: Lunes, Septiembre 15, 2003 10:47 am
Asunto: Re: SII SATA request size limit

> On Fri, Sep 12 2003, Eduardo Casino wrote:
> > Hi All,
> > 
> > I had a look at the NetBSD pciide.c driver and found this 
> interesting> bit of code:
> > 	
> > 	/*
> > 	 * Rev. <= 0x01 of the 3112 have a bug that can cause data
> > 	 * corruption if DMA transfers cross an 8K boundary.  This is
> > 	 * apparently hard to tickle, but we'll go ahead and play it
> > 	 * safe.
> > 	 */
> > 	if (PCI_REVISION(pa->pa_class) <= 0x01) {
> > 	        sc->sc_dma_maxsegsz = 8192;
> > 	        sc->sc_dma_boundary = 8192;
> > 	}
> > 
> > This is basically the same as setting hwif->rqsize to 15, but 
> the NetBSD
> 
> You can do much much better than that, it's pretty simply to just
> restrict the segment size and boundary if you have a controller with
> such a bug. And then you get the benefit of the larger requests too,
> it's basically not a performance hit at that point.
> 
> -- 
> Jens Axboe
> 
> 



             reply	other threads:[~2003-09-15 15:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-15 15:24 CASINO_E [this message]
2003-09-15 15:32 ` SII SATA request size limit Jens Axboe
2003-09-15 16:00   ` Justin Cormack
2003-09-15 16:07     ` Jens Axboe
2003-09-15 22:19   ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2003-09-18 17:43 Allen Martin
2003-09-15 16:33 CASINO_E
2003-09-14  0:57 Eduardo Casino
2003-09-13 16:43 Marcelo Penna Guerra
2003-09-12 23:07 Marcelo Penna Guerra
2003-09-12 23:16 ` Alan Cox
2003-09-12 21:00 Marcelo Penna Guerra
2003-09-12 22:28 ` Alan Cox
2003-09-12 20:55 Marcelo Penna Guerra
2003-09-13 10:56 ` Witold Krecicki
2003-09-12 20:48 Eduardo Casino
2003-09-15  8:47 ` Jens Axboe
2003-09-12  2:57 Marcelo Penna Guerra
2003-09-12 10:41 ` Alan Cox
2003-09-12 17:46   ` Witold Krecicki
2003-09-15 10:12     ` Adam Jones
2003-09-18 11:44       ` Witold Krecicki
2003-09-15  5:57 ` Catalin BOIE

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=d95d2d93f8.d93f8d95d2@teleline.es \
    --to=casino_e@teleline.es \
    --cc=axboe@suse.de \
    --cc=casino_e@terra.es \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.