From owner-freebsd-mips@FreeBSD.ORG Mon Jun 21 20:25:33 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 6DABC1065670 for ; Mon, 21 Jun 2010 20:25:33 +0000 (UTC) (envelope-from freebsd@luftivennad.com) Received: from fiona.equix.ee (fiona.equix.ee [188.92.161.31]) by mx1.freebsd.org (Postfix) with ESMTP id DD2128FC08 for ; Mon, 21 Jun 2010 20:25:32 +0000 (UTC) Received: by fiona.equix.ee (Postfix, from userid 2500) id AE4F426F94C; Mon, 21 Jun 2010 23:27:07 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.equix.ee X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL autolearn=disabled version=3.2.5 Received: from webmail.equix.ee (localhost [188.92.161.31]) by fiona.equix.ee (Postfix) with ESMTP id 6818D26F946; Mon, 21 Jun 2010 23:27:01 +0300 (EEST) Received: from 62.65.217.102.cable.starman.ee ([62.65.217.102]) (SquirrelMail authenticated user zwoz) by webmail.equix.ee with HTTP; Mon, 21 Jun 2010 23:27:01 +0300 Message-ID: In-Reply-To: <20100621.132042.200754750200159567.imp@bsdimp.com> References: <3f993635fc9c54a4d44aa360e26a9be0.squirrel@webmail.equix.ee> <20100621.102045.634347869559339674.imp@bsdimp.com> <3edb8319ac94c39f912d9c7e8f09aeff.squirrel@webmail.equix.ee> <20100621.132042.200754750200159567.imp@bsdimp.com> Date: Mon, 21 Jun 2010 23:27:01 +0300 From: "Ain Tepp" To: "M. Warner Losh" User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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 20:25:33 -0000 > In message: <3edb8319ac94c39f912d9c7e8f09aeff.squirrel@webmail.equix.ee> > "Ain Tepp" writes: > : Hi, > : > : Seems like enabling interface (like ifconfig ath0 up) causes trap. Other > : operations, like setting operational mode works fine. > : If i use "ifconfig ath0 up" i get trap for current ifconfig process pid. > : If i use > : # ifconfig wlan0 up > : > : I get all time pid 0 trap: > : > : Trap cause = 7 (bus error (load or store) - kernel mode) > : [ thread pid 0 tid 100028 ] > : Stopped at platform_start+0x1b10: srl v0,a1,8 > : db> bt > : Tracing pid 0 tid 100028 td 0xc0c7b000 > : db_trace_thread+30 (?,?,?,?) ra 80055a48 sp c74657b0 sz 24 > : 8005592c+11c (0,?,ffffffff,?) ra 8005537c sp c74657c8 sz 32 > : 80054fe8+394 (?,?,?,?) ra 8005550c sp c74657e8 sz 168 > : db_command_loop+78 (?,?,?,?) ra 80057ca8 sp c7465890 sz 24 > : 80057ba0+108 (?,?,?,?) ra 801ace78 sp c74658a8 sz 424 > : kdb_trap+108 (?,?,?,?) ra 8037d730 sp c7465a50 sz 32 > : trap+1620 (?,?,?,?) ra 803733e0 sp c7465a70 sz 176 > : MipsKernGenException+134 (0,deadc0de,a258,c7465c74) ra 80391428 sp > : c7465b20 sz0 > : 80391420+8 (?,?,?,?) ra 0 sp c7465be8 sz 0 > > which routine is this? This is going over my head :( (And in my timezone time is over 11) Can You rephrase Your question (and if needed, with simple command examples :)) Ain > Warner > > : pid 0 > : db> > : > : > : Wbr, > : > : Ain > : > : > 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 > : > > : > : > : >