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 -- 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
