# Dual Athlon + >1GB RAM = kernel oops

## jean-michel

I am trying to install a second GB of RAM into a dual athlon 2400-MP system (actually, several such systems) and am running into consistent issues with linux failing to boot or, after booting, crashing with kernel oopses and EIP messages (usually in the reiserfs section).

I have had this issue arrive on systems built with dual 2400-MP chips and iWill as well as Tyan motherboards, using Corsair PC2700 ECC RAM in various configurations, both from the LiveCD (RC4) and already installed gentoo-sources-r5 kernel.  I have also tried a custom built himem kernel, as well as passing "mem=1024M" to grub.  None of these approaches has made any difference.

Has anyone managed to get a Dual Athlon system to work with greater than 1 GB RAM?  If so, any help or pointers would be greatly appreciated.

Thanks in advance,

Jean.

----------

## rojaro

grad one of the current rc iso's, burn it, boot it and run memtest86 for a few hours to make sure your memory sticks arent faulty.

----------

## Luud

Hi Jean-Michel,

I have a Dual-Athlon MP 2400+ system based on a ASUS A7M266-D motherboard (MPX Chipset).

I have installed 1.5 GB of Kingston PC2100 ECC-REG memory (1x 1GB and 1x 512MB). Gentoo 1.4_r4 installed without any problems as did 1.4_r3 in the past.

Check if you are using buffered or unbuffered memory. Unbuffered can only be used up to 2 GB. That's why I chose the ECC-REG memory, I want to be able to upgrade to 3.5 GB in the future.

Also make sure your power supply is large enough. To be sure I chose a Enermax SilentPlus 550W. I connected all the power connectors to the motherboard as not to starve any components.

If you have verified that everything should be ok I think it is wise to run rojaro's test.

Good luck!

----------

## nadamsieee

I am having the same problem with a single processor Athlon 2500+ system with 1.25 GB (1280MB) of RAM. The solution (which causes a kernel panic for me) is to set the CONFIG_HIGHMEM4G option in the kernel, and recompile. You'll want to make sure you don't overwrite your old kernel with your new kernel, since your box may not boot with the new one. (Its always a good idea to test new kernels before making them the default). Here is my lilo.conf file which does this for me:

```
# Author: nadamsieee

# Start LILO global section

  boot = /dev/hda

  prompt

#  map = /boot/System.map

#  install=/boot/boot.b

  lba32

  timeout= 150

#  timeout= 1

  vga = normal  # Normal VGA console

  default = Gentoo

  root = /dev/hda5

  read-only

  menu-title = "Welcome to malliard"

# End LILO global section

# Linux bootable partition config begins

  # Default Gentoo Kernel

  image = /boot/bzDefault

    label = Gentoo

  # New Test Kernel

  image = /boot/bzTest

    label = Test

# Linux bootable partition config ends
```

Of course, the image labels need to match the actual file names of your kernels, and this example assumes you use lilo as your boot manager.

Also, depending on what you are trying to accomplish, enabling HIGHMEM may actually slow your system down whenever it access RAM above 1GB. This is because HIGHMEM causes the kernel to do virtual to physical mapping to see the higher addresses. You might think of it as a good example of why doing things in hardware is much faster than software.

Let us know if you get the HIGHMEM working. I'd like to build and be able to choose at boot time a kernel that can see the extra RAM on my system. I might name it /boot/bzVideoEdit or something.   :Smile: 

----------

## dberkholz

I have an Athlon 2000+ MP dual system with 1 GB Corsair ECC, and HIGHMEM also does not work for me with gentoo-sources, so I'm stuck with 844MB (or whatever) until I can make it happen. In fact I filed a bug on it. Please feel free to add on to that bug. https://bugs.gentoo.org/show_bug.cgi?id=21742

----------

## jean-michel

Thanks to everyone who lent a hand on this.

