Well, this is irritating. So, I ordered a RAID controller card for my SSD drive thinking that it would enable the full throughput of the drive because the on-board SATA controller on the Dell MT435 XPS is only SATA v2 at 3Gbps, or half of what I need. So, my RocketRaid 620 card promptly arrives, and I throw it in the machine, and I find that despite the SATA link being v3 at 6Gbps, my throughput has nonetheless dropped from roughly 0.25GB to 0.18GB. So, I try all manner of sensible things to get it to come up. I build and install the OEM drivers from HighPoint. No improvement. I flash my RAID controller BIOS, which disappointingly provides an enhanced config menu at the cost of AHCI support (what?). It seems like a downgrade, if anything. I install the RAID management program. I assign the SSD to a 1-disk "array", in case RAID-mode is faster. Still no improvement. So, I begin reading up on my system specifications to ensure that my system supports PCIE 2, which one would hope, since the machine was sold almost two years after the publication of the standard.
One would expect that the answer to such a basic hardware question would be readily available, and one would be completely wrong. Why? Because, once again, the marketing department's whims thoroughly triumph over common sense. Ride along with me on this completely fruitless and stupid journey. Our first stop is Dell's support site at support.dell.com. Typically, when we need specs on a piece of hardware, we look in the manual, where hardware specs belong. Let's see. We have 1 PCIEx16 slot, and 3 PCIx1 slots. Great. The multiplier tells us how many channels or "lanes" are provided by each slot, but we still need to know the PCIE version because our expansion board is x1 and I'm not going to swap out my x16 video card anyway. At any rate, we still don't know whether the slots are v1 or v2, and nowhere in any of the manuals does it specify.
Well, since we aren't getting any help from the manufacturer at the product level, we can "drill down", as they say in the corporate world, to the component level and look for assistance there. So, I look up the parts list for my machine, in search of the motherboard model number, and I get gibberish like this:
N575K QTY 0 SERVICE CHARGE..., HYPERTEXT MARKUP LANGUAGE...,
INTEL..., LAN ON MOTHERBOARD..., 435MT
I interpret this to mean that I was assessed a service fee for a zero-quantity of part number N575 which consisted of HTML, an Intel something-or-other, and integrated ethernet. That makes perfect sense, or whatever is the complete opposite. Nevertheless, by searching for all occurrences of the word "motherboard", I was able to find the one line item which actually does refer to the motherboard, and I determined that the part number is R843J. This is great! Maybe now I can finally get some support. Not to make a long story even longer, this is the "specs" page for the motherboard in question. It does not help. At all.
So, having completely struck out on support from the manufacturer at both the product and component levels, we can begin digging after subcomponents in the hopes of answering the timeless riddle of what type of PCIE support I have. Cursory Googling does not provide any direct answer, but it does reveal that the system board uses the X58 and ICH10R chipsets, which are roughly analogous to a north and south bridge on older machines. We can go to Intel for specs on these and behold, wonder of wonders, a manufacturer who actually bothers to document their products. This is expected, since Intel is perhaps the lead developer of the PC architecture, and they would not maintain that status if nobody could locate or make sense of their documentation.
Homestretch? No way. As it turns out, in a strange twist, both chipsets suport PCI Express. The X58 does v2, and the ICH10R does v1.1. So the question becomes: to which chipset is each slot connected? That would have been a question for the motherboard manufacturer, whom I would at this point describe as having achieved a depth of inefficacy so deeply nested as to constitute a fractal of pure fail.
Now I'm convinced that not even Dell knows which slots on the XPS 435MT support PCIE 2.0. So, let's ask Linux. We can do lspci -t, which gives:
...
\-[0000:00]-+-00.0
+-01.0-[07]--
+-03.0-[06]--
+-07.0-[05]--+-00.0
| \-00.1
+-14.0
+-14.1
+-14.2
+-14.3
+-19.0
+-1a.0
+-1a.1
+-1a.2
+-1a.7
+-1c.0-[04]--
+-1c.3-[03]--+-00.0
| \-00.1
+-1c.4-[02]----00.0
+-1d.0
+-1d.1
+-1d.2
+-1d.7
+-1e.0-[01]--
+-1f.0
+-1f.2
\-1f.3
Using the ouput of
lspci -vvv for further reference, we know that [03] is the RAID controller, and it is connected to function 3 of slot 1c, the info of which looks like this:
0000:00:1c.3 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 4 (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 0000c000-0000dfff
Memory behind bridge: fbd00000-fbdfffff
Prefetchable memory behind bridge: 00000000c0400000-00000000c05fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #4, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
Slot #0, PowerLimit 10.000W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet+ LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: feeff00c Data: 4171
Capabilities: [90] Subsystem: Dell Device 02c9
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=04 ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: pcieport
Right away, we can see that this makes much more sense than a Dell parts list. We have a PCIE v1.0 slot which is capped at 2.5Gbps. Well, this sucks. However, I'm still not done. Because when we go back and look at the bus tree, we see that bus 5 is connected to bus 7, and I happen to know that 5 is my PCI v2x16 video card which does operate at 5Gbps/lane. It has neighbors in the tree which are empty, so maybe there is still some slim chance that the drive controller's slot can be routed to the X58 interface, though it seems unlikely. It seems similarly unlikely that someone would have routed PCI slots around an available fast interface to a slow one, but I've yet to figure out if that's what has actually happened, but I think the primary takeaway from this, as the business school kids say, is that crappy documentation wastes time.