Date: Mon, 7 May 2012 21:29:50 -0400 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@freebsd.org> Cc: "svn-src-stable@freebsd.org" <svn-src-stable@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-stable-9@freebsd.org" <svn-src-stable-9@freebsd.org>, Hans Petter Selasky <hselasky@c2i.net> Subject: Re: svn commit: r235007 - stable/9/sys/dev/pci Message-ID: <F6ECCA3E-5CDD-4B6A-9FAC-D31F242B4239@bsdimp.com> In-Reply-To: <201205070927.41775.jhb@freebsd.org> References: <201205041538.q44FclqK010547@svn.freebsd.org> <201205042141.55089.hselasky@c2i.net> <80963C87-6F37-4AC7-B5E8-132EC5F47D98@bsdimp.com> <201205070927.41775.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F6ECCA3E-5CDD-4B6A-9FAC-D31F242B4239>