Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


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

New box does not load BIOS



Chris Ampenberger, wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I don't know much about modern RAM, but what kind of RAM do you use? Is it single
> channel DDR? I believe you said the Mobo is a A7N8X-X. This board only supports single
> channel DDR. Not sure whether you can even physically plug in dual channel in a single
> channel board and what will happen, if you can.

As I understand it, all that "dual channel DDR" means is that the DIMMs 
have to be installed in pairs, and the motherboard accesses both modules 
in parallel, thus getting a 128-bit memory path instead of 64-bit. RAM 
manufacturers sell matched pairs of DIMMs as dual channel (and if you're 
installing memory in a dual channel motherboard, such matched pairs are 
recommended; you can get hard-to-find flakiness if you use mismatched 
memory), but they will simply work as two ordinary modules in a 
motherboard that doesn't support dual-channel access.

Another possible RAM issue is unbuffered vs. registered SDRAM. (This one 
can apply both to DDR SDRAM on new motherboards, or regular SDRAM on 
older ones.) In registered SDRAM, there is a register on the module that 
acts as a buffer between the motherboard and the RAM. In unbuffered 
SDRAM, the motherboard interacts directly with the memory chips. 
Registered SDRAM is commonly used in servers; the buffers reduce the 
number of chips that the motherboard has to drive (only one per module 
instead of N, where N is the number of memory chips on the module), and 
thus allow the use of more memory modules. Unbuffered DRAM can be faster 
(no overhead for the buffer register), but you can use only a limited 
number of modules. ECC modules are just about always registered, since 
they are mostly used in servers.

Many motherboards support both types (registered and unbuffered), and 
automatically detect which type you have installed. Server motherboards 
with more than four DIMM sockets, most dual-processor motherboards, and 
all Opteron motherboard that I know of, usually only support registered 
memory.

IMPORTANT!!! Cheap desktop motherboards sometimes only support 
unbuffered memory, and will refuse to boot if you install registered 
DIMMs. (This is where all the background was leading.)

If you don't already know, and if the module doesn't have any useful 
labels on it, you can usually tell whether a module is unbuffered or 
registered by visual inspection. An unbuffered module will have a row of 
big chips, all the same size, and one very small chip which is usually 
at one end of the row of big chips. (The big chips are the memory; the 
small chip is the SPD chip, which identifies the size and speed of the 
module. Really old PC66 SDRAM modules may not have an SPD chip.) A 
registered module will have a row of big chips, and below them (closer 
to the card edge fingers) another row of a lesser number of smaller 
chips (but not as small as the SPD chip); those smaller chips are the 
registers. Again, there will be a very small chip at one end of the row 
of big chips. Either type may have another row of large memory chips on 
the other side of the module. The really itty-bitty parts on a memory 
module are resistors and capacitors; you can ignore them for the 
purposes of this discussion.

You can also usually distinguish an ECC module by looking. If your 
module either has an odd number of memory chips on each side of the 
module (most commonly 9 rather than 8 on SDRAM modules), or has a mix of 
two different sizes of memory chip, it is an ECC module. ECC modules 
will work on motherboards that lack ECC support (so long as they support 
registered modules), but you will get no advantage from them in that case.




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org