Skip to contentSkip to conversation

PCI: Work around Stratus ftServer broken PCIe hierarchy

PATCH In review Myron Stowe 2 participants 2 messages Dec 19, 2012 – Dec 20, 2012

Subsystems (2)
x86 PCI
lore
Share & tools
lore

Myron Stowe

author
#0 lore raw

PATCH 1/1 PCI: Work around Stratus ftServer broken PCIe hierarchy

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 <[email protected]>
Signed-off-by Myron Stowe <[email protected]>

---

 arch/x86/pci/common.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
arch/x86/pci/common.c +2 -1
index 720e973..487d9f3 100644
@@ -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"),
 		},
 	},
 	{}
maintainer
#1 lore raw
Quoted 57 lines · Myron Stowe

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 <[email protected]>
Signed-off-by Myron Stowe <[email protected]>

---

 arch/x86/pci/common.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
arch/x86/pci/common.c +0 -0
index 720e973..487d9f3 100644

arch/x86/pci/common.c static const struct dmi_system_id __devinitconst pciprobe_dmi_table[] = { · line 440

Quoted 9 lines
arch/x86/pci/common.c +2 -1
@@ -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