https://bugzilla.novell.com/show_bug.cgi?id=393988
User jbohac@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=393988#c8
Jiri Bohac changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
Info Provider| |sbrabec@novell.com
--- Comment #8 from Jiri Bohac 2008-06-25 02:44:58 MDT ---
I don't think we have any indication that the crash is caused by netfilter.
Netfilter is shown in one of the stack traces, but apparently it copes well
with the allocation failure and we get a couple more allocation failures after
that (most of them in the 8169 driver).
All the failures are atomic, and all are order 0 (single page), so it's not
like any of them would be a hog trying to allocate too much in interrupt
context.
There is probably something doing a lot of atomic allocations wasting the
reserves for atomic allocations and probably a buggy piece of code somewhere
that does not properly handle allocation failures.
Unfortunately, we don't see that in the stack trace of that.
Stanislav, if you have time to help with debugging this, please try to
reproduce it with a serial console attached (this would probably allow us to
see the stack trace). If you have trouble reproducing the problem, you can try
increasing the memory pressure by lowering the memory watermarks that specify
the amount of memory the kernel will preserve and refuse to give out to
allocations.
Currently this is around 4000kB (see the "DMA32 free ...... min:4016kB" line
in your messages). You may try lowering that e.g. to 2000 or 1000 by writing to
/proc/sys/vm/min_free_kbytes. Also, try generating high network load - this is
a typical user of atomic allocations, so this will increase the memory pressure
as well.
If you don't have time for this, there is little I can do (probably a
WORKSFORME)
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.