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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 Nov 2008 13:30:10 -0800
From:	Gary Hade <garyhade@...ibm.com>
To:	"GARCIA DE SORIA LUCENA, JUAN JESUS" <juanj.g_soria@...pobbva.com>
Cc:	Jiri Slaby <jirislaby@...il.com>, Gary Hade <garyhade@...ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Regression: Boot hang sizing transparent PCI-to-PCI
	bridgesinceafter 2.6.25-r7.

On Tue, Nov 11, 2008 at 12:43:28PM +0100, GARCIA DE SORIA LUCENA, JUAN JESUS wrote:
> > -----Original Message-----
> > From: Jiri Slaby [mailto:jirislaby@...il.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@...ibm.com
http://www.ibm.com/linux/ltc

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/