When chips go bad

Doghouse – Chip Replacement

Article from Issue 209/2018
Author(s):

Chip replacement isn’t always the answer.

Last month, I wrote about the Meltdown and Specter issues. The vendors and the community are working hard to evaluate the whole problem and see what types of solutions exist.

Many people are demanding that the chips be replaced. While this would be wonderful, in reality it is unlikely to ever happen, for many reasons.

This problem has been going on a long time, over many iterations of chips. The fabrication plants for creating the older chips have started making more modern chips. Going back in time to replace these older chips would be difficult, and even if the chip makers could do that, many of the chips are soldered to the motherboard. Removing the chip from the motherboard and resoldering it would be very expensive. Even if replacing the chips could be done, unless the chip is an exact replacement, the motherboard circuitry could be different, and the instructions to boot and run the operating system would have to change.

Perhaps it is a more modern chip, manufactured only a short time ago. The customer would have to identify the chip, find out if it is indeed affected, and submit that chip to the vendor to replace. Many of the same issues would exist, although the operating system might still be adaptable to the newer chip.

Another Time and Place

VAXstation 3100 computer systems were desktop computers designed by Digital Equipment Corporation (DEC) around 1986, one of DEC's first forays into "high volume" manufacture, which then measured in hundreds of thousands, not hundreds of millions.

DEC had a whole team of engineers on this product. Hardware circuitry, case design, manufacturing engineers, and of course both VMS and Ultrix (DEC's Unix product) engineers. We met every week in a project meeting.

This product utilized daughter cards for the RAM memory, way before the concept of industry standard SIMMs of memory. DEC had used memory chips from two different Japanese memory manufacturers. Not wanting to be too "cutting edge," DEC used memory chips that were shipping in the millions of units all over the world to many manufacturers, including DEC. The VAXstation 3100 was also the first system that DEC created that had only parity error detection, not ECC correctable memory.

The systems were headed toward field test. Because this was such an important product, there were a huge number of units made, not the typical 20-30 field test units that a larger system might have generated.

As the units were being readied to field test, it was noticed that Ultrix kept crashing while VMS was rock solid. The hardware engineers made comments about how terrible the Ultrix code was.

We eventually proved that the memory chips from one of the Japanese memory vendors was "forgetting," even though it was being properly clocked and fed the right amount of electricity – something that was not supposed to happen. If you did not read or write to that company's memory chip for over 45 seconds, it "forgot." Not all the time … only about half the time.

Wait! Why only Ultrix and not VMS? Because VMS always read into memory from disk when it was swapping in a swapped-out process. This was "refreshed" RAM that had not been written to for a long period. Unix (and Ultrix) realized that if the RAM had not been changed, what was the sense of "refreshing" it, since it still contained the information it had before? Right?

We brought in the Japanese firm and proved to them what was happening. That was when I learned the Japanese words that could not be printed here.

Wait a minute! Why had this not shown up before in those millions and millions of other systems with that vendor's chips?

Most servers of the day had ECC correctable memory. If one chip forgot, the others recreated the missing bit, called a "soft hit," something only noticeable if you looked for it in the system log.

PCs (which only had parity memory detection, not ECC correction) usually ran with small, active memories, so the chips were always being accessed. And if the system did crash, it was probably due to that crappy Microsoft operating system, right?

The memory company begged us not to announce this. DEC decided not to announce it, since it literally would bankrupt the memory company, which would have solved nothing. DEC did insist they buy back every chip they had ever sold us for the price we paid, and when the fix was done, replace the chips at current market price. The difference in price allowed DEC to replace every chip in every board owned by DEC's customers (including manufacture and field service on-site replacement) and still make twelve million dollars of profit on the replacement.

DEC never told which company had the bad chips, and I never will either.

The Author

Jon "maddog" Hall is an author, educator, computer scientist, and free software pioneer who has been a passionate advocate for Linux since 1994 when he first met Linus Torvalds and facilitated the port of Linux to a 64-bit system. He serves as president of Linux InternationalÆ.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News