From: Jonathan W. <jw...@ju...> - 2014-02-01 10:09:50
|
Hi Ilia On Sat, Feb 01, 2014 at 02:14:44AM +0400, ???????? wrote: > > Here is onscreen photos of > > mem lack in r2240: Thanks for these. Looking at the numbers quickly I don't think this is demonstrating a memory leak as such. Certainly the amount of "free" memory is decreasing, but this is by and large a consequence of the increasing amount of memory being used for buffers and cache. This is relatively normal. If more memory ends up being needed for programs the cache usage will be reduced to accommodate this. Furthermore, the memory used by jackd is pretty much constant across all the photos, so if there is a memory leak in jackd or ffado it certainly isn't showing up here. So unless I'm missing something, I don't think this shows a memory leak in progress. A few months ago I did identify a condition under which the kernel could exhaust the system memory. It was triggered as a result of changes made in r2379. A workaround went in as r2384, with a "proper" fix in r2406. All this was considerably later than r2240. Therefore, if there is a kernel memory issue being triggered here it is different to the one I am aware of. > and lockups of r2310: > : If these have the same underlying cause as the reproducible ones triggered by r2379 then there must be something else on your system which is creating the correct environment to trigger the kernel bug. As far as I am aware the r2379 kernel bug has not been tracked down and fixed yet. > rghost.net/download/52105790/0b38c9c33d3268e47141bee7b2b75cede70c9a20/svn2310-lockup-ffado-1.jpg These lockups are different to those that I'm aware of. Stefan mentioned that perhaps a bug in an "older kernel" was responsible for these, but your ffado-diag output indicated that you were using 3.11.something. Interesting. Regards jonathan |