memory access problems (?) - OS2

This is a discussion on memory access problems (?) - OS2 ; some rather unusual developments, but upgrading my system has involved a number of things, so I really don't quite know where to start diagnosing. here are the symptoms of my Warp 4 system with I think the latest fixpacks: a) ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: memory access problems (?)

  1. memory access problems (?)

    some rather unusual developments, but upgrading my system has involved
    a number of things, so I really don't quite know where to start
    diagnosing. here are the symptoms of my Warp 4 system with I think the
    latest fixpacks:

    a) after 1-2 days of uptime, I'll get some symptoms of ill system
    health. first, I will be unable to start some of my Java programs --
    trying to start Moneydance or JFTP, for instance, which ordinarily do
    just fine, will throw up the error message

    "Can't find/run J2WIN.DLL (rc=8, module INNOWIN)"

    b) then I may start getting video corruption -- the PMFax popup window
    will blank out completely, sections of XCenter will completely drop
    out. eventually there is simply no response whatever, and I'll have to
    three-finger salute.

    problem is, in the last month or so I've 1) added SDRAM to bring this
    P2B up to 1 gig of RAM; 2) installed the latest XWorkplace along with
    XCenter, and 3) added Doodle's Screen Saver. things had been quite
    stable for a long time, but I had hoped the added memory would allow me
    to get the most out of OS/2 for at least a few years more, and I'm
    quite pleased with how both DSS and XWP 1.0.6 themselves work.

    I'm not suspicious of the memory per se -- however, the CPU fan on this
    Tualatin adaptor blows directly onto the SDRAM, with only about 1 CM
    separating them; I've been monitoring the CPU temp, which tends to
    hover between 35-40 degrees C -- not exactly cool, but I don't think
    quite hot enough to cause trouble.

    I MAY be a little dubious of Doodle's SS. with the latest version, and
    the recommendation not to enable DPMS Suspend or DPMS Off with this
    NVIDIA card, earlier problems with the system being put into a coma
    were eliminated. however, one reason I stopped using blackout.exe, the
    screen-blanker I had been using for some years, was that it somehow
    interfered with OS/2 accessing some memory segments -- after one or two
    weeks' time, I'd experience symptoms such as Java apps misbehaving, or
    blackout.exe itself ceasing to work.

    A few days ago I upgraded the SNAP driver to the last one I found
    (3.1.8/505) via WarpUpdates, but just now I'm starting to get the Java
    snafu.


  2. Re: memory access problems (?)

    On Thu, 4 Jan 2007 16:22:46 UTC in comp.os.os2.setup.misc, "rafe"
    wrote:

    > a) after 1-2 days of uptime, I'll get some symptoms of ill system
    > health. first, I will be unable to start some of my Java programs --
    > trying to start Moneydance or JFTP, for instance, which ordinarily do
    > just fine, will throw up the error message
    >
    > "Can't find/run J2WIN.DLL (rc=8, module INNOWIN)"


    What's your virtualaddresslimit= setting? This is not an indicator of physical
    memory problems, more likely a problem with shared memory usage reducing the
    amount of private area available.

    Is it Warp 4 or 4.5? If 4.5 then you should add a SET JAVA_HIGH_MEMORY=1 to
    config.sys

    --
    Trevor Hemsley, Brighton, UK
    Trevor dot Hemsley at ntlworld dot com

  3. Re: memory access problems (?)

    Trevor Hemsley wrote:

    > What's your virtualaddresslimit= setting?


    hmm. here it's got:

    REM virtualaddresslimit=3072

    is that a viable number when I unREM it?

    > This is not an indicator of physical
    > memory problems, more likely a problem with shared memory usage reducing the
    > amount of private area available.
    >
    > Is it Warp 4 or 4.5? If 4.5 then you should add a SET JAVA_HIGH_MEMORY=1 to
    > config.sys


    funny thing is, that's in there, though unless recent fixpacks have
    brought it up, it's Warp 4.


  4. Re: memory access problems (?)

    rafe schrieb:
    > Trevor Hemsley wrote:
    >
    >
    >>What's your virtualaddresslimit= setting?

    >
    >
    > hmm. here it's got:
    >
    > REM virtualaddresslimit=3072
    >
    > is that a viable number when I unREM it?


    if you unrem it, make sure it is <= 1024 or so. 3072 will lead to all
    kinds of problems. On the other hand, unremming it will give your
    applications more private and shared memory space as long as the
    dynamically allocate memory in high memory space (DosAllocMem with
    OBJ_ANY flag set). Java is a candidate that is known to make good use of
    high memory.

    >
    >
    >>This is not an indicator of physical
    >>memory problems, more likely a problem with shared memory usage reducing the
    >>amount of private area available.
    >>
    >>Is it Warp 4 or 4.5? If 4.5 then you should add a SET JAVA_HIGH_MEMORY=1 to
    >>config.sys

    >
    >
    > funny thing is, that's in there, though unless recent fixpacks have
    > brought it up, it's Warp 4.


    If you have installed a fixpak >= 13, then you have the 4.5 kernel (and
    this is all this question was about).
    Then, you will have all the high memory extensions available.
    I am running Warp 4, fixpak 16 and I have high memory available. It's a
    good idea to install Theseus (look for THES4001.EXE on the internet). It
    allows you to have a look into the complete memory space and gives very
    extensive system information.

    Larfs

  5. Re: memory access problems (?)

    On Thu, 4 Jan 2007 19:54:15 UTC in comp.os.os2.setup.misc, "rafe"
    wrote:

    >
    > REM virtualaddresslimit=3072
    >
    > is that a viable number when I unREM it?


    Too big. ECS uses a default of 2048 and many report that that is too large too.
    I use 1536 without any apparent problems.

    --
    Trevor Hemsley, Brighton, UK
    Trevor dot Hemsley at ntlworld dot com

  6. Re: memory access problems (?)

    Trevor Hemsley wrote:
    > On Thu, 4 Jan 2007 19:54:15 UTC in comp.os.os2.setup.misc, "rafe"
    > wrote:
    >
    >
    >>REM virtualaddresslimit=3072
    >>
    >>is that a viable number when I unREM it?

    >
    >
    > Too big. ECS uses a default of 2048 and many report that that is too large too.
    > I use 1536 without any apparent problems.
    >

    My eCS 1.2 (non MR) uses 3072. I don't recall changing it. I have had no
    problems I attribute to that, but what do I know? What kind of problems are
    caused by too large a value? I seem to remember that 3072 was the recommended
    value when the parameter was first introduced. What is the default if the
    VIRTUALADDRESSLIMIT parameter is not used at all? (1024 springs to mind, but I
    have no way of verifying that.) I can't even remember what the problem was that
    the parameter was supposed to solve in the first place.

  7. Re: memory access problems (?)

    James J. Weinkam schrieb:
    > Trevor Hemsley wrote:
    >
    >> On Thu, 4 Jan 2007 19:54:15 UTC in comp.os.os2.setup.misc, "rafe"
    >> wrote:
    >>
    >>
    >>> REM virtualaddresslimit=3072
    >>>
    >>> is that a viable number when I unREM it?

    >>
    >>
    >>
    >> Too big. ECS uses a default of 2048 and many report that that is too
    >> large too. I use 1536 without any apparent problems.
    >>

    > My eCS 1.2 (non MR) uses 3072. I don't recall changing it. I have had
    > no problems I attribute to that, but what do I know? What kind of
    > problems are caused by too large a value? I seem to remember that 3072
    > was the recommended value when the parameter was first introduced. What
    > is the default if the VIRTUALADDRESSLIMIT parameter is not used at all?
    > (1024 springs to mind, but I have no way of verifying that.) I can't
    > even remember what the problem was that the parameter was supposed to
    > solve in the first place.

    if VIRTUALADDRESSLIMIT is not specifies, it defaults to 512. In other
    words: you don't have any high memory at all. The same as it was with
    the older kernels.

    Lars

  8. Re: memory access problems (?)

    On Fri, 5 Jan 2007 09:54:16 UTC, Lars Erdmann
    wrote:

    > if VIRTUALADDRESSLIMIT is not specifies, it defaults to 512. In other
    > words: you don't have any high memory at all. The same as it was with
    > the older kernels.


    Is this documented somewhere? I was under the impression that the
    default value is 1024.

    --
    Fred Blau
    (Change "NOSPAM@" to "systematics@" in my e-mail address)

  9. Re: memory access problems (?)

    Fred Blau wrote:
    > On Fri, 5 Jan 2007 09:54:16 UTC, Lars Erdmann
    > wrote:
    >
    >> if VIRTUALADDRESSLIMIT is not specifies, it defaults to 512. In other
    >> words: you don't have any high memory at all. The same as it was with
    >> the older kernels.

    >
    > Is this documented somewhere? I was under the impression that the
    > default value is 1024.
    >


    You can check this and many other kernel defaults using Theseus / System
    / General System / General System Information.

    With no VIRTUALADDRESSLIMIT in CONFIG.SYS I get on my system it gives:

    30. QSV_VIRTUALADDRESSLIMIT = 40000000

    Which is 1024 MB indeed.


    Sjoerd Visser




  10. Re: memory access problems (?)

    Sjoerd Visser schrieb:
    > Fred Blau wrote:
    >
    >>On Fri, 5 Jan 2007 09:54:16 UTC, Lars Erdmann
    >>wrote:
    >>
    >>
    >>>if VIRTUALADDRESSLIMIT is not specifies, it defaults to 512. In other
    >>>words: you don't have any high memory at all. The same as it was with
    >>>the older kernels.

    >>
    >>Is this documented somewhere? I was under the impression that the
    >>default value is 1024.
    >>

    >
    >
    > You can check this and many other kernel defaults using Theseus / System
    > / General System / General System Information.
    >
    > With no VIRTUALADDRESSLIMIT in CONFIG.SYS I get on my system it gives:
    >
    > 30. QSV_VIRTUALADDRESSLIMIT = 40000000
    >
    > Which is 1024 MB indeed.
    >
    >
    > Sjoerd Visser
    >
    >
    >

    Oops, sorry, yes, default is 1024.

    Lars

  11. Re: memory access problems (?)


    Trevor Hemsley wrote:
    > On Thu, 4 Jan 2007 19:54:15 UTC in comp.os.os2.setup.misc, "rafe"
    > wrote:
    >
    > > REM virtualaddresslimit=3072
    > >
    > > is that a viable number when I unREM it?

    >
    > Too big. ECS uses a default of 2048 and many report that that is too large too.
    > I use 1536 without any apparent problems.


    Trevor, regarding your setting of 1536, the ConfigTool database states
    that for the SET JAVA_HIGH_MEMORY statement to be used, "
    VIRTUALADDRESSLIMIT=2048 needs also to be set, otherwise this setting
    will be ignored. TCP 4.1 or higher must be installed."

    Regards,
    Sander


  12. Re: memory access problems (?)

    On Mon, 8 Jan 2007 20:06:21 UTC in comp.os.os2.setup.misc,
    sander.sanco@netzero.net wrote:

    > Trevor, regarding your setting of 1536, the ConfigTool database states
    > that for the SET JAVA_HIGH_MEMORY statement to be used, "
    > VIRTUALADDRESSLIMIT=2048 needs also to be set, otherwise this setting
    > will be ignored. TCP 4.1 or higher must be installed."


    I wonder where they got their info from. TCP/IP 4.1 is needed to allow the IP
    stack to access high memory, that's true, though you can code around this in an
    application by making sure that you only pass low memory to TCP/IP API calls.
    Quite why Java would check the amount of virtual memory available and refude to
    use all that is there if it's less than 2GB is beyond me (and would need special
    coding to make happen). It would be fairly easy to check using Theseus if Java
    was using it if virtualaddresslimit was less than 2048 but I don't think I have
    any java programs that I can run to check it.

    --
    Trevor Hemsley, Brighton, UK
    Trevor dot Hemsley at ntlworld dot com

  13. Re: memory access problems (?)

    In , on 01/05/2007
    at 04:42 AM, "James J. Weinkam" said:

    >My eCS 1.2 (non MR) uses 3072. I don't recall changing it. I have had
    >no problems I attribute to that, but what do I know?


    As always, it depends on your hardware/software. No two eCS/OS2 systems
    are the same. 3072 will make Acrobat 5.1 run like molasses. At 2048, 5.1
    is the most stable and functional reader you can run, although Lucide is
    coming along nicely.

    Some systems with shared video RAM choke on values above 1536 when running
    Scitech video drivers.

    The nice thing about 3072 is that Java apps do run better. Also, apps
    like pmview can take advantage of the additional ring3 address space. The
    same will be true for the Mozilla apps, but this is a work in progress.
    Knut is applying his typical magic so that libc will intelligently use
    upper memory for those kernel APIs that support it.

    Steven

    --
    --------------------------------------------------------------------------------------------
    Steven Levine MR2/ICE 2.67 #10183
    Warp/eCS/DIY/14.103a_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
    --------------------------------------------------------------------------------------------


  14. Re: memory access problems (?)

    Steven Levine wrote:
    > In , on 01/05/2007
    > at 04:42 AM, "James J. Weinkam" said:
    >
    >
    >>My eCS 1.2 (non MR) uses 3072. I don't recall changing it. I have had
    >>no problems I attribute to that, but what do I know?

    >
    >
    > As always, it depends on your hardware/software. No two eCS/OS2 systems
    > are the same. 3072 will make Acrobat 5.1 run like molasses. At 2048, 5.1
    > is the most stable and functional reader you can run, although Lucide is
    > coming along nicely.
    >
    > Some systems with shared video RAM choke on values above 1536 when running
    > Scitech video drivers.
    >
    > The nice thing about 3072 is that Java apps do run better. Also, apps
    > like pmview can take advantage of the additional ring3 address space. The
    > same will be true for the Mozilla apps, but this is a work in progress.
    > Knut is applying his typical magic so that libc will intelligently use
    > upper memory for those kernel APIs that support it.
    >
    > Steven
    >

    Thanks for the explanation. I rarely use any version of Acrobat since it's been
    a long time since anyone has sent me a pdf that ghostscript can't handle. I am
    using the Scitech drivers that come with eCS1.2MR without problems. I do use
    PMView quite a bit. For now, since it ain't broke, I ain't gonna fix it!

  15. Re: memory access problems (?)

    Hi

    Trevor Hemsley wrote:
    > On Mon, 8 Jan 2007 20:06:21 UTC in comp.os.os2.setup.misc,
    > sander.sanco@netzero.net wrote:
    >
    >> Trevor, regarding your setting of 1536, the ConfigTool database states
    >> that for the SET JAVA_HIGH_MEMORY statement to be used, "
    >> VIRTUALADDRESSLIMIT=2048 needs also to be set, otherwise this setting
    >> will be ignored. TCP 4.1 or higher must be installed."

    >
    > I wonder where they got their info from. TCP/IP 4.1 is needed to allow the IP
    > stack to access high memory, that's true, though you can code around this in an
    > application by making sure that you only pass low memory to TCP/IP API calls.
    > Quite why Java would check the amount of virtual memory available and refude to
    > use all that is there if it's less than 2GB is beyond me (and would need special
    > coding to make happen). It would be fairly easy to check using Theseus if Java
    > was using it if virtualaddresslimit was less than 2048 but I don't think I have
    > any java programs that I can run to check it.
    >



    Of possible interest:

    I use VIRTUALADDRESSLIMIT=1536 on my systems here for a very simple
    non-technical couple of reasons.

    1] With VIRTUALADDRESSLIMIT=2048 the SNAP driver displays half of the
    memory onboard my ati x600 Pro 256MB ie System, Screen page displays
    "Memory: 128Mb".
    Also I found that running several biggish apps at the same time,
    Seamonkey, OpenOffice for Windows (via ar5os2.exe) plus various smaller
    apps (some native, some java), was causing strange system slowdowns and
    occasional hangs.

    2] With VIRTUALADDRESSLIMIT=1024 I cannot run Borland JBuilderX Personal
    (using java142 sdk) - it simply will not start.


    So VIRTUALADDRESSLIMIT=1536 seems to be the "balancing point" on this
    system currently.


    Regards

    Pete

  16. Re: memory access problems (?)

    On Wed, 10 Jan 2007 16:57:46 UTC in comp.os.os2.setup.misc, Peter Brown
    wrote:

    > So VIRTUALADDRESSLIMIT=1536 seems to be the "balancing point" on this
    > system currently.


    Likewise, I run 1536 because Pronews can handle large enough newsgroups at this
    setting for my use. At 1GB, it tops out around 1,000,000 articles and I've
    subscribed to groups with 1.2 million.

    --
    Trevor Hemsley, Brighton, UK
    Trevor dot Hemsley at ntlworld dot com

  17. Re: memory access problems (?)

    well, I unremmed the virtualaddresslimit statement and rebooted with it
    set to 1024; after about 2.5 days, when I taxed the system with a Java
    program (Moneydance) I got some nasty, WPS-reset-inducing,
    application-freezing video corruption which necessitated a 3-finger
    reboot, so I've reset it to 1536. we'll see how that holds up.

    as I recall I once tried to install Theseus, but it blew up on me. I
    have got the System Information tool, which reports as "Current CSD"
    XR0M015_, which I presume is FP15. fwiw, I noticed that this NVIDIA
    Geforce2 MX/MX 400 (I think that's the card in there) is shown as
    having 64MB by both the SNAP page and the system information tool,
    whether virtualaddresslimit is set to 1024 or 1536. I thought it had
    more than that but (of course) I don't know.


  18. Re: memory access problems (?)

    After almost 3 days booted with virtualaddresslimit=1536, I got the
    same Java error.

    Perhaps this latest episode in the scenario will provide another clue:
    I started shutting down applications in preparation for a reboot. this
    caused my desktop to reset -- it might have been StarOffice shutting
    down which actually caused this, though I don't know. (I am using SO
    5.1 for the moment, which has been misbehaving -- sometimes soffice.ini
    gets corrupted; more recently, trying to open SO desktop templates
    fails & crashed SO, which I suspect is related to the memory access
    issue.)

    When my desktop came back thanks to XWorkplace, I opened an app and
    typed into it. I then tried to open Moneydance again, this time
    successfully. However, shortly thereafter, the WPS effectively froze
    me out -- I could no longer use the application, nor select any apps
    from the desktop, and Ctrl-Atl-Del'd my way back to this boot.

    Now running virtualaddresslimit=3072, and about to install the latest
    XWorkplace update.

    -rt


  19. Re: memory access problems (?)

    On Jan 4, 11:22 am, "rafe" wrote:

    > "Can't find/run J2WIN.DLL (rc=8, module INNOWIN)"


    just to update: things are somewhat more stable with
    virtualaddresslimit=3072; however, often after 2-3 days, I get
    instability, particularly with video.

    I haven't ruled out a Doodle-screen-saver-related problem. at this
    point I'm using only a single simple module.

    just a short while ago, I tried starting Moneydance to pay some bills,
    uptime 4:10:45:00. that same J2WIN error returned. then I closed
    Firefox (the most recent official release) and Moneydance was able to
    start.

    -rt




+ Reply to Thread