Re: ath0: unable to attach hardware

From: <husyh_at_hush.com>
Date: Thu, 13 Dec 2012 22:11:00 +0100
Hello everyone,

I'm afraid I still don't know what exactly BAR is, or how I get its value that I'm supposed to plug into the line John provided:
dd if=/dev/mem bs=4 iseek=((start of bar + reg offset)/4) count=1 | hd

I assumed that "start of bar" is 0xfdee0000 in my case, since dmesg reports
ath0: <Atheros 5413> mem 0xfdee0000-0xfdeeffff irq 16 at device 4.0 on pci2

This is what I get:
# dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE0000+4004)/4" | bc` count=1 | hd
00 00 01 00
# dd if=/dev/mem bs=4 iseek=`echo "ibase=16; (FDEE0000+4010)/4" | bc` count=1 | hd
14 00 01 00

Please correct me if my assumption about "start of bar" was wrong and/or I made some other mistake.
Also, please don't hesitate to ask me to do anything else that might help you during debugging.

Thank you very much for the effort.

>
>On 11 December 2012 12:49, John Baldwin <jhb_at_freebsd.org> wrote:
>
>
>> Look, it's up to you to look at more registers if you want to 
>debug this
>> further.  PCI says everything is ok, so the ball is in your 
>court.
>
>Right, that's why I've asked for those two above registers.
>
>There are other things that could be wrong - eg, the device may
>actually not have reset correctly.
>
>This isn't the first time that someone's come to me with a "linux
>works, freebsd doesn't" for an AR5212 era NIC. ath5k and FreeBSD do
>the same thing at probe/attach time. I believe they do the same 
>thing
>during device power-on time too. There's some corner cases where 
>the
>chip doesn't reset right because the BIOS PCI bus reset code does
>things in a brain dead manner (eg doing two PCI bus resets back to
>back with not enough time in between for the MAC to settle.)
>
>There may be PCI code differences in how Linux and FreeBSD does 
>things
>like "reset the PCI bus."
>
>
>
>Adrian
Received on Thu Dec 13 2012 - 20:11:07 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:33 UTC