If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
Arno Wagner wrote:
In comp.sys.ibm.pc.hardware.storage Alexander Grigoriev wrote: I've had an MB, which occasionally corrupted bit 0x80000000, but only during disk I/O! And the corrupted bit position was unrelated to I/O buffers! Of course, standalone memory test didn't find anything. I've had to modify the test to make it run under Windows and also run parallel disk I/O threads. In that mode, the failure was detected in a minute. Had to dump the MB. Replacing memory and CPU didn't help. Really nasty. Shows that these things have gotten far to complex... Dunno about that, I ran into something similar with a genuine original PC. Customer brought it in reporting a parity error. He put his program disk in, ran it, sure enough a parity error popped right up. I ran a diagnostic on it overnight, found nothing, put his program in, parity error popped right up again. Replaced the RAM. Same thing. Tried his program on another machine, no problem. Never did find out the cause, just replaced the planar and that was the end of it. Only thing I can figure is that something was busted in the processor or the supporting circuitry that was state dependent--had to go through a certain sequence of states before the error occurred. Should have hung onto the board and dug into it but at the time I figured (probably correctly) that I'd never get around to it. Arno -- --John Reply to jclarke at ae tee tee global dot net (was jclarke at eye bee em dot net) |
#22
|
|||
|
|||
"Mark M" wrote in message ... I use a partition copier which boots off a floppy disk before any other OS is launched. If I copy a partition from one hard drive to another, then is there any risk of data corruption if the BIOS has been changed to aggressively speed up the memory settings? For example the BIOS might set the memory to CAS=2 rather than CAS=3. Or other memory timing intervals might also be set to be shorter than is normal. I am thinking that maybe the IDE cable and drive controllers handle data fairly independently of the memory on the motherboard. So maybe data just flows up and down the IDE cable and maybe the motherboard is not involved except for sync pulses. There are three scenarios I am thinking about: (1) Copying a partition from one hard drive on one IDE cable to another hard drive on a different IDE cable. (2) Copying a partition from one hard drive to another which is on the same IDE cable. (3) Copying one partition to another on the same hard drive. How much effect would "over-set" memory have on these situations? Do the answers to any of the above three scenarios change if the copying of large amounts of data files is done from within WinXP? Personally, I would guess that it is more likely that motherboard memory comes into play if Windows is involved. How about something easy...Loosen your memory timings.(CAS3)...perform the copy...then tighten them back up...Voila! No corruption! |
#23
|
|||
|
|||
SpongeBob wrote:
wrote .... snip ... There are three scenarios I am thinking about: (1) Copying a partition from one hard drive on one IDE cable to another hard drive on a different IDE cable. (2) Copying a partition from one hard drive to another which is on the same IDE cable. (3) Copying one partition to another on the same hard drive. How much effect would "over-set" memory have on these situations? Do the answers to any of the above three scenarios change if the copying of large amounts of data files is done from within WinXP? Personally, I would guess that it is more likely that motherboard memory comes into play if Windows is involved. How about something easy...Loosen your memory timings.(CAS3)... perform the copy...then tighten them back up...Voila! No corruption! However the partition you want to copy has already been messed up by the memory faults, in ways that may not show up for months. If you have ECC installed and active you might get away with it. Copying corrupt data does not repair it. -- Chuck F ) ) Available for consulting/temporary embedded and systems. http://cbfalconer.home.att.net USE worldnet address! |
#24
|
|||
|
|||
"CBFalconer" wrote in message ... SpongeBob wrote: wrote ... snip ... There are three scenarios I am thinking about: (1) Copying a partition from one hard drive on one IDE cable to another hard drive on a different IDE cable. (2) Copying a partition from one hard drive to another which is on the same IDE cable. (3) Copying one partition to another on the same hard drive. How much effect would "over-set" memory have on these situations? Do the answers to any of the above three scenarios change if the copying of large amounts of data files is done from within WinXP? Personally, I would guess that it is more likely that motherboard memory comes into play if Windows is involved. How about something easy...Loosen your memory timings.(CAS3)... perform the copy...then tighten them back up...Voila! No corruption! However the partition you want to copy has already been messed up by the memory faults, in ways that may not show up for months. If you have ECC installed and active you might get away with it. Copying corrupt data does not repair it. -- Chuck F ) ) Available for consulting/temporary embedded and systems. http://cbfalconer.home.att.net USE worldnet address! Well...from what was written...the question was theoretical...data corruption has not occurred, there has been no evidence of system instability, and he has not copied anything yet. High quality memory can often handle tighter timings without ill effect. Test with memtest86 and Prime95 for a few days to be sure of stability. If not...loosen the timings and copy away! To answer the question...tighter memory timings may or may not affect data transfer...It all depends on your memory and your system. |
#25
|
|||
|
|||
On Fri, 12 Mar 2004 14:08:10 -0500, "SpongeBob"
wrote: Well...from what was written...the question was theoretical...data corruption has not occurred, there has been no evidence of system instability, and he has not copied anything yet. High quality memory can often handle tighter timings without ill effect. Test with memtest86 and Prime95 for a few days to be sure of stability. If not...loosen the timings and copy away! To answer the question...tighter memory timings may or may not affect data transfer...It all depends on your memory and your system. There is nothing about data transfer that would inherently make it more susceptible to memory errors... in theory if the memory were to affect that then everything done on the system is subject to, likley to encounter these errors. A system certainly could appear to function stabily for a while with memory errors occuring, depending on their frequency, but it's the worst possible situation having unknown problems and data corruption instead of a more extreme case, an immediate OS crash before the OS even manages to boot, load. |
#26
|
|||
|
|||
Quick Response to Subject Header:
Diskette activity involves DMA, and RAM timings that may be tolerated for CPU access (thus pass diags) may fail under DMA, Consider this if crashes when accessing diskettes are the only problems you have. -------------------- ----- ---- --- -- - - - - Running Windows-based av to kill active malware is like striking a match to see if what you are standing in is water or petrol. -------------------- ----- ---- --- -- - - - - |
#27
|
|||
|
|||
"Folkert Rienstra" wrote in message
... "CBFalconer" wrote in message Correction here - non ECC memory won't even detect any errors, it will just use the wrong value. Sometimes that MAY cause the OS to crash. Folkert is correct. I did some research into this and standard non-ECC memory - the kind found in almost all home PCs - does not do error detection of any kind. The reasoning is that the error rate is so astoundingly low that the cost of adding the logic to detect errors cannot be justified. According to one source I found, actual occurrances of memory errors in home PCs are usually caused by contamination of the DIMM connectors by the installer. Translation: finger goo causes most of the errors. cp |
#28
|
|||
|
|||
On Fri, 12 Mar 2004 19:54:41 GMT, kony wrote:
There is nothing about data transfer that would inherently make it more susceptible to memory errors... If the DMA system errors while CPU access does not (think square wave pulse edges, rise time, local charge pump capacitors etc.) then MemTest86 et al may pass, while UIDE transfers may fail. Other possibilities: - buggy VIA 686B Southbridge problem (eats UIDE data) - bad or noisy UIDE data cables - bad cache RAM on the HD itself - static buildup on ungrounded HD The last is something that bit me; a couple of 32-bit errors in the midst of a 500M bulk file copy, when the loose HD was not touching the chassis. Grounding the HD solved the problem, hence cause presumption -------------------- ----- ---- --- -- - - - - Running Windows-based av to kill active malware is like striking a match to see if what you are standing in is water or petrol. -------------------- ----- ---- --- -- - - - - |
#29
|
|||
|
|||
In comp.sys.ibm.pc.hardware.storage Colin Painter wrote:
"Folkert Rienstra" wrote in message ... "CBFalconer" wrote in message Correction here - non ECC memory won't even detect any errors, it will just use the wrong value. Sometimes that MAY cause the OS to crash. Folkert is correct. I did some research into this and standard non-ECC memory - the kind found in almost all home PCs - does not do error detection of any kind. The reasoning is that the error rate is so astoundingly low that the cost of adding the logic to detect errors cannot be justified. Actually it is not the logic. That is very simple and cheap. It is the additional bits needed, which is one per 8 bits and makes memory (theoretically) 12.5% more expensive. The market is not willing to pay that much for improved reliability. Sad but true. (ECC is more expensive because of the additional bit, but more so because of the lower volume sold.) According to one source I found, actual occurrances of memory errors in home PCs are usually caused by contamination of the DIMM connectors by the installer. Translation: finger goo causes most of the errors. Incorrect (read: too high) clock settings are more likely the main source today. The memory contacts have gotten better and tin-plating is not so common anymore as it was with DIL-memory and the first generation of DIMMs. Arno -- For email address: lastname AT tik DOT ee DOT ethz DOT ch GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F "The more corrupt the state, the more numerous the laws" - Tacitus |
#30
|
|||
|
|||
In comp.sys.ibm.pc.hardware.storage "cquirke (MVP Win9x)" wrote:
On Fri, 12 Mar 2004 19:54:41 GMT, kony wrote: There is nothing about data transfer that would inherently make it more susceptible to memory errors... If the DMA system errors while CPU access does not (think square wave pulse edges, rise time, local charge pump capacitors etc.) then MemTest86 et al may pass, while UIDE transfers may fail. True. But DMA is usually far less agressive in its timing, so this is a rather unlikely scenario. Other possibilities: - buggy VIA 686B Southbridge problem (eats UIDE data) - bad or noisy UIDE data cables That should cause CRC errors. - bad cache RAM on the HD itself - static buildup on ungrounded HD No. The HDD is grounded through the power cable and through the data cable. Unless the whole mainboard is not grounded properly. The last is something that bit me; a couple of 32-bit errors in the midst of a 500M bulk file copy, when the loose HD was not touching the chassis. Grounding the HD solved the problem, hence cause presumption Strange. The hdd has two low-resistance paths to the chassis. These should be enough. Hmmm. O.k., so that may cause problems in some setups. But it cannot be static buildup in the hdd. Maybe you where statically charged and touched the HDD? That yould have induced a spike in some logic-lines... Arno -------------------- ----- ---- --- -- - - - - Running Windows-based av to kill active malware is like striking a match to see if what you are standing in is water or petrol. -------------------- ----- ---- --- -- - - - - P.S.: Like the sig! -- For email address: lastname AT tik DOT ee DOT ethz DOT ch GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F "The more corrupt the state, the more numerous the laws" - Tacitus |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
"Safe" memory testing | Timothy Lee | General | 1 | March 8th 04 08:04 PM |
CAS Timings De-Mystified, and other JEDEC Zins of DDR cRAMming...(Server Problems) | Aaron Dinkin | General | 0 | December 30th 03 02:29 AM |
CAS Timings De-Mystified, and other JEDEC Zins of DDR cRAMming... | Aaron Dinkin | General | 0 | December 30th 03 02:12 AM |
Buying Kingston RAM chips... | Wald | General | 7 | December 6th 03 04:56 AM |
Chaintech 7NIF2 motherboard - memory problems | Wuahn | General | 1 | July 26th 03 01:29 PM |