Re: ath0: unable to attach hardware

Hi,

I'm CC'ing jhb_at_ (who is likely busy after Hurricane Sandy..) who
spends time in the PCI bridge code.

That looks correct (ie, the BAR(0) entry matches your dmesg entry.)

The 0xffffffff register response however means that it isn't mapped
into that particular region correctly. An asleep NIC will return
0xdeadbeef, 0xdeadc0de, etc.
It doesn't return 0xffffffff for registers (well, except for AR_ISR,
but that isn't being probed at this point.)

Did you post a boot -v to -current, showing what all the PCI bridges
are? I'd like to ensure that they're all setup right. Unfortunately I
don't have time to try and figure out what's going on with the PCI
bridge and resource allocation side of things.

John - I think this is a PCI-PCI bridge resource allocation / setup
problem. The BAR(0) for the NIC matches what the probe/attach line for
ath0 says. but the register value of 0xffffffff to me indicates the
NIC isn't mapped into that space correctly. The internal PCI glue in
the NIC will return 0xdeadbeef, 0xdeadc0de, etc as register contents
if the device is asleep and hasn't been woken up or reset correctly.
It won't return 0xffffffff.

I would really appreciate any help you or others can provide on this.

Thanks,



Adrian

On 9 November 2012 15:25,  <husyh_at_hush.com> wrote:
> Hello,
>
> thank you for your reply.
>
> I've entered the following
> pciconf -r ath0_at_pci0:2:4:0 0:255
> and received this output:
>
> 001b168c 02900406 02000001 00002008
> fdee0000 00000000 00000000 00000000
> 00000000 00000000 00005001 500111ad
> 00000000 00000044 00000000 1c0a0110
> 00000000 01c20001 c6004000 00000000
> 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000
>
> I hope this helps you out. If not, please let me know what else I can do.
>
> Thanks!
>
> On Freitag, 9. November 2012 at 5:45 PM, "Adrian Chadd" <adrian_at_freebsd.org> wrote:
>>
>>Can you use pciconf to dump the config space?
>>
>>I think its pciconf -r <ath pci device string> 0:255
>>
>>thanks!
>>
>>
>>
>>adrian
>>
>>On 9 November 2012 01:57,  <husyh_at_hush.com> wrote:
>>> Hello again,
>>>
>>> the mail I'm replying to (and which is cited below) hasn't
>>caused a reaction yet. Seeing that this mailing list has quite a
>>lot of traffic, I'm worried that the mail, and the issue it tries
>>to point out, will be forgotten.
>>> Should I file a bug report in hopes that the issue will somewhen
>>be investigated/resolved?
>>>
>>> Again, I'm offering any kind of help I'm able to provide, i.e.
>>delivering more information upon (hopefully detailed enough for me
>>to understand) request, testing proposed fixes and doing some
>>progamming on my own; for the latter, please keep in mind that I
>>have no experience with the FreeBSD codebase or hardware
>>programming.
>>>
>>> Thanks!
>>>
>>> On Samstag, 3. November 2012 at 11:43 AM, husyh_at_hush.com wrote:
>>>>
>>>>Hello everyone,
>>>>
>>>>I'm new to FreeBSD and wanted to install 9.0-RELEASE amd64 on a
>>PC
>>>>I was given. At first glance, it seems like everything is
>>working,
>>>>except the wireless LAN PCI card.
>>>>
>>>>I started a thread on freebsd-wireless on the 31st of October
>>(see
>>>>here: http://lists.freebsd.org/pipermail/freebsd-wireless/2012-
>>>>October/002511.html or a repost of my original message with
>>proper
>>>>formatting: http://lists.freebsd.org/pipermail/freebsd-
>>>>wireless/2012-October/002513.html )
>>>>
>>>>Short summary:
>>>>The card has the strings "Anatel", "WN5301A-H1-V02" and
>>>>"KN160562*7" printed on it, although I'm not sure which, if any,
>>>>of those is a proper product number.
>>>>After setting
>>>>
>>>>hw.ath.debug=1
>>>>hw.ath.hal.debug=1
>>>>
>>>>I receive
>>>>
>>>>ath0: <Atheros 5413> mem 0xfdee0000-0xfdeeffff irq 16 at device
>>>>4.0 on pci2
>>>>ar5212ChipTest: address test failed addr: 0x00008000 -
>>>>wr:0x00000000 != rd:0xffffffff
>>>>ar5212Attach: hardware self-test failed
>>>>ath0: unable to attach hardware; HAL status 14
>>>>device_attach: ath0 attach returned 6
>>>>
>>>>and am left unable to use the device.
>>>>I tried 8.3-RELEASE i386 as well as 10.0-CURRENT amd64 and i386
>>>>snapshots from https://snapshots.glenbarber.us/Latest/
>>(seemlingly
>>>>built a few days ago) and received the same messages, although I
>>>>did not get the debug messages since I booted off of the
>>>>installation media and therefore had a stock kernel, which
>>>>seemingly doesn't enable ATH_DEBUG and AH_DEBUG. Booting the
>>>>Ubuntu 12.04 amd64 installation media, I can use the NIC without
>>>>having any problems.
>>>>
>>>>Adrian Chadd tried to help me via freebsd-wireless (thank you
>>>>again,) but ultimately asked me this:
>>>>"Please try a recent -HEAD i386 and amd64 snapshot and if that
>>>>doesn't
>>>>work, you could try posting for help on freebsd-current. But
>>please
>>>>stress that I think it's a bus enumeration and PCI bridge
>>>>programming
>>>>problem, _not_ a driver problem."
>>>>
>>>>And so I did.
>>>>
>>>>I'd be very glad if you could try to help me. Of course, I'm
>>>>willing to provide any kind of information you might need, but
>>>>please keep in mind that I'm new to FreeBSD and therefore would
>>be
>>>>thankful if you stated your instructions/requests in a newbie-
>>>>friendly way.
>>>>
>>>>Thank you.
>>>>
>>>>_______________________________________________
>>>>freebsd-current_at_freebsd.org mailing list
>>>>http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>>To unsubscribe, send any mail to "freebsd-current-
>>>>unsubscribe_at_freebsd.org"
>>>
>>> _______________________________________________
>>> freebsd-current_at_freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-
>>unsubscribe_at_freebsd.org"
>