Zitat von Jukka Tastula <jukka.tastula@xxxxxxxxxxx>: > On Thursday 21 April 2005 15:54, Sami Hakkarainen wrote: > > > by one to find out when the changes that cause this have been made. It > > can't be a hardware issue if the older versions work fine, can it? > > That's what too many people who overclock their cpus and memory to the > limit and then try compile something say. "But my windows runs just fine, > never had a crash!". > > Hardware problems can be elusive but it doesn't mean they don't exist. > I guess the older version of the program just doesn't poke the hardware > where it's broken -> no crash/hang/jam. That is if it is broken to begin > with, we're still not sure about that. cpuburn is your friend to test the stability of a new or changed system. Finds mmx/memory-transfer errors on broken mainboards/cpu's. It's designed to produce maximum heat/load on each cpu and finds errors by comparing calculated and expected results. Example: i found, that my old mainboard (labeled FSB133) did not reliable work at 133 MHz FSB although the right memory was used (tested with 3 different RAM chips), with 100 it was (almost) stable. Typical userware might not be suitable for that job because of: 1. not stressing enough (look at the cpu-temp when cpuburn runs - it jumps +10?C almost) 2. most times the errors are not detected because the software just runs on producing wrong results, video glitches etc. but does not crash most the time
