[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161027115152.GG17507@bhelgaas-glaptop.roam.corp.google.com>
Date: Thu, 27 Oct 2016 06:51:52 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Hannes Reinecke <hare@...e.de>
Cc: Johannes Thumshirn <jthumshirn@...e.de>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Yinghai Lu <yinghai@...nel.org>, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pci: Don't set RCB bit in LNKCTL if the upstream bridge
hasn't
On Thu, Oct 27, 2016 at 07:42:27AM +0200, Hannes Reinecke wrote:
> On 10/26/2016 09:43 PM, Bjorn Helgaas wrote:
> > Hi Johannes,
> >
> > On Wed, Oct 26, 2016 at 03:53:34PM +0200, Johannes Thumshirn wrote:
> >> The Read Completion Boundary bit must only be set on a device or endpoint if
> >> it is set on the upstream bridge.
> >>
> >> Fixes: 7a1562d4f ("PCI: Apply _HPX Link Control settings to all devices with a link")
> >
> > Can you please include a spec citation and a pointer to the bug report?
> >
> PCI Express Base Specification 1.1,
> section 2.3.1.1. Data Return for Read Requests:
>
> The Read Completion Boundary (RCB) parameter determines the naturally
> aligned address boundaries on which a Read Request may be serviced with
> multiple Completions
> o For a Root Complex, RCB is 64 bytes or 128 bytes
> o This value is reported through a configuration register
> (see Section 7.8)
> Note: Bridges and Endpoints may implement a corresponding command
> bit which may be set by system software to indicate the RCB value
> for the Root Complex, allowing the Bridge/Endpoint to optimize its
> behavior when the Root Complex’s RCB is 128 bytes.
> o For all other system elements, RCB is 128 bytes
>
> In this particular case the _HPX method was causing the RCB for all PCI
> devices to be set to 128 bytes, while the root bridge remained at 64 bytes.
> While this is arguably a BIOS bug, earlier linux version (ie without the
> mentioned patch) were running fine, so this is actually a regression.
Thanks! I can fold this into the changelog.
I assume you didn't mention a bugzilla or similar URL because this was
found internally? I'd still like a clue about what this issue looks
like to a user, because that helps connect future problem reports with
this fix.
And I suppose that since 7a1562d4f2d0 appeared in v3.18, we maybe
should consider marking the fix for stable?
Bjorn
Powered by blists - more mailing lists