lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20161114142158.6823fbd2@t450s.home>
Date:   Mon, 14 Nov 2016 14:21:58 -0700
From:   Alex Williamson <alex.williamson@...hat.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     linux-pci@...r.kernel.org, bhelgaas@...gle.com,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] PCI: Balance ports to avoid ACS errata on Pericom
 switches

On Mon, 14 Nov 2016 15:03:19 -0600
Bjorn Helgaas <helgaas@...nel.org> wrote:

> On Wed, Oct 26, 2016 at 12:01:40PM -0600, Alex Williamson wrote:
> > As described in the included code comment, this quirk is intended to
> > work around an errata in a variety of Pericom 4-lane, 3 and 4 port
> > PCIe 2.0 switches.  The switches advertise ACS capabilities, but the
> > P2P Request Redirection support includes an errata that PCI_ACS_RR
> > effectively doesn't work and results in transactions being queued and
> > not delivered within the PCIe switch.  The errata has no planned
> > hardware fix.  
> 
> Is there a published erratum we can reference here?  It'd be really
> nice to have a URL.

Unfortunately only the product briefs seem to be public.  I was sent an
errata, but it's marked confidential, so I don't think I'll risk adding
it to the bz.  I haven't even been granted access to the datasheet.
I'm only guessing at the affected devices IDs based on my sample of one.

One thing I've thought of since I posted this series is that it's
possible to have a configuration where the downstream ports don't all
match.  If the upstream port is running at 5GT/s, the first downstream
port is also running 5GT/s, but another downstream port is running
2.5GT/s, this code will retrain the upstream port to 2.5GT/s w/o
revisiting that first port.  I should fix that, but I likely won't have
time for v4.10.  If you want to de-queue this, I'll try to look at it
again for v4.11 and take your other suggestions into account.  Thanks,

Alex

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