From: smoch@web.de (Soeren Moch)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
Date: Mon, 28 Jan 2013 21:59:18 +0100 [thread overview]
Message-ID: <5106E6A6.7010207@web.de> (raw)
In-Reply-To: <20130123181029.GE20719@lunn.ch>
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 3396 3396 3396
>>> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3365 3396 3394 3396 3396
>>> 3396 3396 3373 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
>>> 3396 3353 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
>>> 3394 3396 3396 3396 3396 3396 3396 3396
>>>
>>> Before the last pool exhaustion going down:
>>> 3395 3395 3389 3379 3379 3374 3367 3360 3352 3343 3343 3343 3342 3336
>>> 3332 3324 3318 3314 3310 3307 3305 3299 3290 3283 3279 3272 3266 3265
>>> 3247 3247 3247 3242 3236 3236
>>>
>> Here I stopped vdr (and so closed all dvb_demux devices), the number
>> was remaining the same 3236, even after restart of vdr (and restart
>> of streaming).
>
> So it does suggest a leak. Probably somewhere on an error path,
> e.g. its lost video sync.
>
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 /debug/dma-api/num_free_entries',
which gave stable numbers), but after half an hour there are only
init_isoc messages without corresponding stop_urbs messages and
num_free_entries decreased until coherent pool exhaustion.
Any idea where the memory leak is? What is allocating coherent buffers
for orion-ehci?
Soeren
Jan 28 20:46:03 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:03 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:03 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:03 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:23 guruvdr kernel: em28xx #0 em28xx_stop_urbs :em28xx:
called em28xx_stop_urbs
Jan 28 20:46:23 guruvdr kernel: em28xx #1 em28xx_stop_urbs :em28xx:
called em28xx_stop_urbs
Jan 28 20:46:24 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:24 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:24 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:24 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:44 guruvdr kernel: em28xx #1 em28xx_stop_urbs :em28xx:
called em28xx_stop_urbs
Jan 28 20:46:44 guruvdr kernel: em28xx #0 em28xx_stop_urbs :em28xx:
called em28xx_stop_urbs
Jan 28 20:46:45 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:45 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:45 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:45 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:54:33 guruvdr kernel: ERROR: 1024 KiB atomic DMA coherent pool
is too small!
Jan 28 20:54:33 guruvdr kernel: Please increase it with coherent_pool=
kernel parameter!
WARNING: multiple messages have this Message-ID (diff)
From: Soeren Moch <smoch@web.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Arnd Bergmann <arnd@arndb.de>,
Jason Cooper <jason@lakedaemon.net>,
Greg KH <gregkh@linuxfoundation.org>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-kernel@vger.kernel.org, Michal Hocko <mhocko@suse.cz>,
linux-mm@kvack.org, Kyungmin Park <kyungmin.park@samsung.com>,
Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
linaro-mm-sig@lists.linaro.org,
linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
Date: Mon, 28 Jan 2013 21:59:18 +0100 [thread overview]
Message-ID: <5106E6A6.7010207@web.de> (raw)
In-Reply-To: <20130123181029.GE20719@lunn.ch>
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 3396 3396 3396
>>> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3365 3396 3394 3396 3396
>>> 3396 3396 3373 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
>>> 3396 3353 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
>>> 3394 3396 3396 3396 3396 3396 3396 3396
>>>
>>> Before the last pool exhaustion going down:
>>> 3395 3395 3389 3379 3379 3374 3367 3360 3352 3343 3343 3343 3342 3336
>>> 3332 3324 3318 3314 3310 3307 3305 3299 3290 3283 3279 3272 3266 3265
>>> 3247 3247 3247 3242 3236 3236
>>>
>> Here I stopped vdr (and so closed all dvb_demux devices), the number
>> was remaining the same 3236, even after restart of vdr (and restart
>> of streaming).
>
> So it does suggest a leak. Probably somewhere on an error path,
> e.g. its lost video sync.
>
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 /debug/dma-api/num_free_entries',
which gave stable numbers), but after half an hour there are only
init_isoc messages without corresponding stop_urbs messages and
num_free_entries decreased until coherent pool exhaustion.
Any idea where the memory leak is? What is allocating coherent buffers
for orion-ehci?
Soeren
Jan 28 20:46:03 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:03 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:03 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:03 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:23 guruvdr kernel: em28xx #0 em28xx_stop_urbs :em28xx:
called em28xx_stop_urbs
Jan 28 20:46:23 guruvdr kernel: em28xx #1 em28xx_stop_urbs :em28xx:
called em28xx_stop_urbs
Jan 28 20:46:24 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:24 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:24 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:24 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:44 guruvdr kernel: em28xx #1 em28xx_stop_urbs :em28xx:
called em28xx_stop_urbs
Jan 28 20:46:44 guruvdr kernel: em28xx #0 em28xx_stop_urbs :em28xx:
called em28xx_stop_urbs
Jan 28 20:46:45 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:45 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:45 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:45 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:54:33 guruvdr kernel: ERROR: 1024 KiB atomic DMA coherent pool
is too small!
Jan 28 20:54:33 guruvdr kernel: Please increase it with coherent_pool=
kernel parameter!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Soeren Moch <smoch@web.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Arnd Bergmann <arnd@arndb.de>,
Jason Cooper <jason@lakedaemon.net>,
Greg KH <gregkh@linuxfoundation.org>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-kernel@vger.kernel.org, Michal Hocko <mhocko@suse.cz>,
linux-mm@kvack.org, Kyungmin Park <kyungmin.park@samsung.com>,
Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
linaro-mm-sig@lists.linaro.org,
linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
Date: Mon, 28 Jan 2013 21:59:18 +0100 [thread overview]
Message-ID: <5106E6A6.7010207@web.de> (raw)
In-Reply-To: <20130123181029.GE20719@lunn.ch>
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 3396 3396 3396
>>> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3365 3396 3394 3396 3396
>>> 3396 3396 3373 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
>>> 3396 3353 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
>>> 3394 3396 3396 3396 3396 3396 3396 3396
>>>
>>> Before the last pool exhaustion going down:
>>> 3395 3395 3389 3379 3379 3374 3367 3360 3352 3343 3343 3343 3342 3336
>>> 3332 3324 3318 3314 3310 3307 3305 3299 3290 3283 3279 3272 3266 3265
>>> 3247 3247 3247 3242 3236 3236
>>>
>> Here I stopped vdr (and so closed all dvb_demux devices), the number
>> was remaining the same 3236, even after restart of vdr (and restart
>> of streaming).
>
> So it does suggest a leak. Probably somewhere on an error path,
> e.g. its lost video sync.
>
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 /debug/dma-api/num_free_entries',
which gave stable numbers), but after half an hour there are only
init_isoc messages without corresponding stop_urbs messages and
num_free_entries decreased until coherent pool exhaustion.
Any idea where the memory leak is? What is allocating coherent buffers
for orion-ehci?
Soeren
Jan 28 20:46:03 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:03 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:03 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:03 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:23 guruvdr kernel: em28xx #0 em28xx_stop_urbs :em28xx:
called em28xx_stop_urbs
Jan 28 20:46:23 guruvdr kernel: em28xx #1 em28xx_stop_urbs :em28xx:
called em28xx_stop_urbs
Jan 28 20:46:24 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:24 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:24 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:24 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:44 guruvdr kernel: em28xx #1 em28xx_stop_urbs :em28xx:
called em28xx_stop_urbs
Jan 28 20:46:44 guruvdr kernel: em28xx #0 em28xx_stop_urbs :em28xx:
called em28xx_stop_urbs
Jan 28 20:46:45 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:45 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:46:45 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers each
with 64 x 940 bytes
Jan 28 20:46:45 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
called em28xx_init_isoc in mode 2
Jan 28 20:54:33 guruvdr kernel: ERROR: 1024 KiB atomic DMA coherent pool
is too small!
Jan 28 20:54:33 guruvdr kernel: Please increase it with coherent_pool=
kernel parameter!
next prev parent reply other threads:[~2013-01-28 20:59 UTC|newest]
Thread overview: 181+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-08 6:38 [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls Marek Szyprowski
2012-11-08 6:38 ` Marek Szyprowski
2012-11-08 6:38 ` Marek Szyprowski
2012-11-11 17:22 ` Andrew Lunn
2012-11-11 17:22 ` Andrew Lunn
2012-11-11 17:22 ` Andrew Lunn
2012-11-12 9:48 ` Soeren Moch
2012-11-12 9:48 ` Soeren Moch
2012-11-12 9:48 ` Soeren Moch
2012-11-12 10:38 ` Andrew Lunn
2012-11-12 10:38 ` Andrew Lunn
2012-11-12 10:38 ` Andrew Lunn
2012-11-12 11:03 ` Soeren Moch
2012-11-12 11:03 ` Soeren Moch
2012-11-12 11:03 ` Soeren Moch
2012-11-11 17:31 ` [PATCH] ARM: Orion: Remove redundent init_dma_coherent_pool_size() Andrew Lunn
2012-11-19 0:20 ` Jason Cooper
2013-04-17 20:38 ` Jason Cooper
2013-04-17 20:49 ` Gregory CLEMENT
2013-05-13 19:38 ` Jason Cooper
2012-11-19 0:18 ` [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls Jason Cooper
2012-11-19 0:18 ` Jason Cooper
2012-11-19 0:18 ` Jason Cooper
2012-11-19 22:48 ` Andrew Morton
2012-11-19 22:48 ` Andrew Morton
2012-11-19 22:48 ` Andrew Morton
2012-11-20 10:48 ` Marek Szyprowski
2012-11-20 10:48 ` Marek Szyprowski
2012-11-20 10:48 ` Marek Szyprowski
2012-11-20 19:52 ` Andrew Morton
2012-11-20 19:52 ` Andrew Morton
2012-11-20 19:52 ` Andrew Morton
2012-11-20 14:31 ` [PATCH v2] " Marek Szyprowski
2012-11-20 14:31 ` Marek Szyprowski
2012-11-20 14:31 ` Marek Szyprowski
2012-11-20 19:33 ` Andrew Morton
2012-11-20 19:33 ` Andrew Morton
2012-11-20 19:33 ` Andrew Morton
2012-11-20 20:27 ` Jason Cooper
2012-11-20 20:27 ` Jason Cooper
2012-11-20 20:27 ` Jason Cooper
2012-11-21 8:08 ` Marek Szyprowski
2012-11-21 8:08 ` Marek Szyprowski
2012-11-21 8:08 ` Marek Szyprowski
2012-11-21 8:36 ` Andrew Morton
2012-11-21 8:36 ` Andrew Morton
2012-11-21 8:36 ` Andrew Morton
2012-11-21 9:20 ` Marek Szyprowski
2012-11-21 9:20 ` Marek Szyprowski
2012-11-21 9:20 ` Marek Szyprowski
2012-11-21 19:17 ` Andrew Morton
2012-11-21 19:17 ` Andrew Morton
2012-11-21 19:17 ` Andrew Morton
2012-11-22 12:55 ` Marek Szyprowski
2012-11-22 12:55 ` Marek Szyprowski
2012-11-22 12:55 ` Marek Szyprowski
2013-01-14 11:56 ` Soeren Moch
2013-01-14 11:56 ` Soeren Moch
2013-01-14 11:56 ` Soeren Moch
2013-01-15 16:56 ` Jason Cooper
2013-01-15 16:56 ` Jason Cooper
2013-01-15 16:56 ` Jason Cooper
2013-01-15 17:50 ` Greg KH
2013-01-15 17:50 ` Greg KH
2013-01-15 17:50 ` Greg KH
2013-01-15 20:16 ` Jason Cooper
2013-01-15 20:16 ` Jason Cooper
2013-01-15 20:16 ` Jason Cooper
2013-01-15 21:56 ` Jason Cooper
2013-01-15 21:56 ` Jason Cooper
2013-01-15 21:56 ` Jason Cooper
2013-01-16 0:17 ` Soeren Moch
2013-01-16 0:17 ` Soeren Moch
2013-01-16 0:17 ` Soeren Moch
2013-01-16 2:40 ` Jason Cooper
2013-01-16 2:40 ` Jason Cooper
2013-01-16 2:40 ` Jason Cooper
2013-01-16 3:24 ` Soeren Moch
2013-01-16 3:24 ` Soeren Moch
2013-01-16 3:24 ` Soeren Moch
2013-01-16 8:55 ` Soeren Moch
2013-01-16 8:55 ` Soeren Moch
2013-01-16 8:55 ` Soeren Moch
2013-01-16 15:50 ` [PATCH] ata: sata_mv: fix sg_tbl_pool alignment Jason Cooper
2013-01-16 15:50 ` Jason Cooper
2013-01-16 15:50 ` Jason Cooper
2013-01-16 17:05 ` Soeren Moch
2013-01-16 17:05 ` Soeren Moch
2013-01-16 17:05 ` Soeren Moch
2013-01-16 17:52 ` Jason Cooper
2013-01-16 17:52 ` Jason Cooper
2013-01-16 17:52 ` Jason Cooper
2013-01-16 18:35 ` Jason Cooper
2013-01-16 18:35 ` Jason Cooper
2013-01-16 18:35 ` Jason Cooper
2013-01-16 22:26 ` Soeren Moch
2013-01-16 22:26 ` Soeren Moch
2013-01-16 22:26 ` Soeren Moch
2013-01-16 23:10 ` Soeren Moch
2013-01-16 23:10 ` Soeren Moch
2013-01-16 23:10 ` Soeren Moch
2013-01-17 9:11 ` Soeren Moch
2013-01-17 9:11 ` Soeren Moch
2013-01-17 9:11 ` Soeren Moch
2013-01-16 17:32 ` [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls Soeren Moch
2013-01-16 17:32 ` Soeren Moch
2013-01-16 17:32 ` Soeren Moch
2013-01-16 17:47 ` Jason Cooper
2013-01-16 17:47 ` Jason Cooper
2013-01-16 17:47 ` Jason Cooper
2013-01-16 22:36 ` Soeren Moch
2013-01-16 22:36 ` Soeren Moch
2013-01-16 22:36 ` Soeren Moch
2013-01-17 10:49 ` Arnd Bergmann
2013-01-17 10:49 ` Arnd Bergmann
2013-01-17 10:49 ` Arnd Bergmann
2013-01-17 13:47 ` Soeren Moch
2013-01-17 13:47 ` Soeren Moch
2013-01-17 13:47 ` Soeren Moch
2013-01-17 20:26 ` Arnd Bergmann
2013-01-17 20:26 ` Arnd Bergmann
2013-01-17 20:26 ` Arnd Bergmann
2013-01-19 15:29 ` Soeren Moch
2013-01-19 15:29 ` Soeren Moch
2013-01-19 18:59 ` Andrew Lunn
2013-01-19 18:59 ` Andrew Lunn
2013-01-19 18:59 ` Andrew Lunn
2013-01-23 15:30 ` Soeren Moch
2013-01-23 15:30 ` Soeren Moch
2013-01-23 15:30 ` Soeren Moch
2013-01-23 16:25 ` Andrew Lunn
2013-01-23 16:25 ` Andrew Lunn
2013-01-23 16:25 ` Andrew Lunn
2013-01-23 17:07 ` Soeren Moch
2013-01-23 17:07 ` Soeren Moch
2013-01-23 17:07 ` Soeren Moch
2013-01-23 17:20 ` Soeren Moch
2013-01-23 17:20 ` Soeren Moch
2013-01-23 17:20 ` Soeren Moch
2013-01-23 18:10 ` Andrew Lunn
2013-01-23 18:10 ` Andrew Lunn
2013-01-23 18:10 ` Andrew Lunn
2013-01-28 20:59 ` Soeren Moch [this message]
2013-01-28 20:59 ` Soeren Moch
2013-01-28 20:59 ` Soeren Moch
2013-01-29 0:13 ` Jason Cooper
2013-01-29 0:13 ` Jason Cooper
2013-01-29 0:13 ` Jason Cooper
2013-01-29 11:02 ` Andrew Lunn
2013-01-29 11:02 ` Andrew Lunn
2013-01-29 11:02 ` Andrew Lunn
2013-01-29 11:50 ` Soeren Moch
2013-01-29 11:50 ` Soeren Moch
2013-01-29 11:50 ` Soeren Moch
2013-01-19 20:05 ` Arnd Bergmann
2013-01-19 20:05 ` Arnd Bergmann
2013-01-19 20:05 ` Arnd Bergmann
2013-01-21 15:01 ` Soeren Moch
2013-01-21 15:01 ` Soeren Moch
2013-01-21 15:01 ` Soeren Moch
2013-01-21 18:55 ` Arnd Bergmann
2013-01-21 18:55 ` Arnd Bergmann
2013-01-21 18:55 ` Arnd Bergmann
2013-01-21 21:01 ` Greg KH
2013-01-21 21:01 ` Greg KH
2013-01-21 21:01 ` Greg KH
2013-01-22 18:13 ` Arnd Bergmann
2013-01-22 18:13 ` Arnd Bergmann
2013-01-22 18:13 ` Arnd Bergmann
2013-01-23 14:37 ` Soeren Moch
2013-01-23 14:37 ` Soeren Moch
2013-01-23 14:37 ` Soeren Moch
2013-01-19 16:24 ` Andrew Lunn
2013-01-19 16:24 ` Andrew Lunn
2013-01-19 16:24 ` Andrew Lunn
2013-01-15 20:05 ` Sebastian Hesselbarth
2013-01-15 20:05 ` Sebastian Hesselbarth
2013-01-15 20:05 ` Sebastian Hesselbarth
2013-01-15 20:19 ` Jason Cooper
2013-01-15 20:19 ` Jason Cooper
2013-01-15 20:19 ` Jason Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5106E6A6.7010207@web.de \
--to=smoch@web.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.