From owner-cvs-src@FreeBSD.ORG Wed Apr 26 16:48:12 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 396CF16A400; Wed, 26 Apr 2006 16:48:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C84C43D46; Wed, 26 Apr 2006 16:48:11 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k3QGkvYZ039163; Wed, 26 Apr 2006 10:46:57 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 26 Apr 2006 10:47:08 -0600 (MDT) Message-Id: <20060426.104708.85411757.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <20060426.102502.11595340.imp@bsdimp.com> References: <444F0923.8050508@samsco.org> <20060426.101245.90994186.imp@bsdimp.com> <20060426.102502.11595340.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, bde@zeta.org.au, jhb@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, mj@feral.com 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 16:48:12 -0000 In message: <20060426.102502.11595340.imp@bsdimp.com> "M. Warner Losh" writes: : While an individual DMA transfer on the : PCI-E bus may not cross such a boundary, I bleieve that individual : resources can consume more than 4G. Our PCI code doesn't handle BARs : that are > 4G in size correctly, but it does handle BARs that are : mapped anywhere in a 64-bit address space. I went ahead and looked it up in the standard. Our current PCI code does sizing of 64-bit BARs with only 32-bits. But the 2.2 standard specifically says, in an implementation note, that it should be done with 64-bits. On page 204 in section 6.2.5.1: "64-bit (memory) Base Address registers can be handled the same, except that the second 32-bit register is considered an extension of the first; ie bits 32-63. Software writes 0xffffffff to both registers, reads them back, and combines the result into a 64-bit value. Size calculation is done on the 64-bit value." Anyway, consider this just a footnote to the conversation. I'm happy leaving well enough alone for the i386 implementation given the sentiment expressed in this thread. Warner