From owner-svn-src-all@FreeBSD.ORG Mon Jun 25 14:27:53 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 CB29B106566C; Mon, 25 Jun 2012 14:27:53 +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 9E33C8FC15; Mon, 25 Jun 2012 14:27:53 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 07153B915; Mon, 25 Jun 2012 10:27:53 -0400 (EDT) From: John Baldwin To: Marius Strobl Date: Mon, 25 Jun 2012 10:00:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201206131504.q5DF4opt031336@svn.freebsd.org> <20120623221626.GH69382@alchemy.franken.de> In-Reply-To: <20120623221626.GH69382@alchemy.franken.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206251000.09052.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 25 Jun 2012 10:27:53 -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-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: Mon, 25 Jun 2012 14:27:53 -0000 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 > 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. -- John Baldwin