This is in regards to that Gutsy machine with 8 GB of RAm and 32 bit
OS. I am fairly sure of what happened. Someone from kerneltrap fully
clarified it for me.

What happened is though the machine had 8 GB of RAM, it had only 800
MB of "lowmem" (as opposed to "highmem". Lowmem is used for storing
kernel structures, and for some reason the machine ran out of it and
then bad things started happening.

What to do to fix it (other than install 64 bit, etc) is unclear, but
what is clear is what happens. I will try to read on optimizing
lowmem use. I will also try to find some tools to monitor availability
(or lack thereof) of lowmem.

--
Due to extreme spam originating from Google Groups, and their inattention
to spammers, I and many others block all articles originating
from Google Groups. If you want your postings to be seen by
more readers you will need to find a different means of
posting on Usenet.
http://improve-usenet.org/

Ignoramus14558 wrote:

> This is in regards to that Gutsy machine with 8 GB of RAm and 32 bit
> OS. I am fairly sure of what happened. Someone from kerneltrap fully
> clarified it for me.
>
> What happened is though the machine had 8 GB of RAM, it had only 800
> MB of "lowmem" (as opposed to "highmem". Lowmem is used for storing
> kernel structures, and for some reason the machine ran out of it and
> then bad things started happening.
>
Mmmhm. That reminds me of Good Old DOS and squeezing network drivers and
TSRs into high memory to keep as much lowmem (640_K_Bytes maxed) as
possible.

> What to do to fix it (other than install 64 bit, etc) is unclear, but
> what is clear is what happens. I will try to read on optimizing
> lowmem use. I will also try to find some tools to monitor availability
> (or lack thereof) of lowmem.
>
There are kernel .config options for vmsplit,
here the interesting block:
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_3G_OPT is not set
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_2G_OPT is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y

for my plain standard 4G kernel.
You may have it configured for 2G lowmem as well, as I can tell from the
menuconfig options.

Ignoramus14558 wrote:
> This is in regards to that Gutsy machine with 8 GB of RAm and 32 bit
> OS. I am fairly sure of what happened. Someone from kerneltrap fully
> clarified it for me.
>
> What happened is though the machine had 8 GB of RAM, it had only 800
> MB of "lowmem" (as opposed to "highmem". Lowmem is used for storing
> kernel structures, and for some reason the machine ran out of it and
> then bad things started happening.

That is very strange. Below is how my /var/log/dmesg file starts out. I,
too, have only 896 MB of LOWMEM available, and 7424 MB of HIGHMEM. Mine is a
32-bit dual Xeon system with E7501 chip set. I did not have to do anything
to the Red Hat Enterprise Linux 2.6.18-92.1.6.el5PAE kernel.
>
> What to do to fix it (other than install 64 bit, etc) is unclear, but
> what is clear is what happens. I will try to read on optimizing
> lowmem use. I will also try to find some tools to monitor availability
> (or lack thereof) of lowmem.

It is not clear that that is what needs fixing, since my machine has similar
numbers and has run for over 4 years, almost 24/7 the whole time, and never
run out. Could some application make system requests that use up LOWMEM? It
seems unlikely to me that this is a kernel problem.
>
Linux version 2.6.18-92.1.6.el5PAE (brewbuilder@hs20-bc2-3.build.redhat.com)
(gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)) #1 SMP Fri Jun 20 02:51:01
EDT 2008
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000d2000 - 00000000000d4000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000f7ef0000 (usable)
BIOS-e820: 00000000f7ef0000 - 00000000f7ef8000 (ACPI data)
BIOS-e820: 00000000f7ef8000 - 00000000f7f00000 (ACPI NVS)
BIOS-e820: 00000000f7f00000 - 00000000f7f80000 (usable)
BIOS-e820: 00000000f7f80000 - 00000000f8000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved)
BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000208000000 (usable)
7424MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f6800
Using x86 segment limits to approximate NX protection
On node 0 totalpages: 2129920
DMA zone: 4096 pages, LIFO batch:0
Normal zone: 225280 pages, LIFO batch:31
HighMem zone: 1900544 pages, LIFO batch:31


--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 05:15:02 up 1 day, 10:03, 4 users, load average: 4.26, 4.26, 4.20

Jean-David Beyer wrote:
> Ignoramus14558 wrote:
>> This is in regards to that Gutsy machine with 8 GB of RAm and 32 bit
>> OS. I am fairly sure of what happened. Someone from kerneltrap fully
>> clarified it for me.
>>
>> What happened is though the machine had 8 GB of RAM, it had only 800
>> MB of "lowmem" (as opposed to "highmem". Lowmem is used for storing
>> kernel structures, and for some reason the machine ran out of it and
>> then bad things started happening.
>
> That is very strange. Below is how my /var/log/dmesg file starts out. I,
> too, have only 896 MB of LOWMEM available, and 7424 MB of HIGHMEM. Mine is a
> 32-bit dual Xeon system with E7501 chip set. I did not have to do anything
> to the Red Hat Enterprise Linux 2.6.18-92.1.6.el5PAE kernel.
>> What to do to fix it (other than install 64 bit, etc) is unclear, but
>> what is clear is what happens. I will try to read on optimizing
>> lowmem use. I will also try to find some tools to monitor availability
>> (or lack thereof) of lowmem.
>
> It is not clear that that is what needs fixing, since my machine has similar
> numbers and has run for over 4 years, almost 24/7 the whole time, and never
> run out. Could some application make system requests that use up LOWMEM? It
> seems unlikely to me that this is a kernel problem.

No idea, but if kernel memory is being used up its normally a driver
with a memory leak.

that, or a hardware fault.

So first check all fans are still running etc.

If that doesn't clear it, it might be worth rejigging/upgrading the
drivers somehow..

My plan for now is to explore a) upgrade to Hardy and b) upgrade to 64
bit Hardy.

