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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.