From owner-freebsd-current@FreeBSD.ORG Tue Dec 4 18:42:59 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 A40C448C; Tue, 4 Dec 2012 18:42:59 +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 75F5D8FC17; Tue, 4 Dec 2012 18:42:59 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C11C6B915; Tue, 4 Dec 2012 13:42:58 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: ath0: unable to attach hardware Date: Tue, 4 Dec 2012 11:06:50 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <20121123213551.C2CB9E6739@smtp.hushmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212041106.50645.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 04 Dec 2012 13:42:58 -0500 (EST) Cc: husyh@hush.com, 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: Tue, 04 Dec 2012 18:42:59 -0000 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