Re: ath0: unable to attach hardware

Hello,

thank you for your answer.

Unfortunately, I'm unexperienced with FreeBSD, and am absolutely unfamiliar with hardware specifics. During this mail conversion, I have heard abour BAR for the first time, and therefore, I know neither what exactly I should do (e.g. how I can find the start of bar, which register offsets would be interesting, etc.), nor what the results would tell me.

I'm sorry if I'm tedious, but I would be very grateful if you could provide some more guidance.

Thank you very much!

On Dienstag, 4. Dezember 2012 at 7:43 PM, "John Baldwin" <jhb_at_freebsd.org> wrote:
>
>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