On Thu, 7 Sep 2000 14:27:58 -0700 Kevin Franden <[EMAIL PROTECTED]>
writes:
>
>
> On Thu, 7 Sep 2000 12:00:56 +0200 (CEST) Francis Galiegue
> <[EMAIL PROTECTED]> writes:
> > On Wed, 6 Sep 2000, Kevin Franden wrote:
> >
> > >
> > > Hardware
> > > ========
> > [...]
> > > AMD K6-2 500 MHz chip
> >
> > Have you recompiled your kernel in any way? I've heard that the K6
>
> > had problems
> > with more than 64M RAM...
[ recalled thought ]
It utilized all my memory w/ the 7.0 release If I recall that was a 2.1
kernel, wasn't it?
> >
> >
> > > kernel 2.2.17-9mdk kernel source
> > >
> > >
> > >
> > > Memory: 128212/131027 available.
> >
> > Uh, you sure you haven't forgotten the "k" after the figures? If
> no,
> > then it
> > means that the kernel find 128 *kilobytes* RAM...
>
> Unless I'm still asleep (which is always possible) 128M = 131027k
>
> >
> > > (772k kernel code, 416k reserved, 16280k data, 52k init, 0k
> > bigmem)
> > >
> > > > NOTE: the used memory works out to be 17520k so there ought
> to
> > be
> > > only 113507k left! <
> > >
> > > General Protection Fault: 000
> > > CPU: 0
> > > EIP: 0010:[<c0121863>]
> > > EFLAGS: 00010286
> > >
> > > eax: 0000009f ebx: c7fff0d8 ecx: c017d20 edx:
> c01d7d20
> > > esi: 00000020 edi: ffffffff ebp: c7ffffe0 esp:
> c01e7ed8
> > > ds: 0018 es: 0018 ss: 0018
> > > process swapper (pid: 0, process nr: 0, stackpage=c01e7000)
> > >
> > > stack: 00000000 00000282 00000000 00000000 00000019
> c01d7d28
> > > 00000212 00000001
> > > 00000020 00000000 c01e7f4c c01d21ac 0a100000
> c0121a00
> > > c01d7d20 00000015
> > > c01f8083 00000282 00000000 00000000 00000000
> 00000e00
> > > c8000000 c8000000
> > > Call Trace: [<c0121a00>] [<c0120eb9>] [<c01a6880>]
> > [<c01060000>]
> > > [<e01a82fe>] [<c0106000>] [<c0106000>]
> > > [<c0106000>] [c0100175>]
> > >
> > > Code: 89 07 8b 3f 83 ee 01 73 ca c7 00 00 00 00
> fa
> > c7
> > > 45 08 2b
> > >
> > > Kernel Panic: Attempted to kill the idle task!
> > > In swapper task - not syncing
> > >
> >
> > Yay! Now that's a panic!
> >
> > OK, as you have kept all register informations, can you look at
> the
> > closest
> > downwards address of eip in System.map and see what function it
> > barfs in?
> >
It freaks out in kmem_cache_grow. I looked through it (note I did not
say I ran a debugger) and it has a do-while loop where it could
<possibly> trip.
So what does this all mean? Well, since most of us have kernels that are
smaller than all of memory it's got to work BUT my fyi about used memory
still troubles me. Since I'm not a kernel hack I'll leave it to others.
And no, I still have not tried it w/ 2.2.17
-----BEGIN GEEK CODE BLOCK-----
Version 3.12 (see http://www.geekcode.com for details)
GCS d- s: a C++$ ULAHS++++$ P+++$ L+++>++++$ E++>++++ W+(-) N+ o K? w---
O- !M-- V- PS+ PE+ Y+ PGP t 5- X- R- tv-->! b++ DI++ D+ G+ e++>++++ h*
r++ y++++
------END GEEK CODE BLOCK------
