public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Justin Cormack <justin@street-vision.com>
Cc: casino_e@terra.es, Kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: SII SATA request size limit
Date: Mon, 15 Sep 2003 18:07:03 +0200	[thread overview]
Message-ID: <20030915160703.GF3486@suse.de> (raw)
In-Reply-To: <1063641654.1350.210.camel@lotte.street-vision.com>

On Mon, Sep 15 2003, Justin Cormack wrote:
> On Mon, 2003-09-15 at 16:32, Jens Axboe wrote:
> > On Mon, Sep 15 2003, CASINO_E wrote:
> > > 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()?
> > 
> > No that's not stupid at all. In 2.4 that would be how you do it, in 2.6
> > I was referring to the possibility of letting the drive queues that hang
> > off that controller be naturally limited. So you would do something ala
> > 
> > 	if (hwif->dma_boundary)
> > 		blk_queue_segment_boundary(drive->queue, 0x1fff);
> > 
> > and then no segment would be >= 8192 (or cross it, naturally) by
> > default.
> > 
> > > 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.
> > 
> > Of course. But that is implementation detail, I was just worried that
> > someone would clamp on a nasty work around like 15 sectors (which would
> > in reality be just a 4kb request, nasty!) when you could get nice 128kb
> > requests with just the right segment limiting instead.
> > 
> > But basically I don't understand why the work-around was _ever_ in
> > sectors, if that is the bug in the hardware dma engine. Two
> > explanations: it's not really that bug and NetBSD is wrong, or the
> > person who did the work-around didn't know a better solution existed
> > (don't laugh, I wouldn't be surprised if something like that came down
> > from a vendor :)
> 
> Unfortunately the bug isnt exactly this (apparently) and is only
> revealed under NDA (see Alan Cox's mail).

Just read Alans mails, doesn't really explain anything. But the segment
patch must be close, if limiting max transfer size to 7.5K works. Which
(in spirit, at least) is identical to the NetBSD work-around.

And why you would want to keep a work around like this under NDA (for a
bug that completely cripples the hardware) I don't understand at all,
seems pretty damn stupid to me. "Thanks for buying our hardware, yes
it's buggy and we wont tell you what the bug is. Please come again!"

-- 
Jens Axboe


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

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-15 15:24 SII SATA request size limit CASINO_E
2003-09-15 15:32 ` Jens Axboe
2003-09-15 16:00   ` Justin Cormack
2003-09-15 16:07     ` Jens Axboe [this message]
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=20030915160703.GF3486@suse.de \
    --to=axboe@suse.de \
    --cc=casino_e@terra.es \
    --cc=justin@street-vision.com \
    --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