linux-kernel - Re: [PATCH] PCI: Work around Stratus ftServer broken PCIe hierarchy

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]

Date:	Thu, 20 Dec 2012 14:46:06 -0700
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Myron Stowe <myron.stowe@...hat.com>
Cc:	linux-pci@...r.kernel.org, astarta@....ru, ddutile@...hat.com,
	james.paradis@...atus.com, matthew.r.wilcox@...el.com,
	prarit@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: Work around Stratus ftServer broken PCIe hierarchy

On Wed, Dec 19, 2012 at 2:50 PM, Myron Stowe <myron.stowe@...hat.com> wrote:
> Recently, another report surfaced indicating Stratus ftServer platforms
> were exhibiting similar failures as has occurred in the past [1].
>
>   In late 2011 we started seeing issues with Stratus ftServer systems.
>   The typical failure was that USB and network devices were not being
>   seen.  Research uncovered that the failure was due to the platform's PCI
>   Express hierarchy  not conforming to the PCI Express specification [2]
>   which commit f07852d exposed.
>
>   The following are known Stratus ftServer platforms whose PCI hierarchies
>   are broken:
>
>   Stratus ftServer ????
>   +-07.0-[01-76]--+-00.0-[02-76]--+-00.0-[03-3c]--+-00.0-[04-09]..
>                                                   \-01.0-[0a-0d]--+-[USB]
>                                                                   +-[NIC]
>                                                                   +-..
>
>   Stratus ftServer 6400
>   [0000:00]-+-...-00.0-[03]-00.0-[04]-+-00.0-[05]---00.0-[06]..
>             |  |                      |
>             |  |                      \-01.0-[2c]-+-00.0 [USB]
>             |  |                                  +-00.1 [USB]
>             |  |                                  \-1f.0 [ISA]
>
>   Stratus ftServer 4500
>   Stratus ftServer 6310
>
>   As a solution, commit 284f5f9 was introduced.
>
> Looking into this again it looks as if the quirk introduced in 284f5f9 is
> not making the correct DMI based check.  This patch fixes the DMI 'vendor'
> based check to match "Stratus", not "ftServer".  It also augments the
> checking to include matching the DMI based 'product name' to "ftServer".
> This quirk should now trigger for all Stratus ftServer platforms which I
> was able to confirm by testing on a Stratus ftServer 6400 system with the
> following 'dmidecode' output:
>   System Information
>         Manufacturer: Stratus
>         Product Name: ftServer 6400
>
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=51331
> [2] PCI Express specification, r3.0, Section 7.3.1
>
> Reported-by: Fadeeva Marina <astarta@....ru>
> Signed-off-by: Myron Stowe <myron.stowe@...hat.com>
> ---
>
>  arch/x86/pci/common.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
> index 720e973..487d9f3 100644
> --- a/arch/x86/pci/common.c
> +++ b/arch/x86/pci/common.c
> @@ -433,7 +433,8 @@ static const struct dmi_system_id __devinitconst pciprobe_dmi_table[] = {
>                 .callback = set_scan_all,
>                 .ident = "Stratus/NEC ftServer",
>                 .matches = {
> -                       DMI_MATCH(DMI_SYS_VENDOR, "ftServer"),
> +                       DMI_MATCH(DMI_SYS_VENDOR, "Stratus"),
> +                       DMI_MATCH(DMI_PRODUCT_NAME, "ftServer"),
>                 },
>         },
>         {}
>

I added this to my pci/for-3.8 branch, which I'll ask Linus to pull
soon after v3.8-rc1.  Thanks!

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/