public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gary Hade <garyhade@us.ibm.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>,
	Gary Hade <garyhade@us.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Larry Finger <Larry.Finger@lwfinger.net>,
	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 10:55:13 -0700	[thread overview]
Message-ID: <20090624175513.GE7239@us.ibm.com> (raw)
In-Reply-To: <20090624094411.08fc66e6@jbarnes-g45>

On Wed, Jun 24, 2009 at 09:44:11AM -0700, Jesse Barnes wrote:
> On Wed, 24 Jun 2009 22:03:39 +0530
> Jaswinder Singh Rajput <jaswinder@kernel.org> 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).
> > 
> > Then what is the point of removing last 3 and then adding 3 or more
> > resources, so patch f9cde5f lost its purpose, 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.
> 
> Yeah, I missed that too...  Gary how do you feel about that as the real
> fix?  Would it be safe to make this a fairly high value like 64?  Or
> should we try to do something more flexible...

Sorry I missed the 16->24 change and other good information
in Larry's earlier message.  There were 17 occurrences of the
"PCI: transparent bridge..." message that Larry added which 
indicates that _CRS returned 17 resources.  This is 4 more
than the current 13 maximum which explains the problem. 
I believe Larry's 8 slot increase (16->24) in the array size
provided 4 slots beyond what is needed for Larry's box but
an even higher ceiling would certainly feel more comfortable.
I was thinking 32 but 64 would be better if there aren't any
downsides elsewhere of making the array that big.

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


  reply	other threads:[~2009-06-24 17:55 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 [this message]
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
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=20090624175513.GE7239@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