From owner-svn-src-all@FreeBSD.ORG Tue May 8 01:30:43 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B24E8106566B; Tue, 8 May 2012 01:30:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5E14A8FC0A; Tue, 8 May 2012 01:30:43 +0000 (UTC) Received: from [10.0.133.83] (67-210-169.34.static.tel-ott.com [67.210.169.34] (may be forged)) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q481TqHH069883 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 7 May 2012 19:30:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201205070927.41775.jhb@freebsd.org> Date: Mon, 7 May 2012 21:29:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201205041538.q44FclqK010547@svn.freebsd.org> <201205042141.55089.hselasky@c2i.net> <80963C87-6F37-4AC7-B5E8-132EC5F47D98@bsdimp.com> <201205070927.41775.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 07 May 2012 19:30:27 -0600 (MDT) Cc: "svn-src-stable@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , "svn-src-stable-9@freebsd.org" , Hans Petter Selasky Subject: Re: svn commit: r235007 - stable/9/sys/dev/pci X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 01:30:43 -0000 On May 7, 2012, at 9:27 AM, John Baldwin wrote: > On Friday, May 04, 2012 5:25:32 pm Warner Losh wrote: >>=20 >> On May 4, 2012, at 1:41 PM, Hans Petter Selasky wrote: >>=20 >>> On Friday 04 May 2012 19:18:56 Warner Losh wrote: >>>> On May 4, 2012, at 10:26 AM, Hans Petter Selasky wrote: >>>>> On Friday 04 May 2012 18:14:16 John Baldwin wrote: >>>>>> On Friday, May 04, 2012 11:38:47 am Hans Petter Selasky wrote: >>>>>>> Author: hselasky >>>>>>> Date: Fri May 4 15:38:47 2012 >>>>>>> New Revision: 235007 >>>>>>> URL: http://svn.freebsd.org/changeset/base/235007 >>>>>>>=20 >>>>>>> Log: >>>>>>> MFC r233662, r233677 and r233678: >>>>>>>=20 >>>>>>> Writing zero to BAR actually does not disable it and >>>>>>> it is even harmful as hselasky found out. Historically, >>>>>>> this code was originated from (OLDCARD) CardBus driver and later >>>>>>> leaked into PCI driver when CardBus was newbus'ified and = refactored >>>>>>> with PCI driver. However, it is not really necessary even for >>>>>>> CardBus. >>>>>>=20 >>>>>> FYI, I've got one bug report on HEAD where these changes broke a >>>>>> machine's ATA controller. >>>>>=20 >>>>> Have you considered adding code to disable the I/O or memory range >>>>> instead of writing 0 to the bar in this case? >>>>=20 >>>> I tried that once upon a time, but was problematical with some = bridges=20 > that >>>> had BARs at non-standard locations that needed the I/O or MEM bit = set in >>>> order to work... >>>>=20 >>>> Warner >>>=20 >>> If the size of the bar is a few megabytes, then moving it to = location 0 is=20 >>> definitely wrong. Else it might work! >>=20 >> Only if the bridge passes the transactions for that memory to the PCI = bus=20 > for decoding. The reason it worked for as long as it did was that we = had=20 > bridges that passed the memory cycles to DRAM for addresses near 0 and = they=20 > didn't make it onto the PCI bus. Except in embedded systems, I fail = to see=20 > how that could have changed in the interim. The physical layout of = x86 has=20 > actual memory at location 0 and it would be a big performance hit to = push=20 > those transactions onto the pci bus, so nobody in their right mind = would do=20 > that. >=20 > Not true. During NEW_PCIB testing I at one point fat-fingered = something such > that I had an memory window on a PCI-PCI bridge claim address 0 and = the boot > promptly hung as soon as that register was written. I'll grant that for bridges... The code in question just does devices = though... Still, something we should avoid... Warner