Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() && irqs_disabled()

[Jody McIntyre <scjody@modernduck.com>]

On Fri, Feb 11, 2005 at 10:35:33AM -0500, Dan Dennedy wrote:

> I am testing this patch in the same manner as you: exiting Kino capture.
> I am getting a similar error in a different location. Can you look into
> it, please?
> 
> Debug: sleeping function called from invalid context at mm/slab.c:2082
> in_atomic():1, irqs_disabled():1
>  [<c0119eb1>] __might_sleep+0xa1/0xc0
>  [<c0144914>] kmem_cache_alloc+0x64/0x80
>  [<c037f07b>] dma_pool_create+0x7b/0x190
>  [<e09ede32>] alloc_dma_rcv_ctx+0x1a2/0x400 [ohci1394]
>  [<e09eb239>] ohci_devctl+0x3d9/0x640 [ohci1394]
>  [<e0bc5d4e>] handle_iso_listen+0xee/0x160 [raw1394]
>  [<e0bc878e>] state_connected+0x2de/0x2f0 [raw1394]
>  [<e0bc884e>] raw1394_write+0xae/0xe0 [raw1394]
>  [<c015c80c>] vfs_write+0x14c/0x160
>  [<c015c8f1>] sys_write+0x51/0x80
>  [<c0102a39>] sysenter_past_esp+0x52/0x75

Does this happen on exit or on startup?  Looks like allocation problems,
which will be harder to fix, since you can't return to userland until
the allocation is complete.  AFAICT the correct fix is to use
finer-grained locks, hold them for less time, and not use _irq or
_irqsave unless necessary.  host_info_lock, in particular, is held for
far too long.

Jody

> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> mailing list linux1394-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux1394-devel

--