PDA

View Full Version : on board parity errors



oblivion
October 7th, 2014, 03:50 PM
I've been working with my 286 machine trying to get it running.

specs 20mhz 286
4MB of RAM
Adaptec SCSI ISA controller + SCSI hard drive
Sound Blaster 2.0
ATI VGAwonder+
goldstar Prime 2 multi I/0 card

I just reinstalled DOS 5.0 and I'm in the process of trying to install all my drivers but I keep getting a random

ON BOARD PARITY ERROR
ADDR (HEX) = (1000:909A) *the number after 1000: always changes on each crash*
SYSTEM HALTED

its in real big text, Ive never had this kind of error before in a machine so I have no idea what the problem is. It seems to happen randomly. It happened when I was installing DOS and a few times when I was trying to enter EDIT. I turned off Parity for my SCSI controller but that doesn't seem to have helped.

oblivion
October 7th, 2014, 04:09 PM
NM, maybe I was to hasty. looked in the BIOS and disabled RAM Parity and it seems to run fine now. what does RAM parity do anyways?

krebizfan
October 7th, 2014, 04:29 PM
RAM parity is needed if your chips are setup to handle 9-bits memory: the standard 8-bit byte and a ninth parity bit which is supposed to catch any alterations to memory by things like cosmic rays. With most systems, it will crash if the parity bit does not match the calculated value for the byte and won't catch if two bits in the same byte got changed.

If you have an even number of chips of the same type on each SIMM, you probably have non-parity memory which was cheaper.

Chuck(G)
October 7th, 2014, 04:47 PM
Probably time for a little lesson on parity, maybe?

1. Consider that a byte is 8 bits.
2. Count the number of 1 bits in the byte; if it's an odd number, add a ninth 1 bit to the number. If it's even, add a ninth 0 bit. In any case the number of 1 bits in the 9 bit byte will always be even.
3. When reading a byte back, total the number of 1 bits in the 9 bits read back; if it's not an even number, one of the bits in the byte is wrong. Note that we don't know which one--it could even be the ninth parity bit, but we have a parity error. Also, observe that if we change two bits, the total of 1 bits will still be even, even though we have a double error.

So a "parity error' will only tell you that something is wrong when a given byte is read, not which bit is in error. If we knew that, we could automatically correct the bit and keep going (that's the business behind ECC checking on later machines, but that takes more bits in a byte to do).

If you turn parity checking off, things may still run, but you'll never know there's a problem until something crashes or gives erroneous results.

Arkady
October 9th, 2014, 07:20 AM
Hello,

I met this problem with two 286 Octek mainboards : a Micro286 Rev5.1 (16Mhz) and a FOX M 286 rev1.1 (12Mhz).
This last one is interesting because the CPU is a Intel 80286-10 with a 24Mhz crystal : a very early kind of overclocking ! :lol:

First if i were you, i'd try with only an I/O board and a graphic card.
Then i'd test the motherboard with 2MB only (2 ram sticks)
Last, i'd search among my RAM sticks, four RAM that doesn't give a parity error TOGETHER.

I found that these motherboards only accept a very few kind of RAM sticks. The motherboards don't boot / don't recognize or give parity errors with all 30pins RAM with only 3 chips onto.
I found only a few sets of four RAM sticks that works correctly together: RAM sticks with 9 chips (KM41C1000AJ-8 )
But strangely enough, several RAM sticks that gave parity error (4 sticks together, 4MB), worked like a charm with only 2 sticks (2MB)....
It has been quite difficult to find 4 RAM sticks working well together (to reach 4MB).

I test the RAM with "CHECK-IT" v3.0, long test, several pass (= several hours)

Hope it helps.

Stone
October 9th, 2014, 07:36 AM
Are you using 3 chip or 9 chip SIMMs?

Trixter
October 9th, 2014, 09:06 AM
disabled RAM Parity and it seems to run fine now. what does RAM parity do anyways?

It detects errors in your memory, and some of your memory is going bad which is causing the errors. What kind of memory does your computer have? Some pictures would help us diagnose it.

