home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / sysv386 / 14502 < prev    next >
Encoding:
Text File  |  1992-09-15  |  2.8 KB  |  62 lines
  1. Newsgroups: comp.unix.sysv386
  2. Path: sparky!uunet!mcsun!Germany.EU.net!isaak.isa.de!omega!av
  3. From: av@omega.ssw.de (Andreas Vogel)
  4. Subject: Re: >16MB on a 486
  5. Message-ID: <1992Sep15.000013.24288@omega.ssw.de>
  6. Date: Tue, 15 Sep 1992 00:00:13 GMT
  7. References: <BuILEt.1MG@virtech.uucp> <1992Sep13.105315.15555@husc3.harvard.edu> <BuJIw0.AE3@virtech.uucp>
  8. Organization: Omega Softlab
  9. Lines: 51
  10.  
  11. In article <BuJIw0.AE3@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
  12. >maziere1@husc8.harvard.edu (David Mazieres) writes:
  13. >
  14. >>In article <BuILEt.1MG@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
  15. >>>It cannot be done with ISC 2.2 or 3.0 and the testing that I did with 2.0.2
  16. >>>made me believe that regarless of the setting of this file the
  17. >>>system would start swapping at 16MB...
  18. >
  19. >>This maybe a stupid question, but what's wrong with doing:
  20. >>     "MEMRANGE=0-640K:0,1M-16M:0,16M-64M:1"
  21. >
  22. >>The man page says of the 0/1 flag:
  23. >>     "0 indicates no special properties and 1 indicates memory for which
  24. >>      DMA is not allowed."
  25. >
  26. >First of, this option is not available in 2.2 (as far as I remember) nor
  27. >in 3.0.  In the testing that I did with 2.0.2, even setting 16M-64M:1
  28. >*seemed* to have no effect on whether or not the system started swapping 
  29. >when I reached 16MB of data in processes (using a test process I wrote 
  30. >which allocates 1MB of data and then pokes bytes into it in random 
  31. >locations).  This is something I tried about a year and a half ago and
  32. >I don't have 2.0.2 running anywhere at this point to review the
  33. >test, but I am pretty sure that those were the results I observed.
  34. >
  35.  
  36. As far as I know, one have NO access to memory above the first 16 MB.
  37. This is true for ALL SVR3 Systems (ISC, SCO, ...). This might be true
  38. for some SVR4 systems. The original AT&T code provides the routines
  39. to access memory above the first 16 MB but these routines are not
  40. enabled by default. The only problem that arise is to handle the DMA
  41. access within the first 16 MB. So the kernel has to arrange this for
  42. buffers which resides in the "extended" memory. Personally, I have a 486 ISA
  43. machine running SVR4 with 32MB memory and my SVR4 (SINIX) definitely
  44. uses the whole 32MB :-)) Upgrading to 64MB will give no problems (except
  45. financial aspects :-)
  46.  
  47. Conclusion: SVR3 no, SVR4 maybe.
  48.  
  49. P.S. A developer at Interactive (UK) told me, that Interactive would
  50.      NEVER support memory wich extends the 16MB limit in their SVR3
  51.      version running on ISA architecture. Note that this statement
  52.      was made about 8 month ago, so I don't know if Interactive
  53.      changed their opinion in the meantime.
  54.  
  55. P.P.S. In /stand/boot I have an entry MEMRANGE=0-640K:0,1M-64M:0 which
  56.      works fine for me.
  57.  
  58. -- 
  59. Andreas Vogel                   Bahnhofstr. 13 / D-7300 Esslingen / Germany
  60.                 Voice:  +49-711/357613
  61.                 E-Mail: av@ssw.de
  62.