From owner-freebsd-mips@FreeBSD.ORG Mon Jun 21 16:23:02 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E182106566B for ; Mon, 21 Jun 2010 16:23:02 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A69378FC14 for ; Mon, 21 Jun 2010 16:23:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o5LGKcol034068; Mon, 21 Jun 2010 10:20:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 21 Jun 2010 10:20:45 -0600 (MDT) Message-Id: <20100621.102045.634347869559339674.imp@bsdimp.com> To: freebsd@luftivennad.com From: "M. Warner Losh" In-Reply-To: <3f993635fc9c54a4d44aa360e26a9be0.squirrel@webmail.equix.ee> References: <3f993635fc9c54a4d44aa360e26a9be0.squirrel@webmail.equix.ee> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-mips@freebsd.org Subject: Re: AR5416 MAC based ath X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 16:23:02 -0000 In message: <3f993635fc9c54a4d44aa360e26a9be0.squirrel@webmail.equix.ee> "Ain" writes: : Hello! : : Last month was here a discussion about AR92XX (with subject line "Trap : when setting up ath0"). Now i have same kind trap, my chip is ar9220. If i : understand correctly, patch for 71xx : (http://people.freebsd.org/~imp/ar71xx_ath_war.diff) contains magic number : AR_RXCFG, what is not defined in ar5416reg.h. Can i use same magic to get : my AR92XX working? If not, maybe some other ideas? The RXCFG bug is reported to only be with the older chipset. Atheros didn't fix that bug in the current generation of processors. The newer, N chipsets don't have this bug. If you're seeing issues, then chances are very good that it is a different problem. My work around likely won't help you much. I'd start by building a kernel with symbols and using the debugger to help you track down the issue. With the WAR I put in, I'd always get a different trap address. Maybe this is something as simple as a driver bug (deref of NULL, say).... Warner