Re: Recommended addition to FAQ (Troubleshooting)
On Fri, 18 Feb 2000, Bruce Gingery wrote: So I'll leave it up to you. There should be info at least in a FAQ somewhere that indicates that bad RAM is not something that can be ruled out until tested adequately, and perhaps a checklist of symptoms that (virtually) ALWAYS indicate bad RAM, or at least should make it suspect. It's *precisely* that attitude that makes up all immediately and completely against recommending any memory tester whatsoever. You apparently didn't read what Jordan told you closely enough to catch the main point: There is *no possible software method* of catching memory errors, with more than a 25% chance of really catching errors! There is NO "checklist of symptoms that (virtually) ALWAYS indicate bad RAM". Jordan wrote you what appears to be good advice. Like many who've posted before you, you can't believe that all the memory test programs you can purchase are all pretty much useless (only catching an extremely small set of huge memory faults). Your first post spoke of getting the memory failure "although it had supposedly passed the BIOS memory tests". BIOS checks only the existence of memory, not it's functionality. The closest you can come to in-home memory checks *IS* memory swapping, and disabling BIOS. Advocating other advice in FAQs means only giving out definitely bad advice. Your own experience, in having a memory tester find the problem, is exceptional, most folks wouldn't have even found it that way. What do you tell to users, when they claim they haven't any memory problem, because they already *used* your recommended memory tester? After all, the memory test program is in your FAQ, it's gotta mean something, right? Folks won't believe you when you tell them it's very nearly worthless. The mere existence of recommendations of memory testers, no matter how you wrap them in warnings, is enough to make users certain that you're lying when you say that they haven't even reduced the odds of a memory fault, in doing their software memory tests. Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommended addition to FAQ (Troubleshooting)
Chuck Robey wrote: On Fri, 18 Feb 2000, Bruce Gingery wrote: So I'll leave it up to you. There should be info at least in a FAQ somewhere that indicates that bad RAM is not something that can be ruled out until tested adequately, and perhaps a checklist of symptoms that (virtually) ALWAYS indicate bad RAM, or at least should make it suspect. It's *precisely* that attitude that makes up all immediately and completely against recommending any memory tester whatsoever. You apparently didn't read what Jordan told you closely enough to catch the main point: There is *no possible software method* of catching memory errors, with more than a 25% chance of really catching errors! Sure there is, and it's included in FreeBSD by default: make -j 8 world ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommended addition to FAQ (Troubleshooting)
On Fri, 18 Feb 2000, Bruce Gingery wrote: I can't praise highly enough, two software packages: http://reality.sgi.com/cbrady_denver/memtest86/ and http://www.qcc.sk.ca/~charlesc/software/memtester/ Sweet! I never knew that I've wanted one for all of these years until I saw you talking about them. :) Any OS vendor would do good to package these kinds of tools. -MB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommended addition to FAQ (Troubleshooting)
The situation here, I hate to say, is that you were simply very lucky in having a software memory tester show you anything at all. If your experience had been more typical, you would have run memtest86 and it would have declared your memory to be free of errors. Then you'd have gone right on having problems and losing more hair until you finally just came back to the memory and swapped it out on suspicion. Bingo, the problems are suddenly fixed and you're dragging memtest86 to KDE's trashcan with a resolve to never trust it again. The reason why software memory testers are so generally ineffectual is that there's a whole bunch of things getting in their way. Leaving aside for the moment the nasty problem of having your memory checker loaded into the bad memory in question, the cache also seriously gets in your way (and I'll bet you never even thought to turn both L1 and L2 caches off, did you? :-) by masking errors in a way which is transparent to the program. How's it supposed to know its accesses are getting cached or how much cache it has to "defeat" to get meaningful access to main memory? It can't, really, at least not in a way that's truly foolproof or workable across the entire range of Intel/AMD CPUs it might be run on, and that's why serious bench techs use hardware memory testers exclusively. I've used all kinds of software memory checkers, from "CheckIt" to highly proprietary packages that cost even more money, and the only thing they managed to convince me of is that swapping in known-good memory is the best and fastest way out of these situations. Unless you have a hardware memory tester available, trying to test it yourself is just too likely to give you a false sense of security and send you down more blind alleys. I've even put known BAD memory into boxes and had CheckIt tell me "looks good to me, boss!", just to verify my suspicion that it had lied to me before. It's also very slow to run a software memory tester without the caches enabled and swapping the memory is generally a whole lot faster than that. I'm impatient. :) So, to summarize, I am actually somewhat against the idea of including tools like this on the grounds that they can also help to convince people of the wrong things while they're debugging a problem. I also don't look forward to having to argue with users who've just run such tests and are still getting signal 11's but now refuse to believe that the memory could be bad because "they checked it." If I then turn around and tell them not to trust the tool I also stuck on the CD for them, they're going to ask why I put it there in the first place and a nice long argument will then ensue instead of us just replacing that damn memory and moving on. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommended addition to FAQ (Troubleshooting)
"Jordan K. Hubbard" [EMAIL PROTECTED] wrote: I've used all kinds of software memory checkers, from "CheckIt" to highly proprietary packages that cost even more money, and the only thing they managed to convince me of is that swapping in known-good memory is the best and fastest way out of these situations. Unless I'll second this. I've had memory problems in the past, and every memory checker I used said that the memory was good. Only by swapping out the bad memory (I don't have access to an hardware memory checker) was I able to fix my problems. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommended addition to FAQ (Troubleshooting)
On 18-Feb-00 Darryl Okahata wrote: "Jordan K. Hubbard" [EMAIL PROTECTED] wrote: I've used all kinds of software memory checkers, from "CheckIt" to highly proprietary packages that cost even more money, and the only thing they managed to convince me of is that swapping in known-good memory is the best and fastest way out of these situations. Unless I'll second this. I've had memory problems in the past, and every memory checker I used said that the memory was good. Only by swapping out the bad memory (I don't have access to an hardware memory checker) was I able to fix my problems. -- Darryl Okahata [EMAIL PROTECTED] Every "good" software based memory tester I have ever used took so long to tell me anything I could have gone to the store, bought more memory, and swapped it before it was done. I don't think adding it to the ports tree would be bad for those who are desperate, but deffinatly list it as a "basic" memory tester. Nicole DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message [EMAIL PROTECTED] |\ __ /| (`\ http://www.unixgirl.com/ [EMAIL PROTECTED] | o_o |__ ) ) http://www.dangermouse.org/ // \\ ---(((---(((- -- Powered by Coka-Cola and FreeBSD -- -- Stong enough for a man - But made for a Woman -- -- Microsoft: What bug would you like today? -- --- -- As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
