Date: Tue, 4 Dec 2012 11:06:50 -0500 From: John Baldwin <jhb@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: husyh@hush.com, freebsd-current@freebsd.org Subject: Re: ath0: unable to attach hardware Message-ID: <201212041106.50645.jhb@freebsd.org> In-Reply-To: <CAJ-VmonYjXvx_sxSMYbPkNQ7HmbosWqHWbttDapOyiB=jwd-Lg@mail.gmail.com> References: <20121123213551.C2CB9E6739@smtp.hushmail.com> <CAJ-VmonYjXvx_sxSMYbPkNQ7HmbosWqHWbttDapOyiB=jwd-Lg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201212041106.50645.jhb>