On 02/26/2015 04:34 PM, Bjorn Helgaas wrote:
So it looks like the Unsupported Request error is unrelated to the problem
you're seeing. Probably left over from something the BIOS did when it
enumerated devices.
You could look at "lspci -vv" again after clearing the errors and loading
the driver. But I think it will be the same as it was after you manually
cleared the errors.
(after clearing errors) http://pastebin.com/UxdgDyp1
Oh, one more idea: *before* clearing the errors, can you collect
"lspci -xxxxs05:00.0" output? That will give us more AER log registers,
and it's possible there's a clue there. It's conceivable that we have
an MPS issue that causes the Unsupported Request error.
(before clearing errors w/ card in @ boot) http://pastebin.com/wTeNjHHT
(before clearing errors w/ card out @ boot) http://pastebin.com/4Q82KNNc
Just to be exhaustive, can you also stash the "lspci -vvv" output for the
entire system somewhere (again, before clearing the error).
http://pastebin.com/K4iPhGcq
not sure if this is relevant but for debugging sake here is the output
of the card when left out during boot (no UnsupReq error)...
05:00.0 PCI bridge: Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG PCI
to PCIe Bridge (prog-if 00 [Normal decode])
Physical Slot: 3
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Bus: primary=05, secondary=06, subordinate=06, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: f8000000-f80fffff
Prefetchable memory behind bridge: 00000000f4000000-00000000f40fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
Capabilities: [60] MSI: Enable- Count=1/16 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [80] Subsystem: Creative Labs Device 0040
Capabilities: [90] Express (v1) PCI-Express to PCI/PCI-X Bridge, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0
ExtTag- AttnBtn- AttnInd- PwrInd- RBE-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ BrConfRtry-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency
L0s <512ns, L1 <16us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
The device is at [mem 0xf4300000-0xf4303fff], so anything in that region
should respond. Why don't you try this, which should dump the whole
region:
./mem -N -m -s 0xf4300000 -l 0x4000
http://pastebin.com/eHEsZNmU
The data there looks fine, at least from a PCI perspective:
F4300000:00 33 00 01 3C 00 1D 00 01 00 00 00 00 00 00 00
F4300010:00 00 00 00 00 00 00 00 3C 00 1D 00 00 00 00 00
F4300020:00 00 00 C0 00 00 00 00 00 00 00 00 00 00 00 00
F4300030:0F FA 24 A8 00 00 00 00 00 00 00 00 00 00 00 00
...
That means the device itself seems happy and is responding to read
requests.
The only thing left I can think of to do is to instrument the driver and
see where it gets data that it doesn't expect. So I'm going to punt this
back to you, Takashi :) Don't hesitate to send it back to me if you find
something that looks like a PCI problem, but I don't see one yet.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html