The address 1000:xxxx is in the range 64KB - 128KB, so if you have more than one stick, it will be in the first one.

oblivion
October 9th, 2014, 10:08 AM
I haven't removed them as there not normal SIMMs. almost like ZIP RAM with pins I think. I'm assuming there not very common

http://i43.photobucket.com/albums/e385/0blivi0n1/100_7954_zpse205a85d.jpg (http://s43.photobucket.com/user/0blivi0n1/media/100_7954_zpse205a85d.jpg.html)

http://i43.photobucket.com/albums/e385/0blivi0n1/100_7940_zps5ed73a92.jpg (http://s43.photobucket.com/user/0blivi0n1/media/100_7940_zps5ed73a92.jpg.html)

I didn't run the machine to often after I picked it up but it never game me issues when I did. seems I started getting the errors after I added the SCSI controller and new hard drive though I don't know if that's just coincidence.

Trixter
October 9th, 2014, 10:13 AM
My guess is coincidence.

The first stick is where the errors are being reported; turn parity checking back on, and move the sticks around (preferably swap the first and last). Once you isolate the bad stick, remove it. You'll have less memory, but a reliable system.

BTW if the sticks have pins on them, they are SIPP (http://en.wikipedia.org/wiki/SIPP_memory)s. You can make SIPPs by soldering pins onto the legs of the memory (seriously) so you have options.

Caluser2000
October 9th, 2014, 10:28 AM
Also you can buy 30 pin simm holders and fit them into the sipp banks and use just 30 pin simms. A few other members have done just that. No need for any soldering.

First thing I'd be doing is pulling them out and reinserting them. Might remove any oxidation that has occured over the years.

oblivion
October 9th, 2014, 10:31 AM
ah, well those sound like decent options. I'm going to do some reinserting, rearranging and running checkit in awhile here. i'll let you guys know what the results are.

Chuck(G)
October 9th, 2014, 10:42 AM
Another word on this.

PC parity errors are diagnosed through the non-maskable interrupt--and the process isn't foolproof. Sometimes another device that kicks up an NMI will cause a parity error display. To be certain, run an exhaustive memory test, which does not rely on NMI tripping, but rather uses a read-back check. At least that way, you'll have some degree of certainty concerning the integrity of your memory.

oblivion
October 9th, 2014, 10:46 AM
when I run the check utility should I keep parity checking in BIOS off or turn it back on?

Stone
October 9th, 2014, 11:17 AM
when I run the check utility should I keep parity checking in BIOS off or turn it back on?Turn it on and run CheckIt.

Trixter
October 9th, 2014, 12:14 PM
Turn it on and run CheckIt.

To add to that: Never turn off parity checking again.

oblivion
October 9th, 2014, 02:05 PM
ok, well here are the intresting results.

first removed and reinserted the sipps. turned parity back on and I couldn't even get to the prompt screen before I got halt errors. I tried repositioning sipps and same issue. then on a whim I swapped the SCSI hard drive for the original IDE drive and...no issues. ran the memory checker in checkit3.0 several times on "none quick test" and everything passed. went into things that in the past prompted the error like EDIT and no issues. its been running well over an hour now with parity on and no issues.

remember I first got these issues when I upgraded to a SCSI drive and was installing DOS. so that said should I assume the RAM itself is fine and there's an issues with either the SCSI card or hard drive? knowing its not the RAM itself can I turn parity off and continue using the SCSI drive or am I stuck with IDE?

Stone
October 9th, 2014, 02:12 PM
so that said should I assume the RAM itself is fine and there's an issues with either the SCSI card or hard drive? knowing its not the RAM itself can I turn parity off and continue using the SCSI drive or am I stuck with IDE?Didn't you read the last two posts?

oblivion
October 9th, 2014, 02:14 PM
Didn't you read the last two posts?

yes, but I assumed that was a safety precaution if the RAM itself is bad. if you KNOW the RAM is good I assumed it would be okay to turn it off. I suppose its a calculated risk that one day the RAM will go bad but how likly is that and whats the worst that could happen?

okay, let me rephrase that. since all signs seem to point to the SCSI and not the RAM being bad whats the harm of turning parity off? what are the odds the RAM will go bad in the next say 10 years of sporadic use of this machine and whats the worst that could happen other then instability and me saying "oh, guess the RAM crapped out"

Stone
October 9th, 2014, 02:31 PM
yes, but I assumed that was a safety precaution if the RAM itself is bad. if you KNOW the RAM is good I assumed it would be okay to turn it off. I suppose its a calculated risk that one day the RAM will go bad but how likly is that and whats the worst that could happen?

okay, let me rephrase that. since all signs seem to point to the SCSIand not the RAM being bad whats the harm of turning parity off? what are the odds the RAM will go bad in the next say 10 years of sporadic use of this machine and whats the worst that could happen other then instability and me saying "oh, guess the RAM crapped out"Anything can go bad at any time. That doesn't say it will, but it's certainly a possibility.

It won't blow up your house or office or even your computer. It will just cause errors and crashes. You will surely notice the crashes but you might not notice the errors.

It's just bad practice to use an unreliable computer, car, phone, instrument or anything, for that matter. Of course, there's always a few slobs around that don't care a lick about quality or reliability. I always avoid those individuals and businesses as if they were EBOLA!!! :-)

oblivion
October 9th, 2014, 02:37 PM
I'll do some more tests, maybe try a different SCSI drive. if all else fails I can live with IDE and the smaller storage space.

Stone
October 9th, 2014, 03:20 PM
How big are those two drives?

oblivion
October 9th, 2014, 04:11 PM
ones 2.13 GB and the other is 2 GB

I may of stumbled on something. I tried disabling the parity check on the hard drive itself and it seems to be running fine now. is disabling parity on the hard drive just as bad as disabling the RAM parity?

*nm spoke to soon, I still get them just not as often

Stone
October 9th, 2014, 04:55 PM
ones 2.13 GB and the other is 2 GBReally... you're beating your head against the wall over a 6% difference in size? You're not serious are you? Besides, 2 GB is OVERKILL for a 286 anyway. What do you think you're gonna' put on there that could possibly need 2 GB? Never mind -- I'm outta here.

oblivion
October 9th, 2014, 05:06 PM
Really... you're beating your head against the wall over a 6% difference in size? You're not serious are you? Besides, 2 GB is OVERKILL for a 286 anyway. What do you think you're gonna' put on there that could possibly need 2 GB? Never mind -- I'm outta here.

oh, no you misunderstand. the original IDE drive is 100MB the 2 SCSI drives are 2 and 2.13GB. on the matter of overkill, that's kind of irrelevant. some people like to put V8's in go carts and some people like to push 286's to the limit. that's not what I'm trying to do here but just saying I think 100mb is a little constrictive. I'd probably be fine with it still but anyways.

regardless on practicality its also a problem that wants to be solved. Id be happy with a 500mb drive over a 100mb but 2gb drives are all I have to work with here.

Chuck(G)
October 9th, 2014, 06:20 PM
It's just bad practice to use an unreliable computer, car, phone, instrument or anything, for that matter. Of course, there's always a few slobs around that don't care a lick about quality or reliability. I always avoid those individuals and businesses as if they were EBOLA!!! :-)

Are you trying to get the attention of DHS? :)

Trixter
October 9th, 2014, 06:38 PM
if you KNOW the RAM is good I assumed it would be okay to turn it off.

The RAM is good until it isn't. And without parity checking, you'll never know. You'll just blame lost data, crashing games, etc. on something else, never thinking to check the memory.

oblivion
October 9th, 2014, 06:43 PM
well I *think* its the actual SCSI controller card that was causing the issues, why this is I don't know but using a different controller and drive now seems to of fixed things

Caluser2000
October 10th, 2014, 10:45 AM
Good to see you seemed to have resolved the issue. Any component can become faulty some earlier than others. As the other have said keep the parity checking on.