[lkml]   [2011]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [01/38] PCI: Set PCI-E Max Payload Size on fabric
    On Tue, Oct 11, 2011 at 1:56 PM, Greg KH <> wrote:
    > On Tue, Oct 11, 2011 at 01:47:47PM -0600, Bjorn Helgaas wrote:
    >> On Tue, Oct 11, 2011 at 1:24 PM, Greg KH <> wrote:
    >> > On Tue, Oct 11, 2011 at 12:14:05PM -0600, Bjorn Helgaas wrote:
    >> >> It's not obvious that this fits the criteria for -stable
    >> >> (Documentation/stable_kernel_rules.txt).
    >> >>
    >> >> For example, I can't tell what real problem this fixes.
    >> >
    >> > Yeah, it's not obvious, but I have had a lot of reports that 3.0 does
    >> > not work on some systems without this set of patches.  Now figuring out
    >> > of those same systems ever worked at all is getting to be quite
    >> > difficult as I don't have access to the hardware, and the people that do
    >> > aren't responding to test requests.  But from what I gather, 2.6.32 did
    >> > work on these boxes, so it is a regression somehow, but I am not
    >> > positive of this.
    >> I'd like to know more about this regression.
    > It shows up as an oops that prevents the machine from booting.
    >> > Now I'm very open to pushback, and if people really don't want these in
    >> > (i.e. the PCI maintainer(s) say no), then I'll drop them and work with
    >> > the distros to get them into their trees so that their customers's
    >> > systems will work properly.
    >> If distros want these patches, does that mean they have bug reports?
    >> URLs to them would be helpful.
    > All of the ones I have are "private" at the moment due to the hardware
    > and product being tested by the users, sorry.
    > I really wish that some of the people who had this problem would post
    > publically, and I guess we could just say, because they aren't being
    > public about it, it shouldn't go into a stable tree.  And I don't have a
    > problem with that.

    I think accepting patches without our having a chance to see the
    problem sets a bad precedent. It's quite common to see patches that
    "solve" the problem, but do it in the wrong way.

    If the hardware is secret, maybe they could open a new, sanitized bug
    report? It should be easy to remove the valuable details from the
    dmesg log and oops.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-10-11 22:25    [W:0.023 / U:33.148 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site