mjw06513@uxa.cso.uiuc.edu (Mary Winters) (06/28/90)
I have an interesting problem with memory SIMMs. I recently upgraded my '386 to 4MB of RAM using 1Mb SIMMs (which replaced 2MB of 256K SIMMs). I regularly run DESQview '386 and QEMM, and never had any noticeable problems. I also ran a couple of memory testing programs (the one in CHECKIT, as well as a shareware one from Brown Bag Software). Neither memory test turned up any errors. I assumed my memory was fine. Today, my copy of Turbo C++ arrived. I was playing around, compiling the sample code provided, when all of a sudden a memory parity error burst onto the screen. I rebooted, tried it again. Same thing. Checking the manuals, I found out that the IDE makes use of available extended and/or exapnded RAM. It appears that when the compiler swaps out to expanded RAM, a parity error is generated. I re-ran the memory tests, but the memory passed. I tried various other things, but what finally worked was putting back my old memory SIMMs. Now TC++ compiles everything fine, no parity errors. Clearly, one or more of my 1MB SIMMs is faulty. I'm going to take back the faulty SIMMs and get new ones, but I'd like to make certain that the replacements are in perfect working order. Since both memory test programs available to me passed the bad SIMMs, I need something more powerful, so that more of these "hidden" defects don't pop up and byte (pun intended) me later. What's the best memory testing software for a '386? Why would SIMMs which pass a "normal" test cause parity errors when TC++ tries to access extended RAM? Thanks for your assistance. -- uv@f69.n233.z1.fidonet.org Suffering from PMS (Presentation Manager Syndrome)
bobmon@iuvax.cs.indiana.edu (RAMontante) (06/28/90)
mjw06513@uxa.cso.uiuc.edu (Mary Winters) <1990Jun28.032323.5496@ux1.cso.uiuc.edu> : [ Memory upgrade; software upgrade; then... ] | code provided, when all of a sudden a memory parity error burst onto the | screen. I rebooted, tried it again. Same thing. Checking the manuals, I found | out that the IDE makes use of available extended and/or exapnded RAM. It | appears that when the compiler swaps out to expanded RAM, a parity error is | generated. I re-ran the memory tests, but the memory passed. I tried various | other things, but what finally worked was putting back my old memory SIMMs. | [ description omitted ] | What's the best memory testing software for a '386? Why would SIMMs which pass | a "normal" test cause parity errors when TC++ tries to access extended RAM? For what it's worth... I added a bank of (used) 256K chips to my EMS board awhile ago, and let TC put its editor up there. Shortly afterwards I started getting corrupted files during editing and compilation. What I eventually discovered was that the chips were flaky, but only failed slowly and after they'd been running for long enough to warm up --- the EMS board's memory diagnostics passed the chips, but when the TC editor put a file into that memory bank, some bytes would flip bits *after twenty seconds or so*. I finally diagnosed this by creating a file containing just the `-' character over and over to fill the editor buffer. In the time it would take to page from one end of the file to the other, a few characters would change to something else, which was easily detected visually. (Tediously manual process, but easy.) In my case, I wasn't getting any parity error, possibly because I had turned off parity checking (or maybe a bug in the EMS board). In total, though, SIX of the nine chips had at least one bad bit somewhere! Ten bucks' worth of some more used chips seems to have solved my problem; or maybe putting the EMS board in a different slot lets it run cooler. But I'm a happy camper again.
andyb@stb.info.com (Masked Marauder) (07/04/90)
In article <1990Jun28.032323.5496@ux1.cso.uiuc.edu> mjw06513@uxa.cso.uiuc.edu (Mary Winters) writes: >What's the best memory testing software for a '386? Why would SIMMs which pass >a "normal" test cause parity errors when TC++ tries to access extended RAM? A real application is the best test. If your memory fails only under certain conditions, and the test fails to address those conditions, it will pass the test. Use TC++ as your test. Checkit never worked for me. It insisted things were wrong, when I *knew* that those things were correct, In addition, it failed to find the problem I *was* having! >uv@f69.n233.z1.fidonet.org >Suffering from PMS (Presentation Manager Syndrome) Andy -- | | | T H E L O N E C O N S U L T A N T | | |
emmo@moncam.co.uk (Dave Emmerson) (07/06/90)
Sounds like your memory tests are a bit simplistic -
fill a huge area with known or predictable data, then
read back and compare.
Trouble with this type of test is that REFRESH problems
are disguised by the test itself.
Typical refresh reqirements are (for each chip) 512
consecutive addresses to be accessed every 8msec.
Your memory tests are exceeding that by a HUGE margin
by thundering through your DRAM at top speed. If you
decide to 'roll your own', do the fill first, then
WAIT 2 or 3 seconds in a loop in low memory before
you read back and compare. That way, if the data's
volatile, you stand a chance of detecting it.
Natch, you should avoid haveing any other process
using the ex??nded memory during the test, so you
may need to alter your config.sys..
Good luck!
Dave E.
NB: I assume the SIMMs/SIPs meet the minimum setup time
for your system- you did check didn't you?