Re: PCI Issues with ExpressCard/54 Audio Device

[Bjorn Helgaas <bhelgaas@google.com>]

On Thu, Feb 26, 2015 at 11:32:31AM -0800, Alnie wrote:
> On 02/26/2015 09:46 AM, Bjorn Helgaas wrote:
> >On Thu, Feb 26, 2015 at 12:22:42AM -0800, Alnie wrote:

> >>	Capabilities: [100 v1] Advanced Error Reporting
> >>		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> >>MalfTLP- ECRC- UnsupReq+ ACSViol-
> >
> >This looks suspicious: the bridge logged an Unsupported Request error.
> >Let's see if we can figure out if this error is left there by BIOS or if
> >the PCI core or the driver or rdwrmem is doing something that causes it.
> >
> >Can you try this:
> >
> >   - Boot without the snd_hda_intel driver at all
> >   - Collect "lspci -vvs05:00.0" output
> 
> blacklist snd_hda_intel
> 
> 05:00.0 PCI bridge: Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG
> PCI to PCIe Bridge (prog-if 00 [Normal decode])
> ...
> 	Capabilities: [100 v1] Advanced Error Reporting
> 		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> MalfTLP- ECRC- UnsupReq+ ACSViol-

All three of your lspci outputs are identical, so it looks like the BIOS
probably left UnsupReq set.  Maybe the kernel should log that and clear it
at boot.  I sort of doubt this is the problem, but we can try clearing
those errors manually:

  lspci -vvs05:00.0
  setpci -s05:00.0 0x9a.w=0x0a		# clear UncorrErr UnsuppReq
  setpci -s05:00.0 0x104.l=0x00100000	# clear AER UnsupReq
  lspci -vvs05:00.0
  modprobe snd-hda-intel

> >   - Poke around with rdwr
> 
> (I am unfamiliar with this & hex, was trying different things,
> please correct me in case)
> 
> # ./mem -N -m -s 0xf4300000
> ./mem: request seek to 4096786432, but -198180864 returned
> F4300000:00
> # ./mem -N -m -s f4300000
> 00000000:53
> # ./mem -N -m -s f4310000
> 00000000:53
> # ./mem -N -m -s 0xf4310000
> ./mem: request seek to 4096851968, but -198115328 returned
> F4310000:FF

The first and last ones are on the right track.  The program uses strtoul()
to convert the address.  That function assumes decimal unless there's a
"0x" prefix.  So "-s f4300000" converts to zero, and "-s 0xf4300000" does
what you want.

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

But what's interesting already is that you found these:

  F4300000:00
  F4310000:FF

So we got 0x00 at 0xf4300000, which means the device did respond there.
If that path to the device works, all PCI accesses to it *should* work.

Bjorn