SOLUTION: I upgraded my processors (to dual 2800+ MPs) and my motherboard (dumping the iWill board for a Tyan S2466N-4M) after noticing that 1.5 GB of the exact same memory worked just fine with their 2600+ MPs and the aforementioned motherboard.  I suspect the issue may have been tied in some way to the 2400+ MP chips, but am not certain.

 :Question:  I do not know the exact cause, but it wasn't memory sticks (I tested with numerous different memory sticks, of different makes and models including a number of Corsair, always with the same problem).  It may have been the motherboard (although I had similiar problems with an earlier rev of the Tyan board mentioned above, even with a current flashed bios).  The common denominator however was 2400+ MPs, so I'm wondering if there wasn't a peculiar chip limitation, or combination of the above.  In any event, the new motherboard and chips were the ticket ... the exact same memory now works perfectly in all 4 DIMM slots, for a total of 2GB.  Go figure.

Some notes on software:

 :Arrow:  booting into a kernel without HIMEM support worked just fine (once I got the memory working, no more kernel ooopses of any kind), but memory was limited to 900MB or so.   

 :Arrow:  I stress tested this by compiling a new kernel with HIMEM support (4GB, 3.5GB user ... anyone know of a good doc on what the tradeoffs are for 3.5GB v. 3 GB user?), and emerging all of the dependent stuff (lm-sensors, xfree-drm, iptables, alsa-driver, etc.) with complete success (and jaw-dropping speed despite the memory limitation  :Smile: ).   So a lowmem kernel SHOULD work even on a machine with more than 1GB of RAM, it merely denies you access to the higher memory.

 :Arrow:  I then rebooted under the new kernel with himem support and could see and use all 2GB.  Very, very sweet.  :Very Happy: 

Again, many thanks.  Just knowing it worked for some people helped me to persist.

----------

## nadamsieee

 *Quote:*   

> I do not know the exact cause, but it wasn't memory sticks (I tested with numerous different memory sticks, of different makes and models including a number of Corsair, always with the same problem). It may have been the motherboard (although I had similiar problems with an earlier rev of the Tyan board mentioned above, even with a current flashed bios). The common denominator however was 2400+ MPs, so I'm wondering if there wasn't a peculiar chip limitation, or combination of the above. In any event, the new motherboard and chips were the ticket ... the exact same memory now works perfectly in all 4 DIMM slots, for a total of 2GB. Go figure.

 

My HIGHMEM4G kernel b0rks at boot up. I have a single Athlon XP 2500+ CPU and a Gigabyte mobo. Does anyone know where boot messages are logged?

 *Quote:*   

> booting into a kernel without HIMEM support worked just fine (once I got the memory working, no more kernel ooopses of any kind), but memory was limited to 900MB or so.

 

This is what I'm doing now. I have 1.25GB of physical RAM but my non-HIGHMEM4G kernel only recognizes the first 881.54MB.

 *Quote:*   

> I stress tested this by compiling a new kernel with HIMEM support (4GB, 3.5GB user ... anyone know of a good doc on what the tradeoffs are for 3.5GB v. 3 GB user?), and emerging all of the dependent stuff (lm-sensors, xfree-drm, iptables, alsa-driver, etc.) with complete success (and jaw-dropping speed despite the memory limitation ). So a lowmem kernel SHOULD work even on a machine with more than 1GB of RAM, it merely denies you access to the higher memory.
> 
> I then rebooted under the new kernel with himem support and could see and use all 2GB. Very, very sweet. 

 

Did you time the first compile with the non-HIGHMEM4G kernel? If not, could maybe try booting into the old non-HIGHMEM4G kernel and time it? If you've already timed the old kernel, would you mind doing the exact same compile with the new HIGHMEM4G kernel and post the comparison here? Your extra RAM might actually make things slower (see the links in my previous reply in this thread).

 *Quote:*   

> anyone know of a good doc on what the tradeoffs are for 3.5GB v. 3 GB user?

 

