On Wed, Oct 5, 2011 at 7:21 PM, Ben Hutchings <bhutchings@xxxxxxxxxxxxxx> wrote: > After this change, in 'safe' mode we get the correct MPS. The kernel > log with DEBUG defined for drivers/pci shows: > > pci 0000:03:00.0: Dev MPS 128 MPSS 256 MRRS 512 > pci 0000:03:00.0: Dev MPS 256 MPSS 256 MRRS 512 > pci 0000:03:00.1: Dev MPS 128 MPSS 256 MRRS 512 > pci 0000:03:00.1: Dev MPS 256 MPSS 256 MRRS 512 > > but in 'performance' mode the result is incorrect: > > pci 0000:03:00.0: Dev MPS 128 MPSS 256 MRRS 512 > pci_bus 0000:03: Bus MPSS 512 > pci 0000:03:00.0: MPS configured higher than maximum supported by the device. If a bus issue occurs, try running with pci=pcie_bus_safe. > pci 0000:03:00.0: Dev MPS 512 MPSS 512 MRRS 512 > pci 0000:03:00.1: Dev MPS 128 MPSS 256 MRRS 512 > pci_bus 0000:03: Bus MPSS 512 > pci 0000:03:00.1: MPS configured higher than maximum supported by the device. If a bus issue occurs, try running with pci=pcie_bus_safe. > pci 0000:03:00.1: Dev MPS 512 MPSS 512 MRRS 512 > > I thought the idea was to let bridges have higher MPS than some of their > descendants while setting MRRS on the descendants as an extra constraint > on payload size. But this is instead increasing MPS and MRRS (and the > nominal MPSS!) on the descendant, which is crazy. Yes, these are known issues. Linus rejected the fixes for 3.1 (not for lack of benh trying) :( Thanks for trying it out. I'll re-push the fixes once Jesse opens up the 3.2 queue. Thanks, Jon > > However, Jon's latest fixes seem to produce the correct result: > > pci 0000:03:00.0: Dev MPS 128 MPSS 256 MRRS 512 > pci 0000:03:00.0: Dev MPS 256 MPSS 256 MRRS 256 > pci 0000:03:00.1: Dev MPS 128 MPSS 256 MRRS 512 > pci 0000:03:00.1: Dev MPS 256 MPSS 256 MRRS 256 > > Ben. > > -- > Ben Hutchings, Staff Engineer, Solarflare > Not speaking for my employer; that's the marketing department's job. > They asked us to note that Solarflare product names are trademarked. > > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