I am fairly sure that it is a kernel bug.

i

On 2008-07-22, Jean-David Beyer <jeandavid8@verizon.net> wrote:
> wisdomkiller & pain wrote:
>> Ignoramus14558 wrote:
>>
>>> This is in regards to that Gutsy machine with 8 GB of RAm and 32 bit
>>> OS. I am fairly sure of what happened. Someone from kerneltrap fully
>>> clarified it for me.
>>>
>>> What happened is though the machine had 8 GB of RAM, it had only 800
>>> MB of "lowmem" (as opposed to "highmem". Lowmem is used for storing
>>> kernel structures, and for some reason the machine ran out of it and
>>> then bad things started happening.
>>>
>> Mmmhm. That reminds me of Good Old DOS and squeezing network drivers and
>> TSRs into high memory to keep as much lowmem (640_K_Bytes maxed) as
>> possible.
>>
>>> What to do to fix it (other than install 64 bit, etc) is unclear, but
>>> what is clear is what happens. I will try to read on optimizing
>>> lowmem use. I will also try to find some tools to monitor availability
>>> (or lack thereof) of lowmem.
>>>
>> There are kernel .config options for vmsplit,
>> here the interesting block:
>> # CONFIG_NOHIGHMEM is not set
>> CONFIG_HIGHMEM4G=y
>> # CONFIG_HIGHMEM64G is not set
>> CONFIG_VMSPLIT_3G=y
>> # CONFIG_VMSPLIT_3G_OPT is not set
>> # CONFIG_VMSPLIT_2G is not set
>> # CONFIG_VMSPLIT_2G_OPT is not set
>> # CONFIG_VMSPLIT_1G is not set
>> CONFIG_PAGE_OFFSET=0xC0000000
>> CONFIG_HIGHMEM=y
>>
>> for my plain standard 4G kernel.
>> You may have it configured for 2G lowmem as well, as I can tell from the
>> menuconfig options.
>>
>
> Mine for my 8GByte machine is:
>
> # CONFIG_NOHIGHMEM is not set
> # CONFIG_HIGHMEM4G is not set
> CONFIG_HIGHMEM64G=y
> CONFIG_PAGE_OFFSET=0xC0000000
> CONFIG_HIGHMEM=y
> CONFIG_X86_PAE=y
> # CONFIG_NUMA is not set
> CONFIG_SELECT_MEMORY_MODEL=y
> CONFIG_FLATMEM_MANUAL=y
> # CONFIG_DISCONTIGMEM_MANUAL is not set
> # CONFIG_SPARSEMEM_MANUAL is not set
> CONFIG_FLATMEM=y
> CONFIG_FLAT_NODE_MEM_MAP=y
> # CONFIG_SPARSEMEM_STATIC is not set
> CONFIG_SPLIT_PTLOCK_CPUS=4096
> CONFIG_RESOURCES_64BIT=y
> CONFIG_HIGHPTE=y
>
>

--
Due to extreme spam originating from Google Groups, and their inattention
to spammers, I and many others block all articles originating
from Google Groups. If you want your postings to be seen by
more readers you will need to find a different means of
posting on Usenet.
http://improve-usenet.org/

On 2008-07-22, Jean-David Beyer <jeandavid8@verizon.net> wrote:
> Ignoramus14558 wrote:
>> This is in regards to that Gutsy machine with 8 GB of RAm and 32 bit
>> OS. I am fairly sure of what happened. Someone from kerneltrap fully
>> clarified it for me.
>>
>> What happened is though the machine had 8 GB of RAM, it had only 800
>> MB of "lowmem" (as opposed to "highmem". Lowmem is used for storing
>> kernel structures, and for some reason the machine ran out of it and
>> then bad things started happening.
>
> That is very strange. Below is how my /var/log/dmesg file starts out. I,
> too, have only 896 MB of LOWMEM available, and 7424 MB of HIGHMEM. Mine is a
> 32-bit dual Xeon system with E7501 chip set. I did not have to do anything
> to the Red Hat Enterprise Linux 2.6.18-92.1.6.el5PAE kernel.

I also start a day with that much lowmem, but the amount of available
lowmem declines by 400 kb every minute.

http://igor.chudov.com/tmp/lowmem.txt

>> What to do to fix it (other than install 64 bit, etc) is unclear, but
>> what is clear is what happens. I will try to read on optimizing
>> lowmem use. I will also try to find some tools to monitor availability
>> (or lack thereof) of lowmem.
>
> It is not clear that that is what needs fixing, since my machine has similar
> numbers and has run for over 4 years, almost 24/7 the whole time, and never
> run out. Could some application make system requests that use up LOWMEM? It
> seems unlikely to me that this is a kernel problem.

seems to decline even without our apps running.

i

> Linux version 2.6.18-92.1.6.el5PAE (brewbuilder@hs20-bc2-3.build.redhat.com)
> (gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)) #1 SMP Fri Jun 20 02:51:01
> EDT 2008
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
> BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000d2000 - 00000000000d4000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000f7ef0000 (usable)
> BIOS-e820: 00000000f7ef0000 - 00000000f7ef8000 (ACPI data)
> BIOS-e820: 00000000f7ef8000 - 00000000f7f00000 (ACPI NVS)
> BIOS-e820: 00000000f7f00000 - 00000000f7f80000 (usable)
> BIOS-e820: 00000000f7f80000 - 00000000f8000000 (reserved)
> BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved)
> BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 0000000208000000 (usable)
> 7424MB HIGHMEM available.
> 896MB LOWMEM available.
> found SMP MP-table at 000f6800
> Using x86 segment limits to approximate NX protection
> On node 0 totalpages: 2129920
> DMA zone: 4096 pages, LIFO batch:0
> Normal zone: 225280 pages, LIFO batch:31
> HighMem zone: 1900544 pages, LIFO batch:31
>
>

--
Due to extreme spam originating from Google Groups, and their inattention
to spammers, I and many others block all articles originating
from Google Groups. If you want your postings to be seen by
more readers you will need to find a different means of
posting on Usenet.
http://improve-usenet.org/

On 2008-07-22, The Natural Philosopher <a@b.c> wrote:
> Jean-David Beyer wrote:
>> Ignoramus14558 wrote:
>>> This is in regards to that Gutsy machine with 8 GB of RAm and 32 bit
>>> OS. I am fairly sure of what happened. Someone from kerneltrap fully
>>> clarified it for me.
>>>
>>> What happened is though the machine had 8 GB of RAM, it had only 800
>>> MB of "lowmem" (as opposed to "highmem". Lowmem is used for storing
>>> kernel structures, and for some reason the machine ran out of it and
>>> then bad things started happening.
>>
>> That is very strange. Below is how my /var/log/dmesg file starts out. I,
>> too, have only 896 MB of LOWMEM available, and 7424 MB of HIGHMEM. Mine is a
>> 32-bit dual Xeon system with E7501 chip set. I did not have to do anything
>> to the Red Hat Enterprise Linux 2.6.18-92.1.6.el5PAE kernel.
>>> What to do to fix it (other than install 64 bit, etc) is unclear, but
>>> what is clear is what happens. I will try to read on optimizing
>>> lowmem use. I will also try to find some tools to monitor availability
>>> (or lack thereof) of lowmem.
>>
>> It is not clear that that is what needs fixing, since my machine has similar
>> numbers and has run for over 4 years, almost 24/7 the whole time, and never
>> run out. Could some application make system requests that use up LOWMEM? It
>> seems unlikely to me that this is a kernel problem.
>
> No idea, but if kernel memory is being used up its normally a driver
> with a memory leak.

That's my hypothesis.

i

> that, or a hardware fault.
>
> So first check all fans are still running etc.
>
> If that doesn't clear it, it might be worth rejigging/upgrading the
> drivers somehow..

--
Due to extreme spam originating from Google Groups, and their inattention
to spammers, I and many others block all articles originating
from Google Groups. If you want your postings to be seen by
more readers you will need to find a different means of
posting on Usenet.
http://improve-usenet.org/

Ignoramus2245 wrote:
> My plan for now is to explore a) upgrade to Hardy and b) upgrade to 64
> bit Hardy.

