Messages in this thread | | | From | Bjorn Helgaas <> | Date | Tue, 11 Oct 2011 14:22:11 -0600 | Subject | Re: [01/38] PCI: Set PCI-E Max Payload Size on fabric |
| |
On Tue, Oct 11, 2011 at 1:56 PM, Greg KH <greg@kroah.com> 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@kroah.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |