From: Gary Hade <garyhade@us.ibm.com>
To: Jaswinder Singh Rajput <jaswinder@kernel.org>
Cc: Gary Hade <garyhade@us.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Larry Finger <Larry.Finger@lwfinger.net>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
x86 maintainers <x86@kernel.org>, Len Brown <lenb@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Regression with commit f9cde5f in 2.6.30-gitX
Date: Wed, 24 Jun 2009 12:28:13 -0700 [thread overview]
Message-ID: <20090624192813.GF7239@us.ibm.com> (raw)
In-Reply-To: <1245861219.3216.15.camel@localhost.localdomain>
On Wed, Jun 24, 2009 at 10:03:39PM +0530, Jaswinder Singh Rajput wrote:
> On Wed, 2009-06-24 at 09:13 -0700, Gary Hade wrote:
> > On Wed, Jun 24, 2009 at 09:27:48PM +0530, Jaswinder Singh Rajput wrote:
> > > On Wed, 2009-06-24 at 17:19 +0200, Thomas Gleixner wrote:
> > > > Larry,
> > > >
> > > > On Wed, 24 Jun 2009, Larry Finger wrote:
> > > > > For the record, the printout from the patch results in the following:
> > > > >
> > > > > PCI: Failed to allocate 0xd0000-0xd3fff from PCI mem for PCI Bus 0000:00
> > > > > PCI: Failed to allocate 0xec000-0xeffff from PCI mem for PCI Bus
> > > > > 0000:00 due to _CRS returning more than 13 resource descriptors
> > > > > PCI: Failed to allocate 0xf0000-0xfffff from PCI mem for PCI Bus
> > > > > 0000:00 due to _CRS returning more than 13 resource descriptors
> > > > > PCI: Failed to allocate 0xc0000000-0xfebfffff from PCI mem for PCI Bus
> > > > > 0000:00 due to _CRS returning more than 13 resource descriptors
> > > >
> > > > can you please the patch below instead of the other one ?
> > > >
> > > > Thanks,
> > > >
> > > > tglx
> > > > ---
> > > > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> > > > index 16c3fda..39a0cce 100644
> > > > --- a/arch/x86/pci/acpi.c
> > > > +++ b/arch/x86/pci/acpi.c
> > > > @@ -99,7 +99,6 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> > > > "%d resource descriptors\n", (unsigned long) res->start,
> > > > (unsigned long) res->end, root->name, info->name,
> > > > max_root_bus_resources);
> > > > - info->res_num++;
> > > > return AE_OK;
> > > > }
> > > >
> > >
> > > This fails and system does not boot, I already tested this patch 8 hours
> > > ago.
> >
> > I think the resource array needs to be larger. Can you try
> > the below patch?
> >
> > Gary
> >
> > --- linux-2.6.30-rc8/include/linux/pci.h.ORIG 2009-06-24 09:03:41.000000000 -0700
> > +++ linux-2.6.30-rc8/include/linux/pci.h 2009-06-24 09:06:50.000000000 -0700
> > @@ -319,7 +319,7 @@ static inline void pci_add_saved_cap(str
> > }
> >
> > #ifndef PCI_BUS_NUM_RESOURCES
> > -#define PCI_BUS_NUM_RESOURCES 16
> > +#define PCI_BUS_NUM_RESOURCES 20
> > #endif
> >
> > #define PCI_REGION_FLAG_MASK 0x0fU /* These bits of resource flags tell us the PCI region flags */
>
>
> Larry already suggested PCI_BUS_NUM_RESOURCES to 24 in his patch (check
> first reply from him).
Sorry I missed that.
>
> Then what is the point of removing last 3 and then adding 3 or more
> resources, so patch f9cde5f lost its purpose,
The reason for not populating the last 3 slots of the resource
array when there is a transparent bridge on the bus is to make
sure devices downstream of the transparent bridge get the resources
they need. Because of the offset of 3 between the transparent
bridge parent and child bus resource arrays established by
if (dev->transparent) {
dev_info(&dev->dev, "transparent bridge\n");
for(i = 3; i < PCI_BUS_NUM_RESOURCES; i++)
child->resource[i] = child->parent->resource[i - 3];
}
in pci_read_bridge_bases() [drivers/pci/probe.c] and refreshed by
similar in adjust_transparent_bridge_resources() [arch/x86/pci/acpi.c]
the transparent bridge child bus resource array will not reference
the resources in those last 3 slots.
> best case will be to
> revert f9cde5f as it also removed :
>
> if (info->res_num >= PCI_BUS_NUM_RESOURCES)
> return AE_OK;
>
> which is required in any case.
In the case of a root bus without a transparent bridge,
this still exists (w/added warning and resource count increment) as
if (info->res_num >= max_root_bus_resources) {
< warn and increment resource count >
return AE_OK;
}
because max_root_bus_resources==PCI_BUS_NUM_RESOURCES
In the case were there is a transparent bridge on the root bus,
'max_root_bus_resources' needs to be 3 less than PCI_BUS_NUM_RESOURCES
to avoid populating the last 3 slots of the array that are not
visible below the transparent bridge.
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
next prev parent reply other threads:[~2009-06-24 19:28 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-24 1:33 Regression with commit f9cde5f in 2.6.30-gitX Larry Finger
2009-06-24 5:31 ` Larry Finger
2009-06-24 12:16 ` Jaswinder Singh Rajput
2009-06-24 12:22 ` Ingo Molnar
2009-06-24 12:30 ` Jaswinder Singh Rajput
2009-06-24 14:46 ` Gary Hade
2009-06-24 14:21 ` Larry Finger
2009-06-24 15:16 ` Ingo Molnar
2009-06-24 15:19 ` Thomas Gleixner
2009-06-24 15:42 ` Larry Finger
2009-06-24 15:57 ` Jaswinder Singh Rajput
2009-06-24 16:13 ` Gary Hade
2009-06-24 16:33 ` Jaswinder Singh Rajput
2009-06-24 16:44 ` Jesse Barnes
2009-06-24 17:55 ` Gary Hade
2009-06-24 18:28 ` Jesse Barnes
2009-06-24 18:45 ` Thomas Gleixner
2009-06-24 19:48 ` Gary Hade
2009-06-24 20:05 ` Larry Finger
2009-06-24 21:24 ` Gary Hade
2009-06-24 22:12 ` Gary Hade
2009-06-24 21:32 ` Yinghai Lu
2009-06-24 21:42 ` Larry Finger
2009-06-24 21:44 ` Yinghai Lu
2009-06-24 22:04 ` Larry Finger
2009-06-24 22:11 ` Yinghai Lu
2009-06-24 22:53 ` Yinghai Lu
2009-06-24 23:33 ` Larry Finger
2009-06-24 23:44 ` Linus Torvalds
2009-06-24 19:28 ` Gary Hade [this message]
2009-06-24 16:52 ` Larry Finger
2009-06-24 14:51 ` Thomas Gleixner
2009-06-24 15:55 ` Jaswinder Singh Rajput
2009-06-24 16:17 ` Thomas Gleixner
2009-06-24 15:56 ` Gary Hade
2009-06-24 16:15 ` Jaswinder Singh Rajput
2009-06-24 16:33 ` Gary Hade
2009-06-24 16:25 ` Jesse Barnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090624192813.GF7239@us.ibm.com \
--to=garyhade@us.ibm.com \
--cc=Larry.Finger@lwfinger.net \
--cc=jaswinder@kernel.org \
--cc=jbarnes@virtuousgeek.org \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox