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 <jri...@gmail.com> 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=<value optimized out>, dummy2=0,
> dummy3=0, dummy4=0x0)
>     at /root/ATH/head/sys/ddb/db_command.c:543
> #2  0xffffffff802fafda in db_command (last_cmdp=<value optimized out>,
> cmd_table=<value optimized out>, 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=<value optimized out>, code=0) at
> /root/ATH/head/sys/ddb/db_main.c:231
> #5  0xffffffff8056e4e3 in kdb_trap (type=3, code=0, tf=<value optimized
> 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=<value optimized out>) at cpufunc.h:63
> #9  0xffffffff805390f7 in vpanic (fmt=<value optimized out>, ap=<value
> optimized out>)
>     at /root/ATH/head/sys/kern/kern_shutdown.c:747
> #10 0xffffffff80538fa6 in kassert_panic (fmt=<value optimized out>) at
> /root/ATH/head/sys/kern/kern_shutdown.c:642
> #11 0xffffffff80524cfa in __mtx_lock_sleep (c=0xffffff800090dea8,
> tid=18446741874793984000, opts=<value optimized out>,
>     file=<value optimized out>, line=549311568) at
> /root/ATH/head/sys/kern/kern_mutex.c:394
> #12 0xffffffff8052491a in __mtx_lock_flags (c=<value optimized out>, 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=<value optimized out>)
>     at /root/ATH/head/sys/kern/subr_taskqueue.c:535
> #16 0xffffffff80508a14 in fork_exit (callout=0xffffffff8057d5e0
> <taskqueue_thread_loop>, 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
>>
>
_______________________________________________
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to