home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / os2 / misc / 28567 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.5 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!rutgers!cmcl2!kramden!liuyu
  2. From: liuyu@kramden.nyu.edu (Liuyu)
  3. Newsgroups: comp.os.os2.misc
  4. Subject: Re: OS2 WINS!! I give up!
  5. Message-ID: <liuyu.715062773@kramden>
  6. Date: 29 Aug 92 04:32:53 GMT
  7. References: <1992Aug27.015416.6882@maccs.dcss.mcmaster.ca> <1992Aug27.030506.4609@midway.uchicago.edu> <liuyu.714945700@kramden>             <1992Aug28.200235.7250@njitgw.njit.edu> <19920828.144500.49@almaden.ibm.com>
  8. Sender: notes@cmcl2.nyu.edu (Notes Person)
  9. Organization: New York University
  10. Lines: 39
  11. Nntp-Posting-Host: kramden.acf.nyu.edu
  12.  
  13. ADUNSMUI@TOROLAB6.VNET.IBM.COM (Al Dunsmuir) writes:
  14. >>OS/2, due to it s high amount of context switching, has some strange
  15. >>ability to push intermittently bad memory over the edge.  It's
  16. >>happened on many computers.  Replacing the memory usually works to
  17. >>cure it.
  18. >>
  19. >>My father's computer at work had its memory "pushed over the edge" by
  20. >>Windows 3.1.  So it's nothing inherent in OS/2.  (And when Windows 3.1
  21. >>died, it took most of his /Windows directory with it - a complete
  22. >>re-install of Windows and all Windows apps had to be performed).
  23. >>Again, replacing the memory cured everything.
  24. >>
  25. >>--
  26. >>   |)  David Charlap           "I don't even represent myself
  27. >>  /|_  dic5340@hertz.njit.edu   sometimes so NJIT is right out!.
  28. >> ((|,)
  29. >>  ~|~  Hi! I am a .signature virus, copy me into your .signature file.
  30. >>
  31.  
  32. >  Some of the extra stress is due to two differences between when one executes
  33. >a program from memory, and when one simply reads/writes that memory using a
  34. >program (such as a DOS VDISK device driver).
  35.  
  36. >    A) A DOS device driver typically will access a smallish block of the
  37. >       memory (copying data in or out), then not touch the card for what
  38. >       appears to the card to be a relatively long time.  If the refresh
  39. >       circuitry doesn't properly handle the cases when a particular
  40. >       range of addresses is used without a break (code in a long, tight
  41. >       loop), your memory won't get refreshed properly and you lose data.
  42.  
  43. >    A) When executing a program the address lines change in a fairly random
  44. >       manner. Some memory cards (or memory chips) can keep up with relatively
  45. >       slow changes, but aren't fast enough to keep up with the instruction
  46. >       addresses.  Sooner or later the card fetches storage from the wrong
  47. >       memory address, and your program dies a horrible death.
  48.  
  49.  
  50. Thanks for the detail explaination.
  51. I appreciated it a lot more than some personal attacks I got.
  52.