On Friday, November 23, 2012 5:56:02 pm Adrian Chadd wrote: > Thanks for this! > > I'm sorry it hasn't gotten any more attention. I've cc'ed john because > he understands the PCI-PCI resource allocation stuff and I currently > don't; I'm hoping he can stare at this and see what's going on. > > But yes, if it were an ath(4) problem, the NIC would be returning > 0xdeadbeef, 0xdeadc0de, etc. It wouldn't return 0xffffffff - that > happens when there's nothing mapped at that address. > > The PCI config space that you've provided shows BAR(0) is programmed correctly.. Your dmesg shows that another device behind the same PCI-PCI bridge is working fine (fxp0), so the bridge is configured correctly. Also, the PCI command register for ath0 has memory decoding enabled, so everything should be fine from PCI's perspective. Note that if you want to examine specific registers you can use dd with /dev/mem (albeit carefully), e.g. dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) count=1 | hd to read a single 32-bit register. I think that the card is in fact returning the value you see from its registers. I would do some reads of other registers using dd to see if all of the device registers are returning -1 or if only certain registers are. -- John BaldwinReceived on Tue Dec 04 2012 - 17:42:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:32 UTC