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 [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/linux1394-devel > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
