Date: Mon, 25 Jun 2012 10:00:08 -0400 From: John Baldwin <jhb@freebsd.org> To: Marius Strobl <marius@alchemy.franken.de> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r237008 - head/sys/dev/pci Message-ID: <201206251000.09052.jhb@freebsd.org> In-Reply-To: <20120623221626.GH69382@alchemy.franken.de> References: <201206131504.q5DF4opt031336@svn.freebsd.org> <20120623221626.GH69382@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <OFW PCIe-PCIe bridge> 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: <OFW PCI bus> on pcib3 > <...> > isab0: <PCI-ISA bridge> at device 30.0 on pci3 > isa0: <ISA bus> on isab0 > <...> > rtc0: <Real-Time Clock> 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: <Real-Time Clock> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201206251000.09052.jhb>