XLT366 Memory Compatiblity...

XLT366 Memory Compatiblity...

[Ryan Kirkpatrick]

I recently purchased 16 identical 64MB SIMMs off of eBay for a pair of
XLT366s. These SIMMs have 36 chips, labeled 'HY5116100BT-6', which I
surmise are 60ns (from the '-6'), and a google search found they were
16Mbit in size. The SIMMs are parity (from the chip count). There is also
a sticker on one of chips that has '3163667/23BT S023039 64MB'. I was told
they came out of a Compaq Proliant server (don't know the model). All of
this seems to indicate they _should_ be compatible with the XLTs.

One XLT366 is able to post AlpahBIOS with either four or eight of these
SIMMs installed, and the memory count is either 256MB or 512MB
respectively. Yet, when I boot Linux, I get an endless stream of ECC
errors and corrections, slowing the system down so badly Linux is never
able to fully boot. AlphaBIOS version is 5.66.

The other XLT366 is only able to post AlphaBIOS with eight SIMMs
installed, only four results in a rapid sequence of beeps. Furthermore,
the memory count for all eight SIMMs is only 256MB, yet Linux is able to
boot and runs just fine, no ECC errors. AlphaBIOS version is 5.66.

I had always thought these two XLT366s were identical, but I noticed that
at least the memory retention clips are slightly different between the two
(one's are all plastic, other has metal clips). I also swapped SIMMs
between these two systems without any change to behavior.

Lastly, I tested them in a Sparc LX (which also takes 72pin parity
SIMMs). I installed the maximum of six SIMMs (384MB), and it was able to
see the maximum 96MB it supports. Furthermore it was able to boot and run
Linux without issue. It appears that as long as the SIMMs are not fully
utilized they work fine. When fully utilized, they just don't work.

Anyone have any clue what is going on here? I would very much like to have
my pair of XLT366s running with 512MB of RAM each. Am I missing something?
Is the memory incompatible (and if so, what memory is compatible)? Or is
the memory just plain bad? Thanks!

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------

Re: XLT366 Memory Compatiblity...

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

On Tue, 2004-06-08 05:46:54 -0600, Ryan Kirkpatrick <linux@rkirkpat.net>
wrote in message <Pine.LNX.4.21.0406080536550.13212-100000@magellan.rkirkpat.net>:
> 16Mbit in size. The SIMMs are parity (from the chip count). There is also

So they have an extra parity bit...

> a sticker on one of chips that has '3163667/23BT S023039 64MB'. I was told
> they came out of a Compaq Proliant server (don't know the model). All of
> this seems to indicate they _should_ be compatible with the XLTs.
> 
> One XLT366 is able to post AlpahBIOS with either four or eight of these
> SIMMs installed, and the memory count is either 256MB or 512MB
> respectively. Yet, when I boot Linux, I get an endless stream of ECC
> errors and corrections, slowing the system down so badly Linux is never
> able to fully boot. AlphaBIOS version is 5.66.

...but ECC requires more than one:)

> Lastly, I tested them in a Sparc LX (which also takes 72pin parity
> SIMMs). I installed the maximum of six SIMMs (384MB), and it was able to
> see the maximum 96MB it supports. Furthermore it was able to boot and run
> Linux without issue. It appears that as long as the SIMMs are not fully
> utilized they work fine. When fully utilized, they just don't work.

As I said, parity != ECC.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: XLT366 Memory Compatiblity...

[Thorsten Kranzkowski]

On Tue, Jun 08, 2004 at 02:52:50PM +0200, Jan-Benedict Glaw wrote:
> On Tue, 2004-06-08 05:46:54 -0600, Ryan Kirkpatrick <linux@rkirkpat.net>
> wrote in message <Pine.LNX.4.21.0406080536550.13212-100000@magellan.rkirkpat.net>:
> > 16Mbit in size. The SIMMs are parity (from the chip count). There is also
> 
> So they have an extra parity bit...
> 
> > a sticker on one of chips that has '3163667/23BT S023039 64MB'. I was told
> > they came out of a Compaq Proliant server (don't know the model). All of
> > this seems to indicate they _should_ be compatible with the XLTs.
> > 
> > One XLT366 is able to post AlpahBIOS with either four or eight of these
> > SIMMs installed, and the memory count is either 256MB or 512MB
> > respectively. Yet, when I boot Linux, I get an endless stream of ECC
> > errors and corrections, slowing the system down so badly Linux is never
> > able to fully boot. AlphaBIOS version is 5.66.
> 
> ...but ECC requires more than one:)
> 
> > Lastly, I tested them in a Sparc LX (which also takes 72pin parity
> > SIMMs). I installed the maximum of six SIMMs (384MB), and it was able to
> > see the maximum 96MB it supports. Furthermore it was able to boot and run
> > Linux without issue. It appears that as long as the SIMMs are not fully
> > utilized they work fine. When fully utilized, they just don't work.
> 
> As I said, parity != ECC.

well he said 36 chips which equals 4 bit ECC per 32 bit word.

Ryan, 
have you tried to find a set of 8 (or 4) that work together? maybe there 
are 'just' 2 bad sticks out of 16.

can you see a pattern in your endless stream of ECC errors? e.g. always the
same faulty bit? does this change when you swap them 2 sticks at a time? 

Does AlphaBIOS have an option to enable/disable ECC use? maybe it's running
with ECC off as long there's no OS loaded. Have you tried SRM?

You didn't write whether your XLT366 are ok with other (smaller) RAM?

Apart from the different memory sockets, are your boards identical? It's
unlikely but are the memory slots numbered a different way b/c of board
revisions?

ok, these are more questions than answers :) I hope they help you finding
the cause of your trouble.

Good luck!

> MfG, JBG

Bye,
Thorsten


-- 
| Thorsten Kranzkowski        Internet: dl8bcu@dl8bcu.de                      |
| Mobile: ++49 170 1876134       Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |

Re: XLT366 Memory Compatiblity...

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]

