Re: Regression: Boot hang sizing transparent PCI-to-PCI bridgesinceafter 2.6.25-r7.

[Gary Hade <garyhade@us.ibm.com>]

On Tue, Nov 11, 2008 at 12:43:28PM +0100, GARCIA DE SORIA LUCENA, JUAN JESUS wrote:
> > -----Original Message-----
> > From: Jiri Slaby [mailto:jirislaby@gmail.com] 
> >
> > GARCIA DE SORIA LUCENA, JUAN JESUS napsal(a):
> > > resource_size_t type
> > > (defined in linux/types.h) being u64. Perhaps it's u32 in a 32 bit 
> > > architecture.
> > 
> > Unless you have RESOURCES_64BIT=y which is the default on x86_32 now.
> 
> Ugh. Knowing this will save me from downloading, burning and testing the
> 32 bit Ubuntu distro, whose 2.6.27 kernel will surely use that default
> configuration.
> 
> I'll perform more tests, with more debug kprintf()'s, anyway.
> 
> Do you remember if the cases Gary's patches were trying to fix included
> ranges rolling past the 32-bit address limit (end address below start
> address)?

No, my patches were not trying to fix anything like that.

I looked at the `lspci -vvv` output for some transparent bridges on
one of our systems and found that the messed up looking ranges are
not unique to your system.  We also see that on our systems.  I checked
the lspci code and found that the displayed ranges are based on base
and limit register values obtained directly from PCI config space 
for the device.  I also noticed that -vvv it will display values even
if they do not represent valid ranges such as you might expect for the
contents of base and limit registers on transparent bridges.  This
caused me to peek at the lspci man page which says:
"-vvv   Be even more verbose and display everything we are able
       to parse, even if it doesn’t look interesting at all
       (e.g., undefined memory regions)."
You must be getting some of that "even if it doesn't look interesting
at all" stuff. :)

Gary

-- 
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503  IBM T/L: 775-4503
garyhade@us.ibm.com
http://www.ibm.com/linux/ltc