From owner-svn-src-head@FreeBSD.ORG Mon Jun 25 18:46:58 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E451106567D; Mon, 25 Jun 2012 18:46:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D45668FC0C; Mon, 25 Jun 2012 18:46:57 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 33A28B98A; Mon, 25 Jun 2012 14:46:57 -0400 (EDT) From: John Baldwin To: Marius Strobl Date: Mon, 25 Jun 2012 14:24:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201206131504.q5DF4opt031336@svn.freebsd.org> <201206251000.09052.jhb@freebsd.org> <20120625170811.GI69382@alchemy.franken.de> In-Reply-To: <20120625170811.GI69382@alchemy.franken.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206251424.24621.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 25 Jun 2012 14:46:57 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r237008 - head/sys/dev/pci X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 18:46:58 -0000 On Monday, June 25, 2012 1:08:11 pm Marius Strobl wrote: > On Mon, Jun 25, 2012 at 10:00:08AM -0400, John Baldwin wrote: > > On Saturday, June 23, 2012 6:16:26 pm Marius Strobl wrote: > > > On Wed, Jun 13, 2012 at 03:04:50PM +0000, John Baldwin wrote: > > > > Author: jhb > > > > Date: Wed Jun 13 15:04:50 2012 > > > > New Revision: 237008 > > > > URL: http://svn.freebsd.org/changeset/base/237008 > > > > > > > > Log: > > > > Fix a couple of bugs that prevented windows in PCI-PCI bridges from > > > > growing "downward" (moving the start address down). First, an off by > > > > one error caused the end address to be moved down an extra alignment > > > > chunk unnecessarily. Second, when aligning the new candidate starting > > > > address, the wrong bits were masked off. > > > > > > > > > > Unfortunately, this now panics a sparc64 machine on the first attempt > > > to use a grown resource via bus_space(9) for me: > > > pcib3: at device 0.0 on pci2 > > > pcib2: allocated I/O port range (0x1000-0x1fff) for rid 1c of pcib3 > > > pcib2: allocated memory range (0x200000-0x3ffffff) for rid 20 of pcib3 > > > pcib3: domain 0 > > > pcib3: secondary bus 5 > > > pcib3: subordinate bus 5 > > > pcib3: I/O decode 0x1000-0x1fff > > > pcib3: memory decode 0x200000-0x3ffffff > > > pcib3: no prefetched decode > > > pcib3: Subtractively decoded bridge. > > > <...> > > > pci3: on pcib3 > > > <...> > > > isab0: at device 30.0 on pci3 > > > isa0: on isab0 > > > <...> > > > rtc0: at port 0x70-0x73 on isa0 > > > pcib3: attempting to grow I/O port window for (0x70-0x73,0x4) > > > front candidate range: 0x70-0x73 > > > pcib3: grew I/O port window to 0x70-0x1fff > > > panic: start address is not aligned > > > Alternatively, this may also be a data access trap, which also indicates > > > that some invalid address being used for the access. > > > > I think this was fixed in the next commit to this file (I had gotten the > > mask bits on 'front' wrong). Yes, it should be fixed by r237271: > > > > Old version: > > > > (gdb) p/x (0x70 & (~(1ul << 12) - 1)) > > $1 = 0x70 > > > > Fixed version: > > > > (gdb) p/x (0x70 & (~((1ul << 12) - 1))) > > $2 = 0x0 > > Well, a stock r237433 still panics with a data access trap when > trying to use the resource via bus_space(9). So while the math for > growing the window is probably right now, there still is a problem. Hmm. It would be interesting to know if it used to grow before (it might not have due to the bugs I fixed in the growing code). > > > > > before: > > > rtc0: at port 0x70-0x73 on isa0 > > > pcib3: attempting to grow I/O port window for (0x70-0x73,0x4) > > > pcib2: allocated I/O port range (0x70-0x73) for rid 0 of rtc0 > > > > > > Shouldn't a subtractively decoded resource actually be outside of > > > the window of the parent PCI-PCI bridge, i.e. it seems we shouldn't > > > try to grow the window in that case? The below patch fixes this for > > > me, I'm not sure whether that actually is the right approach though. > > > > Well, I've seen subtractive bridges with programmed windows, and the resource > > will decode properly either way. What the current code does is allow the > > request to pass up the tree if growing fails. > > By growing the window to 0x0-0x1fff in this case we are effectively > turning the formerly subtractively decoded resource in a positively > decodeded one. Maybe there's some additional bit, probably in the > PCI-ISA bridge, that needs to be switch for that, too? In any case, > growing the window in this case and by that changing the type of > decoding seems like a strange approach to me. Why do subtractive > decoders exist in the first place when the windows alternatively > could be grown/set up to only just do positive decoding instead? The PCI-ISA bridge should already be decoding that range. Note that subtractive decoding is slower (it has to wait for an extra cycle to give other devices a chance to snag a request). I would not mind a tunable to control growing or not growing a window on a subtractively decoded bridge. Does the firmware assign a window to this bridge btw? We probably should not allocate a new window for a subtractively decoded bridge, but if the firmware has already assigned a window, growing an existing window seems less problematic. -- John Baldwin