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 wrote:
> * Ben West [11.11.2013 20:36]:
> > I am assuming incidents like these are occurring due to an ill-behaved
> > process (or processes) attemp
* Ben West [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 recovery I kno
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 wrote:
> Hmm, actually I discovered that wpa_supplicant apparently wr
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. Li
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 running
* Ben West [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 erratically if t
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 8 Nov 2013 00:41, "Ben West" 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 found that service
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
wpa_supplican
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 de
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
WRT54
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
> At
12 matches
Mail list logo
