From owner-cvs-src@FreeBSD.ORG Wed Apr 26 00:51:32 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5532816A411; Wed, 26 Apr 2006 00:51:32 +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 9A22A43D68; Wed, 26 Apr 2006 00:51:31 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k3Q0pTlA086365; Tue, 25 Apr 2006 18:51:29 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <444EC410.4020906@samsco.org> Date: Tue, 25 Apr 2006 18:51:28 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Evans References: <444E7750.206@samsco.org> <200604251540.00170.jhb@freebsd.org> <444E7BFE.4040800@samsco.org> <20060425.173236.74726638.imp@bsdimp.com> <444EB6A1.3060901@samsco.org> <20060426103623.M1847@epsplex.bde.org> In-Reply-To: <20060426103623.M1847@epsplex.bde.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: cvs-all@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, jhb@FreeBSD.org, Warner Losh Subject: Re: cvs commit: src/sys/dev/bce if_bcereg.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 00:51:32 -0000 Bruce Evans wrote: > On Tue, 25 Apr 2006, Scott Long wrote: > >> Warner Losh wrote: >> >>> The problem is that PAE's bus_size_t is a 32-bit quantity, when it >>> should be a 64-bit quantity: >>> >>> #ifdef PAE >>> typedef uint64_t bus_addr_t; >>> #else >>> typedef uint32_t bus_addr_t; >>> #endif >>> typedef uint32_t bus_size_t; > > > No, it should be a 32-bit quantity like it is. > >> The next problem is that the boundary argument of bus_dma_tag_create() >> is a bus_size_t. For all PCI Express devices, you need to be able to >> stick a value of 0x100000000 (2^32) in here, have busdma do the right >> thing with it, and not have the compiler complain. I'm torn between >> declaring that the boundary is actually an address and thus should be >> declared as a bus_addr_t, and declaring that bus_size_t should be >> 64-bits on PAE just like it is on real 64-bit platforms. The right > > > I think the boundary is sometimes an address, so it needs to always > have the type of an address. It's never exactly a size. > >> answer is probably to do both. This means a core API change to busdma >> and therefore to 90% of the hardware drivers in the tree, so it's not >> easy to justify MFC'ing it. It can be mostly worked around now anyways. >> >> Does this sound accurate and/or reasonable? > > > Supporting sizes >= 4G sounds unreasonable. How can a single device > need or even address so much space, even on 64-bit arches? For vm, > virtual memory is sort of a device, but even it is limited to 4G on > 32-bit arches, and PAE on i386 isn't pessimized by using a larger than > necessary vm_size_t. > > Bruce Ok, fair enough. Scott