Thinkpads Forum

After searching through the forum I didn't come across an answer to my situation. I've got a 600Ewith these specs:

2645-8BU

Power Mangement: v1.11
POST BIOS: v1.21
Video Verson: 1.15
Setup Version: 1.09
Slave Control: v1.08

Expansion Memory Details:

2 x 256MB Low Density (8 modules per side) PC-100 SODIMMS

Memory Info from BIOS setup screen

557056 Kb installed
032192 Kb useable

I received the laptop with the memory installed but I don't know if it ever worked - I had to update the BIOS to get it boot into W2K.

Any help or advise is greatly appreciated.

The 2645-8BU should be able to take both 256MB sticks. What's the part number of those sticks? If it's 33L3069 or 33L3070, they should work. If they don't, either the slots or the sticks are defective.

The RAM is not IBM. It's Silicon Mountain branded. Could that be the issue?

mudhead wrote:The RAM is not IBM. It's Silicon Mountain branded. Could that be the issue?

From reading their history on their web site, I don't see what/where they are getting the memory components. It appears they simply buy DRAM and assemble and test their own modules. Depending upon the source material (DRAM), the design of the printed circuit board (the "module"), and how they are being tested (which type of tester and to what specs), what works in one system can fail in another.

My advice would be to pull out both modules and run a memory diagnostic such as memtest86+. Verify that there is no problem with the on-board 32MB of memory. Then add in ONE module and retest. If it is identified properly (i.e., installed memory is 288MB and is all usable), then try the other module the same way (installed just by itself) using the SAME slot. Repeat the process for the second memory slot. What you are trying to do is figure out if there is a problem with a specific slot or with a particular module.

memtest86+ can be downloaded from here:

http://www.memtest.org

Ok, I had trouble running memtest, but I did run the internal diagnostic tool on each memory stick (in each slot) - The conclusion was that the memory was bad (or at least for this situation, non-compatible)

I substituted a 256MB stick of PC133 and it was recognized by BIOS but did not boot up. I suspect I need to edit the BIOS to disable the 32MB of onboard memory.

Update: After modifying the Hex value in BIOS, it would not boot. I pulled the CMOS battery to clear out the mod and now I'm back to square one.

Do you have another laptop available to install the 256MB modules and verify that they work in that system?

And you have mail!

To update this story so far and to fully explain everything for the curious: (skip to the last two paragraphs for the simple answer)

What I got today from mudhead are two Mitsubishi MH32S64APFB-7L PC100-222 modules. They are low density versions since they have 16 parts on them (8 per side).

They also have a Silicon Mountain label on them, which I take it to mean that Silicon Mountain has somehow obtained the modules and are selling it as "their own". There can be a number of reason why they are doing this. I don't know anything about this compnay even though I've been in the memory business (as a test engineer) for many years.

They work absolutely fine in both my 600X and T21 systems. Since those are PC100 (100Mhz) system bus computers that's no surprise. However, when they are inserted (singlely and together) into one of my 600E systems (PC66) they are declared not usable. There are NO error beeps or messages; only the on-board 32MB is available.

So, the $64,000 question is, why did they work in a fast system but not in a slower one? And what did I do to finally get them to work in my 600E? Okay, that's really TWO questions. I'll spill the beans, but first, a little refresher course for those of you who are not familiar with Synchronous Dynamic Memory (SDRAM):

SDRAM works in lock-step with the system bus speed, thus the definition of "synchronous". It also usually provides a "burst" of data. By that I mean, you give the memory a "starting address" and it returns a stream of data from consecutive memory locations. For example, you ask it for data starting from memory location 20 and it automatically provides you data from 20, 21, 22 and 23, without the need to explicitly give the memory those extra addresses. This is what makes SDRAM much more faster and efficient than regular, or asynchronous DRAM.

A PC100-rated module means that it has been tested and guaranteed to operate in a computer that has a 100Mhz memory system bus speed (aka front-side bus or FSB). Trying to put a PC100 module in a PC133 system is not advised because you would be running the memory faster than what it has been designed (and tested) for. On the other hand, what's wrong with putting a PC100 module in a slower system like the 600E, which uses a 66Mhz FSB? Can you not run memory slower? Generally the answer is "yes". However, the way that SDRAM works there's another specification to be aware of and that's "CAS latency".

Because we are dealing with SDRAM, access to the system memory takes place at precisely the same rate as the system clock. On a PC100 system, that clock is running at 100Mhz (megahertz or cycles per second). Doing the math, that works out to 10ns (nanosecond) clock cycles. This means that for a PC100 module, access to the data in memory occurs every 10ns. For the "faster" PC133 module, the figure is 7.5ns clock cycles and for the "slower" PC66 system timing, the clock cycle is 15ns. With me so far?