To quote Daniel Robbins:

 *Quote:*   

> The new Gentoo Linux kernel also includes Andrea Archangeli's excellent 3.5GB user address space patch. This patch allows users to customize how Linux divides the system's user and kernel address space. Normally, there is a 3-to-1 ratio between user and kernel memory. A 32-bit Linux kernel thus can only "see" up to 960MB (~1GB) of RAM, with user processes accessing up to 3GB of virtual memory. By using a 3.5U/0.5K or 2U/2K divide, users can choose a balance that better suits the intended use and hardware configuration of their system. For example, a 2U/2K divide will allow a 32-bit Linux kernel to "see" 1960MB of RAM (~2GB) even without enabling "highmem" support. Alternately, a 3.5U/0.5K split plus highmem support can allow VM-hungry applications to access up to 3.5GB of virtual memory while still allowing (thanks to highmem) access to multiple gigabytes of physical RAM. This patch is tremendously helpful for developers who push 32-bit systems to their limits. This patch is also invaluable for those writing applications that need to access more than 3GB of virtual memory. For those interested in trying out this patch, you can find it in one of the kernel directories at http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/.

 

----------

## dberkholz

 *nadamsieee wrote:*   

>  Your extra RAM might actually make things slower (see the links in my previous reply in this thread).

 

My impression is that this is designed to stop that slowdown: 

 *make menuconfig wrote:*   

> 
> 
> (4GB) High Memory Support    
> 
> (3GB) User address space size       
> ...

 

 *HIGHMEM I/O support Help wrote:*   

> 
> 
> CONFIG_HIGHIO:  
> 
> If you want to be able to do I/O to high memory pages, say Y. Otherwise low memory pages are used as bounce buffers causing a degrade in performance.

 

----------

## nadamsieee

The thread is about HIGHMEM4G not HIGHIO. Two separate topics.   :Smile: 

Please clicky my previous links:

http://www.ussg.iu.edu/hypermail/linux/kernel/0211.0/1137.html

http://strasbourg.linuxfr.org/jl3/features-2.3-2.html

----------

## McManus

 *jean-michel wrote:*   

> Thanks to everyone who lent a hand on this.
> 
> SOLUTION: I upgraded my processors (to dual 2800+ MPs) and my motherboard (dumping the iWill board for a Tyan S2466N-4M) after noticing that 1.5 GB of the exact same memory worked just fine with their 2600+ MPs and the aforementioned motherboard.  I suspect the issue may have been tied in some way to the 2400+ MP chips, but am not certain.
> 
> 

 

Odd...   I was about to say, I am having the same problems as you (system crashing all over the place when I use a HIGHMEM vanilla kernel), yet I have the Tyan Tiger MPX S2466N-4M as well.  I am using 1 GB of memory (2x512 in slot 0 and slot 2, you could also say first and third slot, affectionately).  

One thing I have noticed, though, is that different BIOS revisions from Tyan for our board have varying stability levels.  Some of the earlier ones have been rock-solid for me, but I don't remember which ones   :Very Happy:    Out of curiosity, which BIOS revision are you using?  I'm using the latest stable BIOS (4.05).

If nothing works, I may have to resort to upgrading my CPUs to dual 2800+ MPs (or maybe 3000+ MPs if they come out soon   :Wink: )

Thanks!

----------

## McManus

I also forgot to mention, I'm using ECC PC2100 DDR RAM.  

Oh, and while I'm at it, what BIOS settings do you have set?  (Like, ECC options, AGP Strength, MP Revision, etc.)

I've got AGP Strength to FFa, ECC set to ECC (not to Scrub..  that seems to help crash the system faster),  MP Revision 1.4, oh, and AGP FastWrites off.

----------

## dberkholz

HIGHMEM recently started working on my system using the latest gentoo-sources (-r7 or so, maybe -r6, I'm not at my computer now). Yay!

----------

