2011-06-23 20:37:50

by Jesse Barnes

[permalink] [raw]
Subject: [git pull] PCI fixes

The following changes since commit
af0d6a0a3a30946f7df69c764791f1b0643f7cd6:

Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2011-06-01 02:07:22 +0900)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 for-linus

Just a few minor fixes. We have one open issue with the resource
re-allocation code that was re-added. Ram has a fix but I'm concerned
it will introduce other regressions. So at this point we have a few
options:
- revert the bridge resource re-allocation code (again)
- hide the re-allocation code behind a new kernel option (and not
try=!), this would at least let us experiment with new strategies
and PNP resource tracking etc
- apply Ram's patch and revert it all later if things are still broken

The last option gets us the most coverage, but it's a bit late in the
cycle to be experimenting like this...

David S. Miller (1):
PCI: Fix warning in drivers/pci/probe.c on sparc64

M?rton N?meth (1):
x86/PCI/ACPI: fix type mismatch

Randy Dunlap (1):
PCI: fix new kernel-doc warning

arch/x86/pci/acpi.c | 2 +-
drivers/pci/pci.c | 2 +-
drivers/pci/probe.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)

Thanks,
--
Jesse Barnes, Intel Open Source Technology Center


2011-06-24 15:39:03

by Linus Torvalds

[permalink] [raw]
Subject: Re: [git pull] PCI fixes

On Thu, Jun 23, 2011 at 1:37 PM, Jesse Barnes <[email protected]> wrote:
>
> Just a few minor fixes. ?We have one open issue with the resource
> re-allocation code that was re-added. ?Ram has a fix but I'm concerned
> it will introduce other regressions. ?So at this point we have a few
> options:
> ?- revert the bridge resource re-allocation code (again)
> ?- hide the re-allocation code behind a new kernel option (and not
> ? ?try=!), this would at least let us experiment with new strategies
> ? ?and PNP resource tracking etc
> ?- apply Ram's patch and revert it all later if things are still broken

I think I've missed the regression discussion, so can you forward a
description and the fix?

I have to admit that I'm inclined to try the fix if it's clean, just
in the hope to get over this finally. But I'd like to see what the
problem/fix is...

Maybe I've seen it and just didn't react.

Linus

2011-06-24 15:53:33

by Jesse Barnes

[permalink] [raw]
Subject: Re: [git pull] PCI fixes

On Fri, 24 Jun 2011 08:38:07 -0700
Linus Torvalds <[email protected]> wrote:

> On Thu, Jun 23, 2011 at 1:37 PM, Jesse Barnes <[email protected]> wrote:
> >
> > Just a few minor fixes. ?We have one open issue with the resource
> > re-allocation code that was re-added. ?Ram has a fix but I'm concerned
> > it will introduce other regressions. ?So at this point we have a few
> > options:
> > ?- revert the bridge resource re-allocation code (again)
> > ?- hide the re-allocation code behind a new kernel option (and not
> > ? ?try=!), this would at least let us experiment with new strategies
> > ? ?and PNP resource tracking etc
> > ?- apply Ram's patch and revert it all later if things are still broken
>
> I think I've missed the regression discussion, so can you forward a
> description and the fix?
>
> I have to admit that I'm inclined to try the fix if it's clean, just
> in the hope to get over this finally. But I'd like to see what the
> problem/fix is...
>
> Maybe I've seen it and just didn't react.

Some discussion was under "PCI: fix cardbus and sriov regressions",
which includes a patchset as well. Oliver Hartkopp's problem is the one
that worries me most. The SR-IOV issue is really a BIOS bug and
unlikely to affect many people anyway (SR-IOV is really a big server
feature).

--
Jesse Barnes, Intel Open Source Technology Center

2011-06-24 16:08:39

by Linus Torvalds

[permalink] [raw]
Subject: Re: [git pull] PCI fixes

On Fri, Jun 24, 2011 at 8:53 AM, Jesse Barnes <[email protected]> wrote:
>
> Some discussion was under "PCI: fix cardbus and sriov regressions",
> which includes a patchset as well. Oliver Hartkopp's problem is the one
> that worries me most. The SR-IOV issue is really a BIOS bug and
> unlikely to affect many people anyway (SR-IOV is really a big server
> feature).

Ouch. That is much bigger than I was hoping for. Especially that
second patch doesn't look like some -rc5 candidate.

And the fact that Oliver then at the end shows an impossibly aligned
resource shows that it clearly isn't even remotely correct even AFTER
the patches, so that doesn't make me get all warm and fuzzy either.

So I guess we should just revert again.