On Tue, 2004-06-08 17:56:12 +0000, Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
wrote in message <20040608175612.B31492@Marvin.DL8BCU.ampr.org>:
> On Tue, Jun 08, 2004 at 02:52:50PM +0200, Jan-Benedict Glaw wrote:
> > On Tue, 2004-06-08 05:46:54 -0600, Ryan Kirkpatrick <linux@rkirkpat.net>
> > wrote in message <Pine.LNX.4.21.0406080536550.13212-100000@magellan.rkirkpat.net>:
> > > One XLT366 is able to post AlpahBIOS with either four or eight of these
> > > SIMMs installed, and the memory count is either 256MB or 512MB
> > > respectively. Yet, when I boot Linux, I get an endless stream of ECC
> > > errors and corrections, slowing the system down so badly Linux is never
> > > able to fully boot. AlphaBIOS version is 5.66.
> > 
> > ...but ECC requires more than one:)
> > 
> > > Lastly, I tested them in a Sparc LX (which also takes 72pin parity
> > > SIMMs). I installed the maximum of six SIMMs (384MB), and it was able to
> > > see the maximum 96MB it supports. Furthermore it was able to boot and run
> > > Linux without issue. It appears that as long as the SIMMs are not fully
> > > utilized they work fine. When fully utilized, they just don't work.
> > 
> > As I said, parity != ECC.
> 
> well he said 36 chips which equals 4 bit ECC per 32 bit word.

Or one bit per byte... *digging up some RAM* Ah, these do have 10 or 20
chips, so that's 2 bits per byte (which I expected).

> | Thorsten Kranzkowski        Internet: dl8bcu@dl8bcu.de                      |
> | Mobile: ++49 170 1876134       Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
> | Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |

Melle? Not all that far away:) I'm from Hörste (near Halle/Westf.).

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: XLT366 Memory Compatiblity...

[Thorsten Kranzkowski]

On Tue, Jun 08, 2004 at 08:03:35PM +0200, Jan-Benedict Glaw wrote:
> On Tue, 2004-06-08 17:56:12 +0000, Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
> wrote in message <20040608175612.B31492@Marvin.DL8BCU.ampr.org>:
> > On Tue, Jun 08, 2004 at 02:52:50PM +0200, Jan-Benedict Glaw wrote:
> > > On Tue, 2004-06-08 05:46:54 -0600, Ryan Kirkpatrick <linux@rkirkpat.net>
> > > wrote in message <Pine.LNX.4.21.0406080536550.13212-100000@magellan.rkirkpat.net>:
> > > > utilized they work fine. When fully utilized, they just don't work.
> > > 
> > > As I said, parity != ECC.
> > 
> > well he said 36 chips which equals 4 bit ECC per 32 bit word.
> 
> Or one bit per byte... *digging up some RAM* Ah, these do have 10 or 20
> chips, so that's 2 bits per byte (which I expected).

