Re: PCI Issues with ExpressCard/54 Audio Device

[Alnie <memobook80@comcast.net>]

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
>