[lkml]   [2011]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Workaround for Intel MPS errata
On Fri, Sep 30, 2011 at 12:17 PM, Bjorn Helgaas <> wrote:
> On Fri, Sep 30, 2011 at 9:35 AM, Jon Mason <> wrote:
>> On Fri, Sep 30, 2011 at 12:01 AM, Bjorn Helgaas <> wrote:
>> > On Thu, Sep 29, 2011 at 6:16 PM, Jon Mason <> wrote:
>> >> Hey Avi,
>> >> Can you try this patch?  It should resolve the issue you are seeing.
>> >>
>> >> Thanks,
>> >> Jon
>> >>
>> >>    PCI: Workaround for Intel MPS errata
>> >>
>> >>    Intel 5000 and 5100 series memory controllers have a known issue if read
>> >>    completion coalescing is enabled (the default setting) and the PCI-E
>> >>    Maximum Payload Size is set to 256B.  To work around this issue, disable
>> >>    read completion coalescing if the MPS is 256B.
>> >
>> > I'd much rather see this done as an early quirk so it doesn't clutter probe.c.
>> >
>> > I don't know how you decide whether
>> >    - no coalescing with MPS=256, or
>> >    - coalescing with MPS=128
>> > is better.  I suspect that having a quirk that doesn't change the
>> > setting, but merely limits MPS to 128 if the BIOS enabled coalescing,
>> > would be simplest and would stay in the best-tested chipset
>> > configuration.
>> This is what I was debating yesterday.  Is it better to disable
>> coalescing and get better throughput (which could be a net negative if
>> the MPS isn't 256) or never allow it to be greater than 128?  There is
>> no way of knowing at quirk time if the disable is necessary or not,
>> only when setting the MPS is it known (which is why I did it this
>> way).  I could, as you suggest, simply read the bit and see if it is
>> enabled by the BIOS (which I'd bet it is every single time), and then
>> limit the MPS to 128 as a quirk.  This would be fairly simple to do.
>> However, the errata from Intel says Windows 2008 always disables the
>> coalescing and sets the MPS to 256B.  With this known, Linux's I/O
>> performance would be less than Windows on these systems. ...
> Presumably coalescing improves performance, too, and I don't have the
> evidence that says "no coalescing with MPS=256" performs better than
> "coalescing with MPS=128."
> But the fact that Windows 2008 disables coalescing is worth a lot (if
> this is in a public erratum, a URL would be good).  Given that, I'd

The URLs were in the top of the patch, but perhaps they weren't obvious.

Search for "MPS", as they are several pages into the errata chapter.

> probably go with "no coalescing and MPS=256" just as you did.
> Maybe the quirk could be moved out of the generic code by making
> pcie_set_mps() a weak function, so x86 could supply a version that
> disables coalescing if MPS=256?

Not sure what you mean here. Are you saying to make the function
defined differently on each arch?

> No news from Avi?  Were you able to reproduce the problem and verify

None so far. I believe he is in .il, so we might not hear back until Sunday.

> that the quirk fixes it?  I wish the bugzilla were back.

I just found a system to try it on! It has an Intel Corporation 5000X
Chipset Memory Controller Hub, which should have the erratum.

> Since it's not, maybe we should include the LKML URL
> ( in the changelog.

Will do.

> Bjorn
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-09-30 19:41    [W:0.048 / U:4.104 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site