Re: [01/38] PCI: Set PCI-E Max Payload Size on fabric

[Bjorn Helgaas]

On Tue, Oct 11, 2011 at 1:56 PM, Greg KH <greg@xxxxxxxxx> 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 <greg@xxxxxxxxx> 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.

Bjorn
--
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/