I forget what hardware you have. Can you run a 64-bit software (especially
the kernel) on a 32-bit machine?
>
> I am fairly sure that it is a kernel bug.
>
If there is a kernel bug, I would have thought there would be a lot more
complaints.

I have been running this machine for several years now with 8 GB RAM and
have never run out of any kind of memory.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 19:35:01 up 2 days, 23 min, 4 users, load average: 4.14, 4.02, 4.00

On 2008-07-22, Jean-David Beyer <jeandavid8@verizon.net> wrote:
> Ignoramus2245 wrote:
>> My plan for now is to explore a) upgrade to Hardy and b) upgrade to 64
>> bit Hardy.
>
> I forget what hardware you have. Can you run a 64-bit software (especially
> the kernel) on a 32-bit machine?

The machine is 64 bit compatible. IA64.

>> I am fairly sure that it is a kernel bug.
>>
> If there is a kernel bug, I would have thought there would be a lot more
> complaints.

> I have been running this machine for several years now with 8 GB RAM and
> have never run out of any kind of memory.

I think that it is a bug in some special driver.
--
Due to extreme spam originating from Google Groups, and their inattention
to spammers, I and many others block all articles originating
from Google Groups. If you want your postings to be seen by
more readers you will need to find a different means of
posting on Usenet.
http://improve-usenet.org/

Ignoramus2245 wrote:
> On 2008-07-22, Jean-David Beyer <jeandavid8@verizon.net> wrote:
>> Ignoramus2245 wrote:
>>> My plan for now is to explore a) upgrade to Hardy and b) upgrade to 64
>>> bit Hardy.
>> I forget what hardware you have. Can you run a 64-bit software (especially
>> the kernel) on a 32-bit machine?
>
> The machine is 64 bit compatible. IA64.
>
>>> I am fairly sure that it is a kernel bug.
>>>
>> If there is a kernel bug, I would have thought there would be a lot more
>> complaints.
>
>> I have been running this machine for several years now with 8 GB RAM and
>> have never run out of any kind of memory.
>
> I think that it is a bug in some special driver.

That is possible: I have no special drivers. I try to use SCSI for most
things. My hard drives are all drivers on one machine, and the only non-SCSI
hard drive on the other machine is EIDE. Even my CD-ROM burner is SCSI. And
my printer is USB. My networking are PCI cards or Intel 82546EB dual-channel
chip on motherboard. So all mid-age technology and standard. I do not have
fancy video or sound boards, and little else.

So if you need special drivers, I agree that that is the place to look.
Is there a possibility of removing the special drivers, replacing them with
nothing, and running the machine a while to see if the problem goes away? Or
are they vital to too much of what you are doing?

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 05:55:01 up 2 days, 10:43, 4 users, load average: 4.14, 4.08, 4.03