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
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
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
> > 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:
> -
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:
- 16
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
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 first
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 sysfs
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
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
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
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
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
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 debug or
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 -
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
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
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,
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
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 -
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
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
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
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
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
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
[c0104c2e]
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 intend to suggest
29 matches
Mail list logo
