On Sat, Feb 19, 2005 at 11:36:05AM -0800, David Brownell wrote:
>
> Those allocations could be from _using_ a dma pool ... but they're
> not from just creating one!
>
> The cost of creating the dma_pool is the cost of one small kmalloc()
> plus (the expensive part) the /sys/devices/.../pools sysf
On Saturday 19 February 2005 12:50 pm, Parag Warudkar wrote:
> On Saturday 19 February 2005 02:36 pm, David Brownell wrote:
> > The cost of creating the dma_pool is the cost of one small kmalloc()
> > plus (the expensive part) the /sys/devices/.../pools sysfs attribute
> > is created along with the
On Saturday 19 February 2005 02:36 pm, David Brownell wrote:
> The cost of creating the dma_pool is the cost of one small kmalloc()
> plus (the expensive part) the /sys/devices/.../pools sysfs attribute
> is created along with the first pool. (Use that instead of slabinfo
> for those pool allocati
> > Jody - Is the 200K waste for sure or do you want me to verify it by some
> > means? ( Reason I am asking is firstly, Dave Brownell was quite sure it
> > wasn't that costly and secondly, I am hoping it isn't.. ;)
>
> I'm not sure, but I looked through the code and it seems to allocate:
> -
On Saturday 19 February 2005 01:36 am, Jody McIntyre wrote:
> I disagree because the impact of this bug is small. How often do you start
> an ISO receive? If you think it needs to be fixed urgently, please
> explain why - maybe I'm just missing somethnig.
>
I have to agree that the impact is sma
On Fri, Feb 18, 2005 at 10:42:46AM -0500, Parag Warudkar wrote:
> On Friday 18 February 2005 10:32 am, Dan Dennedy wrote:
> > I have tested the patches (including for allocation), and it is working
> > great, but should I only commit for now the deallocation patch? Hmm..
> > which is worse the debu
On Friday 18 February 2005 10:32 am, Dan Dennedy wrote:
> I have tested the patches (including for allocation), and it is working
> great, but should I only commit for now the deallocation patch? Hmm..
> which is worse the debug or the 200K waste?
Thanks for following it up.
IMHO, we should commit
I have tested the patches (including for allocation), and it is working
great, but should I only commit for now the deallocation patch? Hmm..
which is worse the debug or the 200K waste?
On Fri, 2005-02-11 at 22:54 -0500, Parag Warudkar wrote:
> Jody,
> This happens every time you connect a device
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 - Th
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:208
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 a
Forgot to attach ohci.h diff which is affected by this change as well.
Meanwhile, David Brownell suggested it would be much simpler to move the
dma allocations to _probe and deallocations to _remove.
I am working on it and so far haven't got it to work.
Andrew - What do you think? If you too fee
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
Parag Warudkar <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
>
> ...
> >- We'll need a flush_workqueue() in the teardown function for that data
> > structure to ensure that any pending callbacks have completed before we
> > free the storage.
> >
> >
> By saying flush_workqueue did you in
Andrew Morton wrote:
yup. But what happens if someone removes the module while
ohci_free_dma_work_fn() is still pending?
Suggestions:
- The work_struct cannot be on the stack. The code as you have it will
read gunk from the stack when the delayed work executes. The work_struct
needs to be plac
Parag Warudkar <[EMAIL PROTECTED]> wrote:
>
> Problem - ohci1394.c:ohci_devctl ends up calling dma_pool_destroy from
> invalid context. Below is the dmesg output when I exit Kino after video
> capture -
>
> Debug: sleeping function called from invalid context at
> include/asm/semaphore.h:107
>
Problem - ohci1394.c:ohci_devctl ends up calling dma_pool_destroy from
invalid context. Below is the dmesg output when I exit Kino after video
capture -
Debug: sleeping function called from invalid context at
include/asm/semaphore.h:107
in_atomic():1, irqs_disabled():1
[] dump_stack+0x1e/0x20
[
17 matches
Mail list logo
