From owner-freebsd-embedded@FreeBSD.ORG Thu Apr 24 20:26:46 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90BE11065670; Thu, 24 Apr 2008 20:26:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 866FA8FC22; Thu, 24 Apr 2008 20:26:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unknown [208.65.91.234]) by elvis.mu.org (Postfix) with ESMTP id 0CEF01A4D83; Thu, 24 Apr 2008 13:26:45 -0700 (PDT) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m3OKQS9q044310; Thu, 24 Apr 2008 16:26:34 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Hans Petter Selasky Date: Thu, 24 Apr 2008 16:01:51 -0400 User-Agent: KMail/1.9.7 References: <20080421171305.GA19840@eecs.harvard.edu> <200804240806.54354.jhb@freebsd.org> <200804241738.09805.hselasky@c2i.net> In-Reply-To: <200804241738.09805.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804241601.51441.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 24 Apr 2008 16:26:34 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/6926/Thu Apr 24 14:23:40 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-embedded@freebsd.org, freebsd-usb@freebsd.org, Geoffrey Mainland Subject: Re: Soekris 4826 USB failure on FreeBSD 7.0 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2008 20:26:46 -0000 On Thursday 24 April 2008 11:38:09 am Hans Petter Selasky wrote: > On Thursday 24 April 2008, John Baldwin wrote: > > > > This would indicate a bug in the bus_dmamap_load() call (wrong length?) and > > that is going to hose you when you do the bus_dmamap_sync() for systems > > with bounce pages (not enough data will get copied back and forth?). You > > need to track down the real bug and fix it rather than adding a hack in > > your callback routine. > > Hi John, > > The minimum segment size is PAGE_SIZE bytes in my DMA-tag. Bus-dma starts > counting at the memory location of the allocation. And not the memory > location aligned to PAGE_SIZE bytes. > > Memory pages: |--------------|--------------| > My allocation: |---------XXXXXXXXXXXXX-------| > > Sometimes when I allocate DMA memory I can end up having an allocation > crossing two contiguous memory pages in physical memory. In those cases > bus_dma does not give me the segment address of the second page in the > segment list, because the allocation is less than PAGE_SIZE bytes. It fits > within the values specified in the DMA tag. But in other cases, where the > pages are not contiguous in RAM, bus_dma will return two different segment > addresses. > > The question is: Is this a bug or is it a feature? If you can't have a S/G element cross a page boundary, then use a 'boundary' of PAGE_SIZE when you create your tag. As it is, you are (correctly for the tag you are creating) getting a single S/G entry that spans the entire region. It sounds like you want two regions that is split on the page boundary. If so, that is what the 'boundary' argument to bus_dmatag_create() is for. -- John Baldwin