Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261515AbTIOQHd (ORCPT ); Mon, 15 Sep 2003 12:07:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261500AbTIOQHT (ORCPT ); Mon, 15 Sep 2003 12:07:19 -0400 Received: from ns.virtualhost.dk ([195.184.98.160]:52142 "EHLO virtualhost.dk") by vger.kernel.org with ESMTP id S261496AbTIOQHM (ORCPT ); Mon, 15 Sep 2003 12:07:12 -0400 Date: Mon, 15 Sep 2003 18:07:03 +0200 From: Jens Axboe To: Justin Cormack Cc: casino_e@terra.es, Kernel mailing list Subject: Re: SII SATA request size limit Message-ID: <20030915160703.GF3486@suse.de> References: <20030915153255.GB3412@suse.de> <1063641654.1350.210.camel@lotte.street-vision.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1063641654.1350.210.camel@lotte.street-vision.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2547 Lines: 54 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/