Thank you Bastian for the recommendation to look into the swappiness
parameter. I had previously been curious whether I could integrate the
*mlock* tool to tell kernel explicitly which processes to not swap out
(e.g. olsrd, wpa_supplicant).
I also just discovered a Nanostation M mesh node
Hmm, actually I discovered that wpa_supplicant apparently wrote a 240Kbyte
dump file on this device, with approximately the same timestamp as when the
memory errors started appearing in dmesg.
/tmp/wpa_supplicant.1625.11.1384060826.core
I've retained the dump file, if anyone perhaps wants it.
I can take a look at it and see if there is anything interesting, I might
be able to get it disassembled if its any sort of executable. It might just
be an array or something though.
On Mon, Nov 11, 2013 at 12:56 PM, Ben West b...@gowasabi.net wrote:
Hmm, actually I discovered that
* Ben West b...@gowasabi.net [11.11.2013 20:36]:
I am assuming incidents like these are occurring due to an ill-behaved
process (or processes) attempting to allocate several MBytes for itself,
failing that, and also causing memory errors for random resident processes
in consequence. The only
It might mappable against the driver binary or kernel image. Kind of
depends on what it is in it.
On Mon, Nov 11, 2013 at 1:39 PM, Bastian Bittorf bitt...@bluebottle.comwrote:
* Ben West b...@gowasabi.net [11.11.2013 20:36]:
I am assuming incidents like these are occurring due to an
* Ben West b...@gowasabi.net [09.11.2013 19:22]:
anecdotal experience that some processes don't behave well when paged to
swap. I'm running AR7240 devices with 32MB RAM (i.e. UBNT M gear) as mesh
nodes, and I've found that services like olsrd, coovachilli, and
wpa_supplicant seem to behave
Hi Ben,
Thanks for the feedback.
That's strange, although has logic.
Even more strage is that your device has 32MB of Ram so it should be able
to be handling things well.
Can you compile the trunk (Barrier Breaker) and test with it on the same
device to find out if it will behavior the same way
On 11/07/2013 12:08 AM, Fernando Frediani wrote:
Hi Hauke,
What you mean by zram worked differently ? As far as I know zram
(previously known as compcache) has been merged to the Linux Kernel at
3.2 so it should be there on 3.3 as well (check drivers/staging/zram).
In Kernel 3.3 zram
As someone who runs AA r38247 patched to include zram support, I can add
anecdotal experience that some processes don't behave well when paged to
swap. I'm running AR7240 devices with 32MB RAM (i.e. UBNT M gear) as mesh
nodes, and I've found that services like olsrd, coovachilli, and
On 8 Nov 2013 00:41, Ben West b...@gowasabi.net wrote:
As someone who runs AA r38247 patched to include zram support, I can add
anecdotal experience that some processes don't behave well when paged to
swap. I'm running AR7240 devices with 32MB RAM (i.e. UBNT M gear) as mesh
nodes, and I've
On 11/06/2013 05:15 PM, Fernando Frediani wrote:
Hello Hauke,
I have seen a few emails from you on openwrt-devel list about the zram module
and also saw it is already present on the trunk(Barrier Breaker).
Was wondering if there is any work going on or will be to backport it to
Attitude
Hi Hauke,
What you mean by zram worked differently ? As far as I know zram
(previously known as compcache) has been merged to the Linux Kernel at 3.2
so it should be there on 3.3 as well (check drivers/staging/zram).
I have talked to Bastien in another conversation and he mentioned he has a
12 matches
Mail list logo
