Date: Mon, 25 Jun 2012 19:08:11 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: John Baldwin <jhb@freebsd.org> 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: <20120625170811.GI69382@alchemy.franken.de> In-Reply-To: <201206251000.09052.jhb@freebsd.org> References: <201206131504.q5DF4opt031336@svn.freebsd.org> <20120623221626.GH69382@alchemy.franken.de> <201206251000.09052.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <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 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. > > > 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. 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? Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120625170811.GI69382>