Linus

2011-06-24 16:12:00

by Jesse Barnes

[permalink] [raw]
Subject: Re: [git pull] PCI fixes

On Fri, 24 Jun 2011 09:07:46 -0700
Linus Torvalds <[email protected]> wrote:

> On Fri, Jun 24, 2011 at 8:53 AM, Jesse Barnes <[email protected]> wrote:
> >
> > Some discussion was under "PCI: fix cardbus and sriov regressions",
> > which includes a patchset as well. Oliver Hartkopp's problem is the one
> > that worries me most. The SR-IOV issue is really a BIOS bug and
> > unlikely to affect many people anyway (SR-IOV is really a big server
> > feature).
>
> Ouch. That is much bigger than I was hoping for. Especially that
> second patch doesn't look like some -rc5 candidate.
>
> And the fact that Oliver then at the end shows an impossibly aligned
> resource shows that it clearly isn't even remotely correct even AFTER
> the patches, so that doesn't make me get all warm and fuzzy either.
>
> So I guess we should just revert again.

How about a boot param? We've done similar things for _CRS, and it
might give Yinghai and Ram some more flexibility in improving our
dynamic resource allocation before enabling it again (if ever).

Thanks,
--
Jesse Barnes, Intel Open Source Technology Center

2011-06-24 23:03:00

by Linus Torvalds

[permalink] [raw]
Subject: Re: [git pull] PCI fixes




Jesse Barnes <[email protected]> wrote:
>
>How about a boot param? We've done similar things for _CRS, and it
>might give Yinghai and Ram some more flexibility in improving our
>dynamic resource allocation before enabling it again (if ever).

I'm OK with that, but then I'd suggest against the currently not yet merged series that doesn't seem to work anyway...

IOW, just a simple patch that disables the resource re-allocation, and enables it with some command line option.

Linus

2011-06-25 00:01:09

by Jesse Barnes

[permalink] [raw]
Subject: Re: [git pull] PCI fixes

On Fri, 24 Jun 2011 15:56:42 -0700
Linus Torvalds <[email protected]> wrote:

>
>
>
> Jesse Barnes <[email protected]> wrote:
> >
> >How about a boot param? We've done similar things for _CRS, and it
> >might give Yinghai and Ram some more flexibility in improving our
> >dynamic resource allocation before enabling it again (if ever).
>
> I'm OK with that, but then I'd suggest against the currently not yet merged series that doesn't seem to work anyway...
>
> IOW, just a simple patch that disables the resource re-allocation, and enables it with some command line option.

Ok sounds good, thanks.

--
Jesse Barnes, Intel Open Source Technology Center

2011-06-25 00:18:28

by Yinghai Lu

[permalink] [raw]
Subject: Re: [git pull] PCI fixes

On 06/24/2011 05:00 PM, Jesse Barnes wrote:
> On Fri, 24 Jun 2011 15:56:42 -0700
> Linus Torvalds <[email protected]> wrote:
>
>>
>>
>>
>> Jesse Barnes <[email protected]> wrote:
>>>
>>> How about a boot param? We've done similar things for _CRS, and it
>>> might give Yinghai and Ram some more flexibility in improving our
>>> dynamic resource allocation before enabling it again (if ever).
>>
>> I'm OK with that, but then I'd suggest against the currently not yet merged series that doesn't seem to work anyway...
>>
>> IOW, just a simple patch that disables the resource re-allocation, and enables it with some command line option.
>
> Ok sounds good, thanks.

please check the draft one, not sure if you like
pci=try=2
or
pci=reallocate_bridge


[PATCH] pci: disable pci trying to reallocate pci bridge by default.

| PCI: update bridge resources to get more big ranges when allocating space (again)
| da7822e5ad71ec9b745b412639f1e5e0ba795a20

still too risky and cause some systems have problem.

Disable reallocating feature, So other user could use command line enable it
to enable it with "pci=try=2"

Signed-off-by: Yinghai Lu <[email protected]>

