On 29.01.2013 12:02, Andrew Lunn wrote:
Now I activated the debug messages in em28xx. From the messages I
see no correlation of the pool exhaustion and lost sync. Also I
cannot see any error messages from the em28xx driver.
I see a lot of init_isoc/stop_urbs (maybe EPG scan?) without
draining
> Now I activated the debug messages in em28xx. From the messages I
> see no correlation of the pool exhaustion and lost sync. Also I
> cannot see any error messages from the em28xx driver.
> I see a lot of init_isoc/stop_urbs (maybe EPG scan?) without
> draining the coherent pool (checked with
Now I activated the debug messages in em28xx. From the messages I
see no correlation of the pool exhaustion and lost sync. Also I
cannot see any error messages from the em28xx driver.
I see a lot of init_isoc/stop_urbs (maybe EPG scan?) without
draining the coherent pool (checked with 'cat
On 29.01.2013 12:02, Andrew Lunn wrote:
Now I activated the debug messages in em28xx. From the messages I
see no correlation of the pool exhaustion and lost sync. Also I
cannot see any error messages from the em28xx driver.
I see a lot of init_isoc/stop_urbs (maybe EPG scan?) without
draining
On Mon, Jan 28, 2013 at 09:59:18PM +0100, Soeren Moch wrote:
> On 23.01.2013 19:10, Andrew Lunn wrote:
>
> >>>
> >>>Now (in the last hour) stable, occasionally lower numbers:
> >>>3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >>>3396 3396 3396 3396 3396 3396 3396
On 23.01.2013 19:10, Andrew Lunn wrote:
Now (in the last hour) stable, occasionally lower numbers:
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
On 23.01.2013 19:10, Andrew Lunn wrote:
Now (in the last hour) stable, occasionally lower numbers:
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
On Mon, Jan 28, 2013 at 09:59:18PM +0100, Soeren Moch wrote:
On 23.01.2013 19:10, Andrew Lunn wrote:
Now (in the last hour) stable, occasionally lower numbers:
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >>
> >
> >Now (in the last hour) stable, occasionally lower numbers:
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396
On 23.01.2013 18:07, Soeren Moch wrote:
On 23.01.2013 17:25, Andrew Lunn wrote:
On Wed, Jan 23, 2013 at 04:30:53PM +0100, Soeren Moch wrote:
On 19.01.2013 19:59, Andrew Lunn wrote:
Please find attached a debug log generated with your patch.
I used the sata disk and two em28xx dvb sticks, no
On 23.01.2013 17:25, Andrew Lunn wrote:
On Wed, Jan 23, 2013 at 04:30:53PM +0100, Soeren Moch wrote:
On 19.01.2013 19:59, Andrew Lunn wrote:
Please find attached a debug log generated with your patch.
I used the sata disk and two em28xx dvb sticks, no other usb devices,
no ethernet cable
On Wed, Jan 23, 2013 at 04:30:53PM +0100, Soeren Moch wrote:
> On 19.01.2013 19:59, Andrew Lunn wrote:
> >>Please find attached a debug log generated with your patch.
> >>
> >>I used the sata disk and two em28xx dvb sticks, no other usb devices,
> >>no ethernet cable connected, tuners on
On 19.01.2013 19:59, Andrew Lunn wrote:
Please find attached a debug log generated with your patch.
I used the sata disk and two em28xx dvb sticks, no other usb devices,
no ethernet cable connected, tuners on saa716x-based card not used.
What I can see in the log: a lot of coherent mappings
On 22.01.2013 19:13, Arnd Bergmann wrote:
On Monday 21 January 2013, Greg KH wrote:
I don't know a lot about USB, but I always assumed that this was not
a normal condition and that there are only a couple of URBs per endpoint
used at a time. Maybe Greg or someone else with a USB background can
On 22.01.2013 19:13, Arnd Bergmann wrote:
On Monday 21 January 2013, Greg KH wrote:
I don't know a lot about USB, but I always assumed that this was not
a normal condition and that there are only a couple of URBs per endpoint
used at a time. Maybe Greg or someone else with a USB background can
On 19.01.2013 19:59, Andrew Lunn wrote:
Please find attached a debug log generated with your patch.
I used the sata disk and two em28xx dvb sticks, no other usb devices,
no ethernet cable connected, tuners on saa716x-based card not used.
What I can see in the log: a lot of coherent mappings
On Wed, Jan 23, 2013 at 04:30:53PM +0100, Soeren Moch wrote:
On 19.01.2013 19:59, Andrew Lunn wrote:
Please find attached a debug log generated with your patch.
I used the sata disk and two em28xx dvb sticks, no other usb devices,
no ethernet cable connected, tuners on saa716x-based card not
On 23.01.2013 17:25, Andrew Lunn wrote:
On Wed, Jan 23, 2013 at 04:30:53PM +0100, Soeren Moch wrote:
On 19.01.2013 19:59, Andrew Lunn wrote:
Please find attached a debug log generated with your patch.
I used the sata disk and two em28xx dvb sticks, no other usb devices,
no ethernet cable
On 23.01.2013 18:07, Soeren Moch wrote:
On 23.01.2013 17:25, Andrew Lunn wrote:
On Wed, Jan 23, 2013 at 04:30:53PM +0100, Soeren Moch wrote:
On 19.01.2013 19:59, Andrew Lunn wrote:
Please find attached a debug log generated with your patch.
I used the sata disk and two em28xx dvb sticks, no
Now (in the last hour) stable, occasionally lower numbers:
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
3396 3396 3396 3396
On Monday 21 January 2013, Greg KH wrote:
> >
> > I don't know a lot about USB, but I always assumed that this was not
> > a normal condition and that there are only a couple of URBs per endpoint
> > used at a time. Maybe Greg or someone else with a USB background can
> > shed some light on this.
On Monday 21 January 2013, Greg KH wrote:
I don't know a lot about USB, but I always assumed that this was not
a normal condition and that there are only a couple of URBs per endpoint
used at a time. Maybe Greg or someone else with a USB background can
shed some light on this.
On Mon, Jan 21, 2013 at 06:55:25PM +, Arnd Bergmann wrote:
> On Monday 21 January 2013, Soeren Moch wrote:
> > On 01/19/13 21:05, Arnd Bergmann wrote:
> > > from the distribution of the numbers, it seems that there is exactly 1 MB
> > > of data allocated between bus addresses 0x1f9 and
On Monday 21 January 2013, Soeren Moch wrote:
> On 01/19/13 21:05, Arnd Bergmann wrote:
> > from the distribution of the numbers, it seems that there is exactly 1 MB
> > of data allocated between bus addresses 0x1f9 and 0x1f9, allocated
> > in individual pages. This matches the size of
On 01/19/13 21:05, Arnd Bergmann wrote:
I found at least one source line that incorrectly uses an atomic
allocation, in ehci_mem_init():
dma_alloc_coherent (ehci_to_hcd(ehci)->self.controller,
ehci->periodic_size * sizeof(__le32),
On 01/19/13 21:05, Arnd Bergmann wrote:
I found at least one source line that incorrectly uses an atomic
allocation, in ehci_mem_init():
dma_alloc_coherent (ehci_to_hcd(ehci)-self.controller,
ehci-periodic_size * sizeof(__le32),
On Monday 21 January 2013, Soeren Moch wrote:
On 01/19/13 21:05, Arnd Bergmann wrote:
from the distribution of the numbers, it seems that there is exactly 1 MB
of data allocated between bus addresses 0x1f9 and 0x1f9, allocated
in individual pages. This matches the size of your pool,
On Mon, Jan 21, 2013 at 06:55:25PM +, Arnd Bergmann wrote:
On Monday 21 January 2013, Soeren Moch wrote:
On 01/19/13 21:05, Arnd Bergmann wrote:
from the distribution of the numbers, it seems that there is exactly 1 MB
of data allocated between bus addresses 0x1f9 and 0x1f9,
On Saturday 19 January 2013, Soeren Moch wrote:
> What I can see in the log: a lot of coherent mappings from sata_mv and
> orion_ehci, a few from mv643xx_eth, no other coherent mappings.
> All coherent mappings are page aligned, some of them (from orion_ehci)
> are not really small (as claimed in
> Please find attached a debug log generated with your patch.
>
> I used the sata disk and two em28xx dvb sticks, no other usb devices,
> no ethernet cable connected, tuners on saa716x-based card not used.
>
> What I can see in the log: a lot of coherent mappings from sata_mv
> and orion_ehci, a
On Thu, Jan 17, 2013 at 08:26:45PM +, Arnd Bergmann wrote:
> On Thursday 17 January 2013, Soeren Moch wrote:
> > On 17.01.2013 11:49, Arnd Bergmann wrote:
> > > On Wednesday 16 January 2013, Soeren Moch wrote:
> > I will see what I can do here. Is there an easy way to track the buffer
> >
On Thu, Jan 17, 2013 at 08:26:45PM +, Arnd Bergmann wrote:
On Thursday 17 January 2013, Soeren Moch wrote:
On 17.01.2013 11:49, Arnd Bergmann wrote:
On Wednesday 16 January 2013, Soeren Moch wrote:
I will see what I can do here. Is there an easy way to track the buffer
usage
Please find attached a debug log generated with your patch.
I used the sata disk and two em28xx dvb sticks, no other usb devices,
no ethernet cable connected, tuners on saa716x-based card not used.
What I can see in the log: a lot of coherent mappings from sata_mv
and orion_ehci, a few
On Saturday 19 January 2013, Soeren Moch wrote:
What I can see in the log: a lot of coherent mappings from sata_mv and
orion_ehci, a few from mv643xx_eth, no other coherent mappings.
All coherent mappings are page aligned, some of them (from orion_ehci)
are not really small (as claimed in
On Thursday 17 January 2013, Soeren Moch wrote:
> On 17.01.2013 11:49, Arnd Bergmann wrote:
> > On Wednesday 16 January 2013, Soeren Moch wrote:
> I will see what I can do here. Is there an easy way to track the buffer
> usage without having to wait for complete exhaustion?
> >>>
> >>>
On 17.01.2013 11:49, Arnd Bergmann wrote:
On Wednesday 16 January 2013, Soeren Moch wrote:
I will see what I can do here. Is there an easy way to track the buffer
usage without having to wait for complete exhaustion?
DMA_API_DEBUG
OK, maybe I can try this.
Any success with this? It
On Wednesday 16 January 2013, Soeren Moch wrote:
> >> I will see what I can do here. Is there an easy way to track the buffer
> >> usage without having to wait for complete exhaustion?
> >
> > DMA_API_DEBUG
>
> OK, maybe I can try this.
> >
Any success with this? It should at least tell you if
On Wednesday 16 January 2013, Soeren Moch wrote:
I will see what I can do here. Is there an easy way to track the buffer
usage without having to wait for complete exhaustion?
DMA_API_DEBUG
OK, maybe I can try this.
Any success with this? It should at least tell you if there is a
On 17.01.2013 11:49, Arnd Bergmann wrote:
On Wednesday 16 January 2013, Soeren Moch wrote:
I will see what I can do here. Is there an easy way to track the buffer
usage without having to wait for complete exhaustion?
DMA_API_DEBUG
OK, maybe I can try this.
Any success with this? It
On Thursday 17 January 2013, Soeren Moch wrote:
On 17.01.2013 11:49, Arnd Bergmann wrote:
On Wednesday 16 January 2013, Soeren Moch wrote:
I will see what I can do here. Is there an easy way to track the buffer
usage without having to wait for complete exhaustion?
DMA_API_DEBUG
OK,
On 16.01.2013 18:47, Jason Cooper wrote:
On Wed, Jan 16, 2013 at 06:32:09PM +0100, Soeren Moch wrote:
On 16.01.2013 09:55, Soeren Moch wrote:
On 16.01.2013 04:24, Soeren Moch wrote:
I did not bisect it, but Marek mentioned earlier that commit
e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux
On Wed, Jan 16, 2013 at 06:32:09PM +0100, Soeren Moch wrote:
> On 16.01.2013 09:55, Soeren Moch wrote:
> >On 16.01.2013 04:24, Soeren Moch wrote:
> >>I did not bisect it, but Marek mentioned earlier that commit
> >>e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
> >>new code
On 16.01.2013 09:55, Soeren Moch wrote:
On 16.01.2013 04:24, Soeren Moch wrote:
On 16.01.2013 03:40, Jason Cooper wrote:
Soeren,
On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
On 15.01.2013 22:56, Jason Cooper wrote:
On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper
On 16.01.2013 04:24, Soeren Moch wrote:
On 16.01.2013 03:40, Jason Cooper wrote:
Soeren,
On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
On 15.01.2013 22:56, Jason Cooper wrote:
On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
If my understanding is correct, one of
On 16.01.2013 04:24, Soeren Moch wrote:
On 16.01.2013 03:40, Jason Cooper wrote:
Soeren,
On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
On 15.01.2013 22:56, Jason Cooper wrote:
On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
If my understanding is correct, one of
On 16.01.2013 09:55, Soeren Moch wrote:
On 16.01.2013 04:24, Soeren Moch wrote:
On 16.01.2013 03:40, Jason Cooper wrote:
Soeren,
On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
On 15.01.2013 22:56, Jason Cooper wrote:
On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper
On Wed, Jan 16, 2013 at 06:32:09PM +0100, Soeren Moch wrote:
On 16.01.2013 09:55, Soeren Moch wrote:
On 16.01.2013 04:24, Soeren Moch wrote:
I did not bisect it, but Marek mentioned earlier that commit
e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
new code for dma
On 16.01.2013 18:47, Jason Cooper wrote:
On Wed, Jan 16, 2013 at 06:32:09PM +0100, Soeren Moch wrote:
On 16.01.2013 09:55, Soeren Moch wrote:
On 16.01.2013 04:24, Soeren Moch wrote:
I did not bisect it, but Marek mentioned earlier that commit
e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux
On 16.01.2013 03:40, Jason Cooper wrote:
Soeren,
On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
On 15.01.2013 22:56, Jason Cooper wrote:
On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
If my understanding is correct, one of the drivers (most likely one)
either
Soeren,
On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
> On 15.01.2013 22:56, Jason Cooper wrote:
> >On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
> >>If my understanding is correct, one of the drivers (most likely one)
> >>either asks for too small of a dma buffer,
On 15.01.2013 22:56, Jason Cooper wrote:
Soeren,
On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
If my understanding is correct, one of the drivers (most likely one)
either asks for too small of a dma buffer, or is not properly
deallocating blocks from the per-device pool.
Soeren,
On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
> If my understanding is correct, one of the drivers (most likely one)
> either asks for too small of a dma buffer, or is not properly
> deallocating blocks from the per-device pool. Either case leads to
> exhaustion, and
On Tue, Jan 15, 2013 at 09:05:50PM +0100, Sebastian Hesselbarth wrote:
> If we look for a mem leak in one of the above drivers (including sata_mv),
> is there an easy way to keep track of allocated and freed kernel memory?
I'm inclined to think sata_mv is not the cause here, as there are many
On Tue, Jan 15, 2013 at 09:50:20AM -0800, Greg KH wrote:
> On Tue, Jan 15, 2013 at 11:56:42AM -0500, Jason Cooper wrote:
> > Greg,
> >
> > I've added you to the this thread hoping for a little insight into USB
> > drivers and their use of coherent and GFP_ATOMIC. Am I barking up the
> > wrong
On 01/15/2013 05:56 PM, Jason Cooper wrote:
Greg,
I've added you to the this thread hoping for a little insight into USB
drivers and their use of coherent and GFP_ATOMIC. Am I barking up the
wrong tree by looking a the drivers?
On Mon, Jan 14, 2013 at 12:56:57PM +0100, Soeren Moch wrote:
On
On Tue, Jan 15, 2013 at 11:56:42AM -0500, Jason Cooper wrote:
> Greg,
>
> I've added you to the this thread hoping for a little insight into USB
> drivers and their use of coherent and GFP_ATOMIC. Am I barking up the
> wrong tree by looking a the drivers?
I don't understand, which drivers are
Greg,
I've added you to the this thread hoping for a little insight into USB
drivers and their use of coherent and GFP_ATOMIC. Am I barking up the
wrong tree by looking a the drivers?
On Mon, Jan 14, 2013 at 12:56:57PM +0100, Soeren Moch wrote:
> On 20.11.2012 15:31, Marek Szyprowski wrote:
>
On 15.01.2013 22:56, Jason Cooper wrote:
Soeren,
On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
If my understanding is correct, one of the drivers (most likely one)
either asks for too small of a dma buffer, or is not properly
deallocating blocks from the per-device pool.
Soeren,
On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
On 15.01.2013 22:56, Jason Cooper wrote:
On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
If my understanding is correct, one of the drivers (most likely one)
either asks for too small of a dma buffer, or is not
On 16.01.2013 03:40, Jason Cooper wrote:
Soeren,
On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
On 15.01.2013 22:56, Jason Cooper wrote:
On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
If my understanding is correct, one of the drivers (most likely one)
either
Greg,
I've added you to the this thread hoping for a little insight into USB
drivers and their use of coherent and GFP_ATOMIC. Am I barking up the
wrong tree by looking a the drivers?
On Mon, Jan 14, 2013 at 12:56:57PM +0100, Soeren Moch wrote:
On 20.11.2012 15:31, Marek Szyprowski wrote:
On Tue, Jan 15, 2013 at 11:56:42AM -0500, Jason Cooper wrote:
Greg,
I've added you to the this thread hoping for a little insight into USB
drivers and their use of coherent and GFP_ATOMIC. Am I barking up the
wrong tree by looking a the drivers?
I don't understand, which drivers are you
On 01/15/2013 05:56 PM, Jason Cooper wrote:
Greg,
I've added you to the this thread hoping for a little insight into USB
drivers and their use of coherent and GFP_ATOMIC. Am I barking up the
wrong tree by looking a the drivers?
On Mon, Jan 14, 2013 at 12:56:57PM +0100, Soeren Moch wrote:
On
On Tue, Jan 15, 2013 at 09:50:20AM -0800, Greg KH wrote:
On Tue, Jan 15, 2013 at 11:56:42AM -0500, Jason Cooper wrote:
Greg,
I've added you to the this thread hoping for a little insight into USB
drivers and their use of coherent and GFP_ATOMIC. Am I barking up the
wrong tree by
On Tue, Jan 15, 2013 at 09:05:50PM +0100, Sebastian Hesselbarth wrote:
If we look for a mem leak in one of the above drivers (including sata_mv),
is there an easy way to keep track of allocated and freed kernel memory?
I'm inclined to think sata_mv is not the cause here, as there are many
heavy
Soeren,
On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
If my understanding is correct, one of the drivers (most likely one)
either asks for too small of a dma buffer, or is not properly
deallocating blocks from the per-device pool. Either case leads to
exhaustion, and falling
On 20.11.2012 15:31, Marek Szyprowski wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning of emergency memory pools without any good reason. Additionaly,
on ARM architecture any driver which is using
On 20.11.2012 15:31, Marek Szyprowski wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning of emergency memory pools without any good reason. Additionaly,
on ARM architecture any driver which is using
On 11/21/2012 8:17 PM, Andrew Morton wrote:
On Wed, 21 Nov 2012 10:20:07 +0100
Marek Szyprowski wrote:
> On 11/21/2012 9:36 AM, Andrew Morton wrote:
> > On Wed, 21 Nov 2012 09:08:52 +0100 Marek Szyprowski
wrote:
> > > On 11/20/2012 8:33 PM, Andrew Morton wrote:
> > > > On Tue, 20 Nov 2012
On 11/21/2012 8:17 PM, Andrew Morton wrote:
On Wed, 21 Nov 2012 10:20:07 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:
On 11/21/2012 9:36 AM, Andrew Morton wrote:
On Wed, 21 Nov 2012 09:08:52 +0100 Marek Szyprowski
m.szyprow...@samsung.com wrote:
On 11/20/2012 8:33 PM, Andrew
On Wed, 21 Nov 2012 10:20:07 +0100
Marek Szyprowski wrote:
> Hello,
>
> On 11/21/2012 9:36 AM, Andrew Morton wrote:
> > On Wed, 21 Nov 2012 09:08:52 +0100 Marek Szyprowski
> > wrote:
> >
> > > Hello,
> > >
> > > On 11/20/2012 8:33 PM, Andrew Morton wrote:
> > > > On Tue, 20 Nov 2012 15:31:45
Hello,
On 11/21/2012 9:36 AM, Andrew Morton wrote:
On Wed, 21 Nov 2012 09:08:52 +0100 Marek Szyprowski
wrote:
> Hello,
>
> On 11/20/2012 8:33 PM, Andrew Morton wrote:
> > On Tue, 20 Nov 2012 15:31:45 +0100
> > Marek Szyprowski wrote:
> >
> > > dmapool always calls dma_alloc_coherent() with
On Wed, 21 Nov 2012 09:08:52 +0100 Marek Szyprowski
wrote:
> Hello,
>
> On 11/20/2012 8:33 PM, Andrew Morton wrote:
> > On Tue, 20 Nov 2012 15:31:45 +0100
> > Marek Szyprowski wrote:
> >
> > > dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> > > regardless the flags provided
Hello,
On 11/20/2012 8:33 PM, Andrew Morton wrote:
On Tue, 20 Nov 2012 15:31:45 +0100
Marek Szyprowski wrote:
> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> regardless the flags provided by the caller. This causes excessive
> pruning of emergency memory pools without any
Hello,
On 11/20/2012 8:33 PM, Andrew Morton wrote:
On Tue, 20 Nov 2012 15:31:45 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning of emergency
On Wed, 21 Nov 2012 09:08:52 +0100 Marek Szyprowski m.szyprow...@samsung.com
wrote:
Hello,
On 11/20/2012 8:33 PM, Andrew Morton wrote:
On Tue, 20 Nov 2012 15:31:45 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
Hello,
On 11/21/2012 9:36 AM, Andrew Morton wrote:
On Wed, 21 Nov 2012 09:08:52 +0100 Marek Szyprowski m.szyprow...@samsung.com
wrote:
Hello,
On 11/20/2012 8:33 PM, Andrew Morton wrote:
On Tue, 20 Nov 2012 15:31:45 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:
dmapool
On Wed, 21 Nov 2012 10:20:07 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:
Hello,
On 11/21/2012 9:36 AM, Andrew Morton wrote:
On Wed, 21 Nov 2012 09:08:52 +0100 Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
On 11/20/2012 8:33 PM, Andrew Morton wrote:
On
On Tue, Nov 20, 2012 at 11:33:25AM -0800, Andrew Morton wrote:
> On Tue, 20 Nov 2012 15:31:45 +0100
> Marek Szyprowski wrote:
>
> > dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> > regardless the flags provided by the caller. This causes excessive
> > pruning of emergency
On Tue, 20 Nov 2012 15:31:45 +0100
Marek Szyprowski wrote:
> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> regardless the flags provided by the caller. This causes excessive
> pruning of emergency memory pools without any good reason. Additionaly,
> on ARM architecture any
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning of emergency memory pools without any good reason. Additionaly,
on ARM architecture any driver which is using dmapools will sooner or
later trigger the
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning of emergency memory pools without any good reason. Additionaly,
on ARM architecture any driver which is using dmapools will sooner or
later trigger the
On Tue, 20 Nov 2012 15:31:45 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning of emergency memory pools without any good reason. Additionaly,
on ARM
On Tue, Nov 20, 2012 at 11:33:25AM -0800, Andrew Morton wrote:
On Tue, 20 Nov 2012 15:31:45 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning of
84 matches
Mail list logo
