From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 27 00:29:47 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C1FCC7D7 for ; Wed, 27 Mar 2013 00:29:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7B515E for ; Wed, 27 Mar 2013 00:29:47 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hi18so1733314wib.15 for ; Tue, 26 Mar 2013 17:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XzRRWZuSjCV8v+FTj49HUqzjZJBXCRB9gAk3+1OFHes=; b=yvGGtSyp9FgQCiw0+mMxeD4ZWb3VLvR8OEY96qHGwN1m4UNVmI0SbillUDJdXYnixb cTCfe2iwqZxZMIYxPxgqCqXiXD2Mw4WcFV4w6aQ8AYUY+gA4TawlcLyhb27wnLqcB4j2 ZvDujMMcnmIhy3UFTPcHf5WMq8iYZzr3+5PUPvvtVVX8mNMkrY8TZqFhLp/Y6Nnz/nqf qes5R98vK7mFtKE6l2R+1szSgstrqKopvogVGJJ3cqKMKIx1oIAi4nn0fUZert1Wi4PJ 8LtDcI+S+R3HmWy5Z6g++UsA+BAMY9KPM3p7jdJD0BKEkKIGFVPc10x6+XrZ7zwpWd0F aDug== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr28053422wjb.24.1364344185657; Tue, 26 Mar 2013 17:29:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Tue, 26 Mar 2013 17:29:45 -0700 (PDT) In-Reply-To: <51523B6F.5010506@gmail.com> References: <51522277.6040107@gmail.com> <51523B6F.5010506@gmail.com> Date: Tue, 26 Mar 2013 17:29:45 -0700 X-Google-Sender-Auth: r4Zki_VV1onYzVlb-HFGwP4kV4M Message-ID: Subject: Re: [wip] ar9300 hostap support From: Adrian Chadd To: Joshua Isom Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 00:29:47 -0000 it's the same underlying problem as before. I just screwed up the locking. Lemme fix that. Adrian On 26 March 2013 17:21, Joshua Isom wrote: > Another panic, but a different cause. I think I'd seen it once before but > I'm not sure. > > Unread portion of the kernel message buffer: > > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ath0: ath_edma_tx_processq: Q1: empty? > panic: _mtx_lock_sleep: recursed on non-recursive mutex ath0_txq1 @ > /root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c:667 > > cpuid = 1 > KDB: enter: panic > > [...] > > (kgdb) bt > #0 doadump (textdump=0) at pcpu.h:229 > #1 0xffffffff802fb52e in db_dump (dummy=, dummy2=0, > dummy3=0, dummy4=0x0) > at /root/ATH/head/sys/ddb/db_command.c:543 > #2 0xffffffff802fafda in db_command (last_cmdp=, > cmd_table=, dopager=1) > at /root/ATH/head/sys/ddb/db_command.c:449 > #3 0xffffffff802fad92 in db_command_loop () at > /root/ATH/head/sys/ddb/db_command.c:502 > #4 0xffffffff802fd740 in db_trap (type=, code=0) at > /root/ATH/head/sys/ddb/db_main.c:231 > #5 0xffffffff8056e4e3 in kdb_trap (type=3, code=0, tf= out>) at /root/ATH/head/sys/kern/subr_kdb.c:654 > #6 0xffffffff807d5368 in trap (frame=0xffffff8020bdd7d0) at > /root/ATH/head/sys/amd64/amd64/trap.c:579 > #7 0xffffffff807be232 in calltrap () at exception.S:228 > #8 0xffffffff8056dcce in kdb_enter (why=0xffffffff808abd45 "panic", > msg=) at cpufunc.h:63 > #9 0xffffffff805390f7 in vpanic (fmt=, ap= optimized out>) > at /root/ATH/head/sys/kern/kern_shutdown.c:747 > #10 0xffffffff80538fa6 in kassert_panic (fmt=) at > /root/ATH/head/sys/kern/kern_shutdown.c:642 > #11 0xffffffff80524cfa in __mtx_lock_sleep (c=0xffffff800090dea8, > tid=18446741874793984000, opts=, > file=, line=549311568) at > /root/ATH/head/sys/kern/kern_mutex.c:394 > #12 0xffffffff8052491a in __mtx_lock_flags (c=, opts=0, > file=0xffffffff813f2dcf > "/root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c", line=667) > at /root/ATH/head/sys/kern/kern_mutex.c:224 > #13 0xffffffff81335467 in ath_edma_tx_processq (sc=0xffffff800090d000, > dosched=1) > at /root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c:667 > #14 0xffffffff8057cea0 in taskqueue_run_locked (queue=0xfffffe0006488500) at > /root/ATH/head/sys/kern/subr_taskqueue.c:333 > #15 0xffffffff8057d67b in taskqueue_thread_loop (arg=) > at /root/ATH/head/sys/kern/subr_taskqueue.c:535 > #16 0xffffffff80508a14 in fork_exit (callout=0xffffffff8057d5e0 > , arg=0xffffff800090d810, > frame=0xffffff8020bddc00) at /root/ATH/head/sys/kern/kern_fork.c:991 > #17 0xffffffff807be76e in fork_trampoline () at exception.S:602 > #18 0x0000000000000000 in ?? () > > > > On 3/26/2013 7:11 PM, Adrian Chadd wrote: >> >> >> Hah, that's nice to know. >> >> Please let me know if you see any further issues here. >> >> I have another tweak to add in soon in the TX completion code; I just >> noticed a very subtle difference between what my code does and what >> the reference code does. >> >> Thanks, >> >> >> >> Adrian >> >