rml@extro.ucc.su.oz.au (Dr.Ross Lazarus) (03/15/91)
I have a nice fast '486 clone. Unfortunately, when I activate the 128k external cache (as you all know, the 486 has an 8k onchip cache) I get random lock ups with a memory parity error - address varies. After many days of continuous ram testing and weeks of trouble free running without the external cache enabled, I suspect that the 4mB of motherboard RAM is quite healthy but that the parity error is arising from a flakey static ram cache chip. So here's the rub - anyone written a pd or shareware cache tester ? Anyone up to the challenge ? Any thoughts on fixing this sucker ?
rcollins@altos86.Altos.COM (Robert Collins) (03/19/91)
In article <1991Mar15.055837.7844@metro.ucc.su.OZ.AU> rml@extro.ucc.su.oz.au (Dr.Ross Lazarus) writes: >I have a nice fast '486 clone. Unfortunately, when I activate the 128k >external cache (as you all know, the 486 has an 8k onchip cache) I get >random lock ups with a memory parity error - address varies. After many >days of continuous ram testing and weeks of trouble free running without >the external cache enabled, I suspect that the 4mB of motherboard RAM is >quite healthy but that the parity error is arising from a flakey static >ram cache chip. So here's the rub - anyone written a pd or shareware >cache tester ? Anyone up to the challenge ? Any thoughts on fixing this >sucker ? Testing a cache is very much hardware dependant. Therefore it would be impossible to write a generic external cache tester. Many cache controllers can be put into a test mode where the SRAM and TAGRAM can be memory mapped into user memory space for testing purposes. However other cache controllers use other testing mechanisms. And others have no testing mechanism at all. Another problem arises in how the hardware implemented the entrance to test mode. For example, let's suppose that every cache controller had a test mode that was enabled by pulling a certain pin low for exactly two clocks before releasing it; and this test mode was exited by asserting the same pin for three clocks. The hardware must perform this by writing to some I/O port, or memory mapped I/O address. My '486 may use I/O port C02, another may use I/O port C04, and yet another may use memory mapped I/O @ RAM address 90000004. The point is that supposing every cache controller used the same method to enter test mode (which they don't), the I/O port or memory mapped I/O used by the hardware can't be guaranteed to be the same port or memory address. So, sorry, but I'm certainly not up to the challange. P.S. I'm not convinced that the parity error is either A) a real parity error, or B) caused by the SRAM. But C) is definetely caused by some interaction with the cache mechanism -- "Worship the Lord your God, and serve him only." Mat. 4:10 Robert Collins UUCP: ...!sun!altos86!rcollins HOME: (408) 225-8002 WORK: (408) 432-6200 x4356