Re: [Patch 1/1] x86 pci: Add option to not assign BAR's if not alreadyassigned

From: Mike Travis
Date: Fri May 14 2010 - 18:59:23 EST




Jesse Barnes wrote:
On Fri, 14 May 2010 15:34:01 -0700
Mike Travis <travis@xxxxxxx> wrote:


Jesse Barnes wrote:
On Thu, 13 May 2010 14:02:30 -0600
Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote:
This issue is not specific to x86, so I don't really like having
the implementation be x86-specific.
I agree this isn't a x86 specific issue but given the 'norom'
cmdline option is basically doing the same thing (but for pci
Expansion ROM BARs) this code was modeled after it.
IMHO, we should fix both.
Yeah, that would be good. Mike, have you looked at this at all?

Also, to clarify, this isn't affecting users today, right? Or do you
need all this I/O space for multiple IOHs and the drivers that bind to
them in current UV systems?
We have customers that want to install more than 16 PCI-e cards right
now. Our window of opportunity closes very soon (days), so either this
patch makes it in as is (or something close), or we wait for another
release cycle. UV shipments start this month.

[I wouldn't mind working on an improvement for later.]

Wow and they're using cards that want to use I/O space? Funky. It's
too late to get this into 2.6.34, but that can't be what you were
expecting... I don't see a problem with getting something like this in
for 2.6.35.

2.6.35 would be fine. It's the acceptance that's the key.

And yes, we're using standard cards like everyone else... ;-)

[The message is "UV" is just a really, really big PC. ;-)]

I would appreciate however, some more detail on what's the goal of the
updates to "fix both". Thanks!


Fundamentally, until we have real dynamic PCI resource management (i.e.
driver hooks for handling relocation, lazy allocation of resources at
driver bind time, etc.) we're going to continue to need hacks like
this. However, we could make them slightly more automated by making
"nobar" and "norom" the default on systems that typically need them,
maybe with a DMI table.
It seems that BIOS changes are much more difficult. The real solution
to this problem is for Card Vendors to not request I/O Bars if they
won't be using them. But that's the hardest option of all to accomplish.

Right.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/