[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Oops in Etch 40r3

On Sun, Apr 13, 2008 at 05:55:36AM +0200, NN_il_Confusionario wrote:
> On Sat, Apr 12, 2008 at 11:23:48PM +0000, digbyt@skaro.afraid.org wrote:
> > digbyt@debian:~$ free -b
> >              total       used       free     shared    buffers     cached
> > Mem:    1061478400  311463936  750014464          0  100552704  105132032
> > -/+ buffers/cache:  105779200  955699200
> > Swap:    699138048          0  699138048
> >  . .Detected 1495.263 MHz processor.
> For my standards this is a very modern and powerful box.
> If memterst86 (or memtest from memtester package, if you cannot spare
> the box) and the check of logs does not show anything, I will
> _temporarilly_ try another kernel (a newer one from etch-and-half,
> backports and/or an older one from sarge; or even the suse kernel that
> was running fine before) to understand if a bug report agaisnt the
> current kernel in etch is needed

memtester is an interesting idea (since my next opportunity to shutdown
is about a week away). I assume that it won't really be able to rule out
the possibility of a memory problem as it can only test a sufficiently
small amount of free memory so as not to interfere with the running of
the system.
That gives rise to another question. I just repeated the free command
above to see how much memory can be spared, and see that my memory usage
has steadily climbed despite having no users on the system, and nothing
running other than the standard packages from a server install:
             total       used       free     shared    buffers     cached
Mem:    1061478400  860430336  201048064          0  374857728  164020224
-/+ buffers/cache:  321552384  739926016
Swap:    699138048          0  699138048
Clearly about half of this increase (270M) is due to the buffer chache,
which is a reasonable use for spare memory capacity. Any idea how to
find out where the rest has gone? I'd rather not push the system into
excessive swapping if disk i/o is a potentially implicated in the
original crash.
Digby R. S. Tarvin                                          digbyt(at)digbyt.com

Reply to: