[lkml]   [2010]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Patch 1/1] x86 pci: Add option to not assign BAR's if not already assigned

    Jesse Barnes wrote:
    > On Fri, 14 May 2010 15:34:01 -0700
    > Mike Travis <> wrote:
    >> Jesse Barnes wrote:
    >>> On Thu, 13 May 2010 14:02:30 -0600
    >>> Bjorn Helgaas <> 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.

     \ /
      Last update: 2010-05-15 01:01    [W:0.049 / U:1.300 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site