Quoting kaffbeemer <[EMAIL PROTECTED]>:
> Jan 23 20:13:50 axis-00408c100330 kernel: lowmem_reserve[]: 0 0 0 0
> Jan 23 20:13:50 axis-00408c100330 kernel: DMA: 10*8kB 4*16kB 0*32kB
> 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB =
> 656kB
> Jan 23 20:13:50 axis-00408c100330 kernel: DMA32: empty
> Jan 23 20:13:50 axis-00408c100330 kernel: Normal: empty
> Jan 23 20:13:50 axis-00408c100330 kernel: HighMem: empty
> Jan 23 20:13:50 axis-00408c100330 kernel: Free swap: 0kB
> Jan 23 20:13:50 axis-00408c100330 kernel: 2048 pages of RAM
> Jan 23 20:13:50 axis-00408c100330 kernel: 132 free pages
> Jan 23 20:13:50 axis-00408c100330 kernel: 323 reserved pages
> Jan 23 20:13:50 axis-00408c100330 kernel: 1358 pages nonshared
> Jan 23 20:13:50 axis-00408c100330 kernel: 509 pages shared
> Jan 23 20:13:50 axis-00408c100330 kernel: 0 pages swap cached
> Jan 23 20:13:50 axis-00408c100330 kernel: Out of Memory: Killed
> process 3939 (ls).
Your Foxboard has no more memory available: maybe there are some leaks in the
apps you use for sharing files? Here's a quote from "man malloc" on my RedHat
workstation, it applies to your situation too:
By default, Linux follows an optimistic memory allocation strategy. This
means that when malloc() returns non-NULL there is no guarantee that the
memory really is available. This is a really bad bug. In case it turns out
that the system is out of memory, one or more processes will be killed
by the infamous OOM killer. In case Linux is employed under circumstances
where it would be less desirable to suddenly lose some randomly picked
processes, and moreover the kernel version is sufficiently recent, one
can switch off this overcommitting behavior using a command like
# echo 2 > /proc/sys/vm/overcommit_memory
See also the kernel Documentation directory, files vm/overcommit-accounting
and sysctl/vm.txt.
HTH,
Ant9000