Quoting from my DS20 manual (DP264 actually):

"The 72-bit, 100 MHz DIMMs consist of 64 Bits of data and 8 bits of ECC, ..."

These are 200 pin sticks which are definitely not found in PC World :)

I assume Ryans memory is bog-standard 72Pin-PS/2 (currently googling to 
find a proof) and also with that it's definitely 4bits/32bit. Quoting
from ref_memory.txt that describes my noname-board:

Table 3-1 Possible Memory Capacities

Organization  SIMM      Bank      BCR<SBE>   BCR<RAS>  BMR
              size      size
----------------------------------------------------------------
1 Mbit x 36   4 Mbyte   8 Mbyte   0          0011b     0070.0000
2 Mbit x 36   8 Mbyte   16 Mbyte  1          0011b     00F0.0000
[...]



Unfortunately most useful Alpha docs seem to be gone by today - the 
closest I could find is: 
http://hvdkooij.xs4all.nl/docs/RedHatLinuxAlpha/machinexlt.html 
which also suggests 36 Bit RAM.


Now I'm curious what kind of RAM-Sticks _you_ found in your black-box?
are all (10,20) chips of the same size and type? Any stickers that
suggest a clue?


> Melle? Not all that far away:) I'm from Hörste (near Halle/Westf.).

Ein freundliches Hallo nach Nordrhein Westfahlen! ;-)
 
> MfG, JBG

Bis denn,
Thorsten


-- 
| Thorsten Kranzkowski        Internet: dl8bcu@dl8bcu.de                      |
| Mobile: ++49 170 1876134       Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |
-
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: XLT366 Memory Compatiblity...

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

On Tue, 2004-06-08 19:32:37 +0000, Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
wrote in message <20040608193237.A31694@Marvin.DL8BCU.ampr.org>:
> I assume Ryans memory is bog-standard 72Pin-PS/2 (currently googling to 
> find a proof) and also with that it's definitely 4bits/32bit. Quoting
> from ref_memory.txt that describes my noname-board:

IIRC NoName (aka. AXPpci33) only uses parity, not ECC. Or am I wrong?

> Table 3-1 Possible Memory Capacities
> 
> Unfortunately most useful Alpha docs seem to be gone by today - the 
> closest I could find is: 
> http://hvdkooij.xs4all.nl/docs/RedHatLinuxAlpha/machinexlt.html 
> which also suggests 36 Bit RAM.
> 
> Now I'm curious what kind of RAM-Sticks _you_ found in your black-box?
> are all (10,20) chips of the same size and type? Any stickers that
> suggest a clue?

These were spare sticks which were initially ripped off some RS/6000,
IIRC. But I'd probably look into my PSW500au tomorrow...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: XLT366 Memory Compatiblity...

[Thorsten Kranzkowski]

On Tue, Jun 08, 2004 at 10:26:29PM +0200, Jan-Benedict Glaw wrote:
> On Tue, 2004-06-08 19:32:37 +0000, Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
> wrote in message <20040608193237.A31694@Marvin.DL8BCU.ampr.org>:
> > I assume Ryans memory is bog-standard 72Pin-PS/2 (currently googling to 
> > find a proof) and also with that it's definitely 4bits/32bit. Quoting
> > from ref_memory.txt that describes my noname-board:
> 
> IIRC NoName (aka. AXPpci33) only uses parity, not ECC. Or am I wrong?

unfortunately you are :)

From Digital AXPpci33 OEM Design Guide, chapter 1, table 1 on page 2:

External Cache		Configurable for 0, 256KB, or 1MB
			(64 data and ECC protection (8) bits, 20ns or 
			15ns access)

Memory Bus Width	64 data bits plus 8 ECC bits



> > Now I'm curious what kind of RAM-Sticks _you_ found in your black-box?
> > are all (10,20) chips of the same size and type? Any stickers that
> > suggest a clue?
> 
> These were spare sticks which were initially ripped off some RS/6000,

Do you know which model?

> IIRC. But I'd probably look into my PSW500au tomorrow...

Bye,
Thorsten

-- 
| Thorsten Kranzkowski        Internet: dl8bcu@dl8bcu.de                      |
| Mobile: ++49 170 1876134       Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |

