On Sun, 2005-01-30 at 20:19 -0500, Parag Warudkar wrote: > Attached is the reworked patch to take care of Andrew's suggestions - > > 1) Allocate the work struct dynamically in struct ti_ohci during device > probe, free it during device remove > 2) In ohci1394_pci_remove, ensure queued work, if any, is flushed before > the device is removed (As I understand, this should work for both device > removal cases as well as module removal - correct?) > 3) Rework the free_dma_rcv_ctx - It is called in multiple contexts by > different callers - teach it to free the dma according to caller's wish > - either direct free where caller determines the context is safe to > sleep OR delayed via schedule_work when caller wants to call it from a > context where it cannot sleep. So it now takes 2 extra arguments - > method to free - direct or delayed and if it is to be freed delayed, an > appropriate work_struct. > > Andrew - flush_scheduled_work does not touch work which isn't shceduled > - so I don't think INIT_WORK in setup is necessary. Let me know if I am > missing something here. (I tried INIT_WORK in ochi1394_pci_probe and > putting flush_scheduled_work in ohci1394_pci_remove - It did not result > in calling the work function after I did rmmod, since it wasn't scheduled.) >
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 - 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/
