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]
Message-ID: <20081111213009.GA7072@us.ibm.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