When the memory system receives a READ command (requesting access to some data that's in memory), there's a certain amount of delay time associated with getting that data. In the old days before SDRAM, when it was just (asynchonous) DRAM, this was known as "access time". The measure back then was from a system signal known as "CAS", which stands for "Column Address Strobe". To keep it simple, just think of the CAS signal as the point in time where the memory is finally "told" which address to get the piece of data from. Because of the physics involved and the design of the memory chip, there's going to be a finite amount of time before the memory can give out the requested piece of data. This is known throughout computerland as "CAS latency". I'm sure most of you have heard of this term. What is confusing if you haven't spent a lot of time with semiconductor memories, is what it really means. To put it succinctly, CAS latency is the number of system clock cycles that the computer must wait after giving a READ command to actually being able to use the FIRST piece of data. For CL2, that means two system clocks cycles must occur before the requested data is available. Similarly, CL3 means three clock cycles.

CL came about with the advent of SDRAM because of the inherent "CAS access time" issue. The specification of CAS access time is generally in the order to 15 to 22ns for these modules (PC66 to PC133). This time is independent of the system clock speed. In other words, a faster or slower FSB will not change the CAS access time. Rather, CL is the means by which the memory system is told how long (how many clock cycles) it has to wait to accomodate the CAS access time. Here's a couple of examples on what I mean:

Assume the memory has a given CAS access time, then these are the minimum values of CL that must be used and the reasoning why:

CAS access of 17ns
PC66........CL2....17ns is less than 2 clock cycles of 15ns (30ns)
PC100......CL2....17ns is less than 2 clock cycles of 10ns (20ns)
PC133......CL3....17ns is less than 3 clock cycles of 7.5ns (22.5ns)

CAS access of 21ns
PC66........CL2....21ns is less than 2 clock cycles of 15ns (30ns)
PC100......CL3....21ns is less than 3 clock cycles of 10ns (30ns)
PC133......CL3....21ns is less than 3 clock cycles of 7.5ns (22.5ns)

Why am I explaining all of this? This background is needed because of the fact that when SDRAM modules were first proposed, it was decided that an extra component be added to the memory module that allowed it to contain information about itself. This information normally is used by the computer so that it "knows" the capabilities of the memory module (size, speed, manufacturer, etc.). This is known as the SPD (Serial Presence Detect) bytes.

By definition, specific information is stored in dedicated areas of this SPD memory. CAS latency is just one of them. There are bits that can be toggled on and off which will tell the computer which CL the module supports, generally at the given or rated clock speed of the module (PC66, 100 or 133, for example).

So after all of this exposition, what was wrong with mudhead's modules? Simple. These two modules were declared as CL3 versions only! Somewhere along the line, the SPD information for the CL was changed. CL2 was removed as a supported condition and only CL3 was left, even though the label still has the PC100-222 marking (PC100 CL2). This means that for the systems which check the supported CL, the modules could only be used with CL3 systems. It now appears that the 600E does this check and it will only use modules that have CL2 enabled. Hopefully this will explain why some PC100 (and PC133) low density modules have not worked inside the 600E when conventional wisdom says they should have.

Oh, how did I "fix" the modules? I used a Windows-based, bench-top memory tester we have at work to read the entire contents of the SPD. You can then open a window, click a CL2 check box and then re-write the SPD information back into the module. Both modules have now run through a couple of complete passes of memtest86+ on my newest (366Mhz) 600E without any failures.

Nice work Ray!

Hey Ray.............

Do you give classes? I'm learning alot, just reading your answers.

Thanks,
Ron

Thanks for the detailed explanation, Ray! I've spent a number of hours over the years trying understand some of these memory issues, but I learned more reading through that single post than I learned after searching for hours on my own.

Phil.

Mudhead has PM'ed me to verify that the two modules are now working in his 600E. I've looked around the net but cannot find what I think I need, cheaply or for free. Does anybody know of a utility program that can read and WRITE SPD information from modules installed in a system? This may be kind of a "catch-22" situation in that if the module is not properly identified by the BIOS, how can you boot the system and access it? Fixing these kinds of problems would be easier to perform if all you had to do is download a program and run it. I know that CPU-Z appears to have the capability to read the SPD data. It doesn't work on my T23s as this chipset and/or SDRAM memory may not be supported. If I remember, the program does report SPD correctly for the A31 I use at work (DDR SDRAM memory) but doesn't allow changing it. I know of several module testers that connect to a computer and have this SPD editing capability, but the cost is prohibitive.

In any event, I have now seen four modules in the last couple of months that had messed up SPD information. All of the actual memory bits were working fine; the bad SPD info simply made the laptops reject the modules.

Ray, you sound like my grandpa when I ask him about electronics and the like. He used to be an electronics professor at a local college.

jamiphar wrote:Ray, you sound like my grandpa...

HEY! I'm not one yet!

rkawakami wrote:HEY! I'm not one yet!

Er, I didn't mean it to be an age crack....honest!

Ray.....all I can say is wow....my head is spinning after that explanation. Great explanation, but I must be too tired.

That was fantastic, Ray !

And even if my english is not fluent, I think I have understood everything.

Very Nice !

W.