Re: bus_dmamap_destroy no longer callable from interrupt context?

[Matt Thomas <matt%3am-software.com@localhost>]

On Nov 15, 2013, at 6:22 AM, Christoph Badura <bad%bsd.de@localhost> wrote:

> While trying to port BCM586x support I discovered that I get the following
> panic under -current.  The same code works fine on -6.  What gives?
> 
> panic: kernel diagnostic assertion "((!cpu_intr_p() && !cpu_softintr_p()) || 
> (pc->pc_pool.pr_ipl != IPL_NONE || cold || panicstr != NULL)" failed: file 
> "../../../../kern/subr_pool.c", line 2209 pool 'vmmpepl' is IPL_NONE, but 
> called from interrupt context
> 
> backtrace:
> ...
> kern_assert
> pool_cache_get_paddr
> _uvm_mapent_alloc.clone.2
> uvm_map_dup_start
> uvm_unmap_remove
> uvm_unmap1
> _bus_dmamap_destroy_clone.8
> ubsec_callback+0x9d
> ubsec_intr+0x100
> intr_biglock_wrapper
> ...
> 
> This is generic ubsec code that is used by our currently supported devices.
> I.e. ubsec(4) should be completely busted.

it's intentional.  dmamap create/destroy can't be done from interrupt because 
they allocate memory.  besides mbufs, memory can't be allocated.  I don't agree 
with the softintr restriction (where else can drivers allocate).