---
Documentation/kernel-parameters.txt | 6 ++++++
drivers/pci/pci.c | 4 ++++
drivers/pci/pci.h | 2 ++
drivers/pci/setup-bus.c | 15 +++++++++------
4 files changed, 21 insertions(+), 6 deletions(-)

Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -1980,6 +1980,12 @@ bytes respectively. Such letter suffixes
for broken drivers that don't call it.
skip_isa_align [X86] do not align io start addr, so can
handle more pci cards
+ try=n set the pci_try_num to reallocate the pci bridge resource
+ 1: default
+ 2: will set the num to max_depth, and try to reallocate res
+ to get big range for the bridge. assume the pci peer root
+ resource is right from _CRS or from hostbridge pci reg
+ reading out.
firmware [ARM] Do not re-enumerate the bus but instead
just use the configuration from the
bootloader. This is currently used on
Index: linux-2.6/drivers/pci/pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
@@ -3485,6 +3485,10 @@ static int __init pci_setup(char *str)
pci_no_aer();
} else if (!strcmp(str, "nodomains")) {
pci_no_domains();
+ } else if (!strncmp(str, "try=", 4)) {
+ int try_num = memparse(str + 4, &str);
+ if (try_num > 0)
+ pci_try_num = try_num;
} else if (!strncmp(str, "cbiosize=", 9)) {
pci_cardbus_io_size = memparse(str + 9, &str);
} else if (!strncmp(str, "cbmemsize=", 10)) {
Index: linux-2.6/drivers/pci/pci.h
===================================================================
--- linux-2.6.orig/drivers/pci/pci.h
+++ linux-2.6/drivers/pci/pci.h
@@ -223,6 +223,8 @@ static inline int pci_ari_enabled(struct
return bus->self && bus->self->ari_enabled;
}

+extern int pci_try_num;
+
#ifdef CONFIG_PCI_QUIRKS
extern int pci_is_reassigndev(struct pci_dev *dev);
resource_size_t pci_specified_resource_alignment(struct pci_dev *dev);
Index: linux-2.6/drivers/pci/setup-bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -1030,6 +1030,7 @@ static int __init pci_get_max_depth(void
* second and later try will clear small leaf bridge res
* will stop till to the max deepth if can not find good one
*/
+int pci_try_num = 1;
void __init
pci_assign_unassigned_resources(void)
{
@@ -1042,16 +1043,18 @@ pci_assign_unassigned_resources(void)
unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
IORESOURCE_PREFETCH;
unsigned long failed_type;
- int max_depth = pci_get_max_depth();
- int pci_try_num;
-

head.next = NULL;
add_list.next = NULL;

- pci_try_num = max_depth + 1;
- printk(KERN_DEBUG "PCI: max bus depth: %d pci_try_num: %d\n",
- max_depth, pci_try_num);
+ if (pci_try_num > 1) {
+ int max_depth = pci_get_max_depth();
+
+ if (max_depth + 1 > pci_try_num)
+ pci_try_num = max_depth + 1;
+ printk(KERN_DEBUG "PCI: max bus depth: %d pci_try_num: %d\n",
+ max_depth, pci_try_num);
+ }

again:
/* Depth first, calculate sizes and alignments of all

2011-06-28 17:03:58

by Jesse Barnes

[permalink] [raw]
Subject: Re: [git pull] PCI fixes

On Fri, 24 Jun 2011 15:56:42 -0700
Linus Torvalds <[email protected]> wrote:

>
>
>
> Jesse Barnes <[email protected]> wrote:
> >
> >How about a boot param? We've done similar things for _CRS, and it
> >might give Yinghai and Ram some more flexibility in improving our
> >dynamic resource allocation before enabling it again (if ever).
>
> I'm OK with that, but then I'd suggest against the currently not yet merged series that doesn't seem to work anyway...
>
> IOW, just a simple patch that disables the resource re-allocation, and enables it with some command line option.

Ram or Yinghai, want to come up with something? (And
note: pci=bridge_realloc or something would be a lot more descriptive
than pci=try=2!)

Thanks,
--
Jesse Barnes, Intel Open Source Technology Center

2011-06-29 01:05:16

by Ram Pai

[permalink] [raw]
Subject: Re: [git pull] PCI fixes

On Tue, Jun 28, 2011 at 10:02:27AM -0700, Jesse Barnes wrote:
> On Fri, 24 Jun 2011 15:56:42 -0700
> Linus Torvalds <[email protected]> wrote:
>
> >
> >
> >
> > Jesse Barnes <[email protected]> wrote:
> > >
> > >How about a boot param? We've done similar things for _CRS, and it
> > >might give Yinghai and Ram some more flexibility in improving our
> > >dynamic resource allocation before enabling it again (if ever).
> >
> > I'm OK with that, but then I'd suggest against the currently not yet merged series that doesn't seem to work anyway...
> >
> > IOW, just a simple patch that disables the resource re-allocation, and enables it with some command line option.
>
> Ram or Yinghai, want to come up with something? (And
> note: pci=bridge_realloc or something would be a lot more descriptive
> than pci=try=2!)
Jesse,

Will have something your way soon.

RP