Re: XLT366 Memory Compatiblity...

[Ryan Kirkpatrick]

On Tue, 8 Jun 2004, Thorsten Kranzkowski wrote:

> have you tried to find a set of 8 (or 4) that work together? maybe there 
> are 'just' 2 bad sticks out of 16.
> can you see a pattern in your endless stream of ECC errors? e.g. always the
> same faulty bit? does this change when you swap them 2 sticks at a time? 

Both good questions, I will not have time to test until this weekend, but
I will do so then and let you know the results. 

> Does AlphaBIOS have an option to enable/disable ECC use? maybe it's running
> with ECC off as long there's no OS loaded. Have you tried SRM?

I don't think AlphaBIOS has such an option, but I will look. Unfortunetly
SRM does not support XLTs as far as I know. I would dearly love to get rid
of AlphaBIOS. :)

> You didn't write whether your XLT366 are ok with other (smaller) RAM?

Yea, they run fine with their current memory, and have for a few
years. One had 8x32MB SIMMs, and the other had 8x16MB SIMMs, though after
the failure to get this new RAM to work, I balenced them with 4x32MB +
4x16MB SIMMs each. These working SIMMs each have 18 chips, and not Digital
branded memory.

> Apart from the different memory sockets, are your boards identical? It's
> unlikely but are the memory slots numbered a different way b/c of board
> revisions?

That's the funny thing. I was not able to find any difference in the board
revision labels. The stickers had identical numbers, same for one that
looked like a serial number, and even then only the last digit or two was
a bit different. But yes, other than the memory sockets, the boards are
completely identical.

> ok, these are more questions than answers :) I hope they help you finding
> the cause of your trouble.

Thanks for the help. I will do a bit more complete testing of SIMM
combinations this weekend. Though I am beginning to suspect that system
just does not care for 36 chip SIMMs, maybe too many chips to drive? TTYL.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------

Re: XLT366 Memory Compatiblity...

[Ryan Kirkpatrick]

On Wed, 9 Jun 2004, Ryan Kirkpatrick wrote:

> On Tue, 8 Jun 2004, Thorsten Kranzkowski wrote:
> 
> > have you tried to find a set of 8 (or 4) that work together? maybe there 
> > are 'just' 2 bad sticks out of 16.
> > can you see a pattern in your endless stream of ECC errors? e.g. always the
> > same faulty bit? does this change when you swap them 2 sticks at a time? 
> 
> Both good questions, I will not have time to test until this weekend, but
> I will do so then and let you know the results. 

Well, as all of my computer problems lately have been, it turned out to be
a combination of bad memory and memory incompatiblity. I was able to
isolate a single SIMM that was generating the parity/ECC errors. Without
that SIMM in the system, I was able to get eight SIMMs working just fine,
for a total of 512MB. 

But that was in just one of my XLT366s. The other one continued its
previous behavior, even with all good DIMMs. It refused to see more than
256MB with eight SIMMs. I have to conclude it is an older rev then the
other system, and that is just all it can see. Oh well.

> > You didn't write whether your XLT366 are ok with other (smaller) RAM?
> 
> Yea, they run fine with their current memory, and have for a few
> years. One had 8x32MB SIMMs, and the other had 8x16MB SIMMs, though after
> the failure to get this new RAM to work, I balenced them with 4x32MB +
> 4x16MB SIMMs each. These working SIMMs each have 18 chips, and not Digital
> branded memory.

And in the end, I gave the second system that is limited at 256MB the
8x32MB SIMMs, and it is quite happy. So, that leaves me with 8x16MB and
7x64MB SIMMs for the ever expanding spare computer part collection. :)

> > ok, these are more questions than answers :) I hope they help you finding
> > the cause of your trouble.

Thanks again for your help. And just through a last little mystery
in, those 16MB SIMMs I was using have 10 chips, and the 32MB SIMMs have 20
chips! Worse, not all of the chips are identical either! I think the
parity chips on these SIMMs are lower density than the memory chips, where
it takes two parity chips to match the size of the memory chips. Weird!

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------

Re: XLT366 Memory Compatiblity...

[Thorsten Kranzkowski]

