Date: Thu, 13 Dec 2012 22:11:00 +0100 From: husyh@hush.com To: "Adrian Chadd" <adrian@freebsd.org>, "John Baldwin" <jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: ath0: unable to attach hardware Message-ID: <20121213211100.5395F10E2C8@smtp.hushmail.com> In-Reply-To: <CAJ-VmonvJ4M5aJC9Mm5g%2B06Gfe=aoTg_p0NStj6gZtjkJ77Btw@mail.gmail.com> References: <20121123213551.C2CB9E6739@smtp.hushmail.com> <201212101437.54825.jhb@freebsd.org> <CAJ-VmomM965-=QByhJZMPUn_PZAnSjafcm3cy3ojRaPc5fbWPg@mail.gmail.com> <201212111549.49942.jhb@freebsd.org><CAJ-VmonvJ4M5aJC9Mm5g%2B06Gfe=aoTg_p0NStj6gZtjkJ77Btw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121213211100.5395F10E2C8>