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

[Parag Warudkar <kernel-stuff@comcast.net>]

Jody,
This happens every time you connect a device which ends up doing
ISO_LISTEN_CHANNEL. We fixed the device disconnect case in -mm recently.

I had sent you and Andrew an alternative patch which fixes this
dma_pool_create case as well as the dma_pool_destroy case, albeit with a
disadvantage - The patch does pre-allocation of the IR Legacy DMA in
_pci_probe and deallocates it in _pci_remove. However I am not truly
happy with it since it possibly wastes 200K of memory for people who
don't have devices which need it.

As I said earlier, I think the way to fix this is via schedule_work
similar to the disconnect case, but it involves good amount of code
change. I am working on it - any better ideas most welcome.

Dan - Can you try the attached patch - on top current -mm1? (It's pretty
no brainer that it will fix both cases but two testing heads are better
than one.. :)

Thanks

Parag

On Fri, 2005-02-11 at 13:43 -0500, Jody McIntyre wrote:
> 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
>