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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>