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-unsubscr...@freebsd.org"
_______________________________________________
freebsd-amd64@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"

Reply via email to