From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 19:38:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40B4438B; Mon, 10 Dec 2012 19:38:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 114E48FC12; Mon, 10 Dec 2012 19:38:05 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3463EB95D; Mon, 10 Dec 2012 14:38:04 -0500 (EST) From: John Baldwin To: husyh@hush.com Subject: Re: ath0: unable to attach hardware Date: Mon, 10 Dec 2012 14:37:54 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20121123213551.C2CB9E6739@smtp.hushmail.com> <201212041106.50645.jhb@freebsd.org> <20121207095937.ECB38E6726@smtp.hushmail.com> In-Reply-To: <20121207095937.ECB38E6726@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201212101437.54825.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 10 Dec 2012 14:38:04 -0500 (EST) Cc: Adrian Chadd , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 19:38:05 -0000 On Friday, December 07, 2012 4:59:37 am husyh@hush.com wrote: > 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! Adrian should be able to do that for you. He knows which registers he wants to see. > On Dienstag, 4. Dezember 2012 at 7:43 PM, "John Baldwin" 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 > > -- John Baldwin