Hi,
the appended 0-order alloc failure resulted in killing X and
subsequently my beloved cats (at least the screensaver cycling through
my collection of "family" pictures :-) From the time in
/var/log/messages this happend during "updatedb" (yes, I could switch
that of ...).
The system in question is a Notebook with 320 MB and no swap. Kernel is
2.4.18-pre8 with Andreas VM-24, O(1)-K8, preempt and lock break. Running
with swap disabled improves my "interactive" experience. Of course, I am
aware that I risk OOM conditions, but according to the output there was
enough memory available in buffer/cache.
The thing happens from arch/i383/mm/fault.c. I have added the "VM: out
of memory ..." output and a call to show_mem() just before the kill
instruction (this happened before). As the mem-info shows, there should
be plenty of memory available in buffer/cache.
Is this of any help? Anything I should do?
% dmesg
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
cf8dde60 c026c520 00000000 000001d2 00000000 000001d2 cff8c3c0 00104025
ce9ab3c0 00000001 00000001 c02b747c c02b7654 000001d2 00000000
c012f556
418e4000 c01253dc 418e4000 cff8c3c0 00000001 ce9ab3c0 c01254b5
cff8c3c0
Call Trace: [<c012f556>] [<c01253dc>] [<c01254b5>] [<c012565b>]
[<c01124db>]
[<c0112328>] [<c0106367>] [<c0106470>] [<c0107158>]
VM: out of memory condition in do_page_fault. adress=0x418e4000,
error_code=0x06
Mem-info:
Free pages: 2472kB ( 0kB HighMem)
Zone:DMA freepages: 1352kB
Zone:Normal freepages: 1120kB
Zone:HighMem freepages: 0kB
( Active: 36930, inactive: 39647, free: 618 )
2*4kB 0*8kB 0*16kB 0*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB
0*2048kB = 1352kB)
8*4kB 2*8kB 1*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB
0*2048kB = 1120kB)
= 0kB)
Swap cache: add 0, delete 0, find 0/0, race 0+0
Free swap: 0kB
81888 pages of RAM
0 pages of HIGHMEM
1669 reserved pages
16884 pages shared
0 pages swap cached
0 pages in page table cache
Buffer memory: 30320kB
Cache memory: 87756kB
VM: killing process X
% ksymoops
Reading Oops report from the terminal
cf8dde60 c026c520 00000000 000001d2 00000000 000001d2 cff8c3c0 00104025
ce9ab3c0 00000001 00000001 c02b747c c02b7654 000001d2 00000000
c012f556
418e4000 c01253dc 418e4000 cff8c3c0 00000001 ce9ab3c0 c01254b5
cff8c3c0
Call Trace: [<c012f556>] [<c01253dc>] [<c01254b5>] [<c012565b>]
[<c01124db>]
[<c0112328>] [<c0106367>] [<c0106470>] [<c0107158>]
Warning (Oops_read): Code line not seen, dumping what data is available
Trace; c012f556 <_alloc_pages+16/18>
Trace; c01253dc <do_anonymous_page+50/f4>
Trace; c01254b4 <do_no_page+34/17c>
Trace; c012565a <handle_mm_fault+5e/f0>
Trace; c01124da <do_page_fault+1b2/4f2>
Trace; c0112328 <do_page_fault+0/4f2>
Trace; c0106366 <restore_sigcontext+116/13c>
Trace; c0106470 <sys_sigreturn+e4/110>
Trace; c0107158 <error_code+34/40>
Martin
-- ------------------------------------------------------------------ Martin Knoblauch | email: Martin.Knoblauch@TeraPort.de TeraPort GmbH | Phone: +49-89-510857-309 C+ITS | Fax: +49-89-510857-111 http://www.teraport.de | Mobile: +49-170-4904759 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:14 EST