On Mon, Jun 14, 2004 at 05:55:42AM -0600, Ryan Kirkpatrick wrote:
> a combination of bad memory and memory incompatiblity. I was able to
> isolate a single SIMM that was generating the parity/ECC errors. Without
> that SIMM in the system, I was able to get eight SIMMs working just fine,
> for a total of 512MB. 

smells like success :-)
 
> But that was in just one of my XLT366s. The other one continued its
> previous behavior, even with all good DIMMs. It refused to see more than
> 256MB with eight SIMMs. I have to conclude it is an older rev then the
> other system, and that is just all it can see. Oh well.

There might be a jumper and/or a Firmware switch hiding that may select
support of so-called 'double sided' RAM. This kind of RAM presents itself
as two memory banks on one memory stick to the mainboard. There were
mainboards that could support these by reducing the number of total sticks
by 1/2. (i.e. 8 'single sided' or 4 'double sided'). 
I have no idea whether Alphas ever had such limitations.
(And despite the name this has nothing to do with actual placement of chips.
there are actually 'single sided' sticks with chips on both sides of the PCB.
It has more to do with memory size: IIRC 1, 4, 16, 64 MByte sticks are single,
2, 8, 32 etc. are double)
 
> And in the end, I gave the second system that is limited at 256MB the
> 8x32MB SIMMs, and it is quite happy. So, that leaves me with 8x16MB and
> 7x64MB SIMMs for the ever expanding spare computer part collection. :)

Must be some kind of physical constant ;)

> Thanks again for your help. And just through a last little mystery
> in, those 16MB SIMMs I was using have 10 chips, and the 32MB SIMMs have 20
> chips! Worse, not all of the chips are identical either! I think the

I'd bet there are 8 (16) chips with 4 bits each and 2 (4) with 2 bits.

> parity chips on these SIMMs are lower density than the memory chips, where
> it takes two parity chips to match the size of the memory chips. Weird!

lower density, yes, and maybe a slight bit faster to help the ECC mechanism.
probably it was cheaper to use 2 smaller than 1 bigger chip of the faster 
kind.

bye,
Thorsten

-- 
| Thorsten Kranzkowski        Internet: dl8bcu@dl8bcu.de                      |
| Mobile: ++49 170 1876134       Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |

Re: XLT366 Memory Compatiblity...

[Ryan Kirkpatrick]

On Mon, 14 Jun 2004, Thorsten Kranzkowski wrote:

> On Mon, Jun 14, 2004 at 05:55:42AM -0600, Ryan Kirkpatrick wrote:
> > a combination of bad memory and memory incompatiblity. I was able to
> > isolate a single SIMM that was generating the parity/ECC errors. Without
> > that SIMM in the system, I was able to get eight SIMMs working just fine,
> > for a total of 512MB. 
> 
> smells like success :-)

Yes, it does. :) Though if I don't add a bit more cooling to the system
(i.e. a fan on or near the memory), its going to smell like cooked memory
chips. These DIMMs get awful hot!

> > But that was in just one of my XLT366s. The other one continued its
> > previous behavior, even with all good DIMMs. It refused to see more than
> > 256MB with eight SIMMs. I have to conclude it is an older rev then the
> > other system, and that is just all it can see. Oh well.
> 
> There might be a jumper and/or a Firmware switch hiding that may select
> support of so-called 'double sided' RAM.

Hmm... I will have to go looking. Though I am pretty sure one of my XLTs
is much older than the other. I acquired one (in mid-1998) about 2-3
years before the other (late-2000), though both were used. Thanks for the
idea though.

> > And in the end, I gave the second system that is limited at 256MB the
> > 8x32MB SIMMs, and it is quite happy. So, that leaves me with 8x16MB and
> > 7x64MB SIMMs for the ever expanding spare computer part collection. :)
> 
> Must be some kind of physical constant ;)

Oh good grief yes! I have an endless amount of spare computer parts,
including more than enough steel in the basement to keep my house from
going anywhere. :)

> > Thanks again for your help. And just through a last little mystery
> > in, those 16MB SIMMs I was using have 10 chips, and the 32MB SIMMs have 20
> > chips! Worse, not all of the chips are identical either! I think the
> 
> I'd bet there are 8 (16) chips with 4 bits each and 2 (4) with 2 bits.
> lower density, yes, and maybe a slight bit faster to help the ECC
> mechanism. probably it was cheaper to use 2 smaller than 1 bigger chip
> of the faster kind.

Agreed. TTYL.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------