Date: Mon, 6 Jan 2020 09:40:08 -0500 From: Mark Johnston <markj@freebsd.org> To: Rajesh Kumar <rajfbsd@gmail.com> Cc: freebsd-drivers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: panic: smp_targeted_tlb_shootdown: interrupts disabled - FreeBSD 12.0 Message-ID: <20200106144008.GA23672@spy> In-Reply-To: <CAAO%2BANN9VR9oXhhHjZ7zipLkDQTpjvawTqDtwJmMioY0bH=z5g@mail.gmail.com> References: <CAAO%2BANN9VR9oXhhHjZ7zipLkDQTpjvawTqDtwJmMioY0bH=z5g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 02, 2020 at 11:17:10PM +0530, Rajesh Kumar wrote: > Hi, > > I am hitting the below panic when I am testing couple of my drivers. When i > looked at the source, the reason is PSL_I bit (Interrupt enabled) bit is > not set when read in "smp_targeted_tlb_shootdown" routine. But I am > wondering what leads to this. > > *Driver test scenario:* > 1. Driver has a kernel thread, which allocates memory and dma maps it and > send the dma addr to Driver 2. Then wait (msleep) till it gets a > notification from Driver 2. > 2. Driver 2 has a kernel thread which will submit the received address from > Driver1 to hardware and wait (msleep) for an interrupt > 3. Driver 2 receives a interrupt and wakes up the thread (wakeup_one) in > Driver2. Thread in Driver 2 then notifies Driver1 through a callback. > 4. Callback in Driver 1 wakeup (wakeup_one) it's sleeping kernel thread. > The kernel thread then dma unmap the buffer the frees the memory > > Kernel Panics while the memory is freed at last. I am sure this is a > driver, but not sure what am I doing wrong here. Please help. Does your driver hold a spin mutex when it calls kmem_free()? If so, that is causing your problem: interrupts are disabled while a spin mutex is held. Most kernel interfaces do not expect to be called with a spin mutex held and will misbehave in this case. > panic: smp_targeted_tlb_shootdown: interrupts disabled > cpuid = 44 > time = 1577463701 > KDB: stack backtrace: > #0 0xffffffff80be7977 at kdb_backtrace+0x67 > #1 0xffffffff80b9b563 at vpanic+0x1a3 > #2 0xffffffff80b9b3b3 at panic+0x43 > #3 0xffffffff811eea8f at smp_targeted_tlb_shootdown+0x40f > #4 0xffffffff811eeb22 at smp_masked_invlpg_range+0x42 > #5 0xffffffff8105e67c at pmap_invalidate_range+0x25c > #6 0xffffffff81061cdd at pmap_remove_ptes+0x6d > #7 0xffffffff8106079b at pmap_remove+0x35b > #8 0xffffffff80ee0366 at _kmem_unback+0x36 > #9 0xffffffff80ee04cd at kmem_free+0x2d > #10 0xffffffff829fc5f8 at driver_thread_work+0x798 > #11 0xffffffff80bf9cb4 at taskqueue_run_locked+0x154 > #12 0xffffffff80bfae18 at taskqueue_thread_loop+0x98 > #13 0xffffffff80b5bf33 at fork_exit+0x83 > #14 0xffffffff810501be at fork_trampoline+0xe > > Please let me know if any details needed. > > Thanks, > Rajesh. > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200106144008.GA23672>