From owner-freebsd-current@FreeBSD.ORG Wed Jan 11 16:02:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4556106564A for ; Wed, 11 Jan 2012 16:02:25 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 6913D8FC15 for ; Wed, 11 Jan 2012 16:02:24 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id q0BG2IbX011854; Wed, 11 Jan 2012 09:02:18 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <4F0C9D14.60705@FreeBSD.org> Date: Wed, 11 Jan 2012 09:02:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <43B9536E-7AF4-47A8-A556-79BC30125304@samsco.org> References: <4F0C9D14.60705@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1251.1) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: FreeBSD current Subject: Re: bus dma: a flag/quirk for page zero X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 16:02:25 -0000 An old controller in the aac driver family had a variation of this = problem back when the FreeBSD contigmalloc algorithm started from the = bottom of memory instead of the top. I worked around it at driver init = time by basically assuring that page 0 (and page 1) were allocated and = thrown away; it seemed easier to leak 8k of memory than to jump through = expensive hoops in busdma. The busdma filter is expensive, and is used so rarely that I'm not even = sure it works. It was created for an old SCSI controller that had a = buggy DMA controller which aliased a repeating pattern of address = ranges; in other words it was a hack. It's expensive to use, since it = forces every bus_dmamap_load() request through the slow path and = possibly bouncing. With that said, your idea of a flag is probably a reasonable change for = now. Alternatively, the ability to specify multiple DMA exclusion = ranges has come up in the past, and would be a more complete answer to = your problem; just treating page0 as special might not be enough (and I = know for a fact that this is true with old i960RX pci processors). = That'll involve an API change, so is something that I'd rather not = happen on a whim. Scott On Jan 10, 2012, at 1:18 PM, Andriy Gapon wrote: >=20 >=20 > Some hardware interfaces may reserve a special meaning for a = (physical) memory > address value of zero. One example is the OHCI specification where a = zero value > in CurrentBufferPointer doesn't mean a physical address, but has a = reserved > meaning. To be honest I don't have another example :) but don't = preclude its > existence. >=20 > To deal with this peculiarity we could use a special flag/quirk that = would > instruct the bus dma code to never use the page zero for communication = with the > hardware. > Here's a proof of concept patch that implements the idea: > http://people.freebsd.org/~avg/usb-dma-pagezero.diff >=20 > Some concerns: > - not sure if BUS_DMA_NO_PAGEZERO is the best name for the flag > - the patch implements the flag only for x86 at the moment > - usb code uses the flag regardless of the actual controller type >=20 > What do you think? >=20 > --=20 > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"