From owner-cvs-all@FreeBSD.ORG Wed Apr 26 00:48:34 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A79D316A401; Wed, 26 Apr 2006 00:48:34 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F76643D45; Wed, 26 Apr 2006 00:48:34 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (Postfix) with ESMTP id 080D7347C58; Wed, 26 Apr 2006 10:48:33 +1000 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k3Q0mP6h027002; Wed, 26 Apr 2006 10:48:30 +1000 Date: Wed, 26 Apr 2006 10:48:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Scott Long In-Reply-To: <444EB6A1.3060901@samsco.org> Message-ID: <20060426103623.M1847@epsplex.bde.org> References: <444E7750.206@samsco.org> <200604251540.00170.jhb@freebsd.org> <444E7BFE.4040800@samsco.org> <20060425.173236.74726638.imp@bsdimp.com> <444EB6A1.3060901@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 00:48:34 -0000 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