I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processingcrashing - VMS

This is a discussion on I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processingcrashing - VMS ; The last time we had a DECwindows problem, posting it here help as much as calling HP technical support, so here the scoop ... We have a large number of rx2620's and a few rx2660's installed at customer sites, and ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processingcrashing

  1. I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processingcrashing

    The last time we had a DECwindows problem, posting it here help as
    much as calling HP technical support, so here the scoop ...

    We have a large number of rx2620's and a few rx2660's installed at
    customer sites, and all have the same problem. Every time a user logs
    into the DECwindows console the x-server process grows in page count.
    When the user logs out you would expect the memory page count to go
    down, but it does not. The next time anyone logs into the DECwindows
    console, the page count again increases. You do this enough times, and
    the x-server crashes.

    We were concerned that any modifications we have made to the
    configuration of VMS and DECwindows might be the cause of the problem.
    We modify the logical decw$system_defaults, update the quotas for
    multiheaded/xinerama displays, and modify both decw$private setup
    files. We decided to do another test to eliminate this possibility.

    I took a brand new rx2660 and installed VMS V83, and the VMS patch
    UPDATE5 onto a blank disk. I selected all of the defaults for the VMS
    install. I then repeated the test to see if we received the same
    results, and we did. The x-server continued to grow each time we
    repeated the test.

    One attribute of this failure is that restarting the x-server after it
    fails seldom works. After the x-server fails, in restart the x-server
    just fails again, leaving an orphaned LOGINOUT.EXE process. Maybe one
    in ten trys at restarting DECwindows works, but when it works the
    initial page count for the process is much larger than what it would
    normally be after a VMS reboot and DECwindows restart.

    The test I preformed is:

    * Login to the system
    * Create a DECterm
    * show system/proc=DECW* and record the statistics from the DECW
    $SERVER_0 process
    * Without logging out the DECterm, quit the CDE or old DECwindow
    session
    * Do it again and compare the results.

    This test is very repeatable, and anyone should be able to generate a
    system like I did and get the same results. The amount the x-server
    grows varies between 200 and 500 pages per login/out. The rate of
    increase is not linear.

    Also, please note that so far the AXP systems we field do not have
    this problem. We field VMS 7.3-2 and DECWindows 1.26 on our AXP
    systems.

    I truthfully do not know how long this problem has existed, but we
    recently started to notice the crashes at a customer site. At this
    site, they religiously login at the beginning of their shift, and
    logout at the end. They have 3 shifts, so the problem might just show
    up at their site quicker than at other customer sites. We have been
    dialing into our other I64 customer sites, and so far it looks like
    all of these customer have the problem to some degree.

    Hopefully someone out there is having the same problem, but has not
    noticed it yet. Your support in prodding HP into a fix would be
    appreciated.

    Maybe someone out there has seen and has already found a fix to this
    problem. Any information you can provide me would also be appreciated.

    All help will be appreciated, and your karma point count increase.
    What a way to end the year.

    Happy New Years

    mjjerabek
    mjjerabek@gnail.com

  2. Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing

    "mjjerabek" wrote in message
    news:1503a949-aa96-4fbd-9ceb-c277361f5d06@i7g2000prf.googlegroups.com...
    > The last time we had a DECwindows problem, posting it here help as
    > much as calling HP technical support, so here the scoop ...
    >


    I suggest the call to support. We can't fix things that we don't know
    about.

    Now to answer some misconceptions...

    Logging out of a session resets the server, but it does not restart the
    process.

    The most common cause of server page count growth is pixmaps that are
    created and never deleted. In addition, it is possible to fragment heap
    space because alloc/free does not do garbage collection.

    The X11 server code source is identical between Alpha and IPF. But it is
    possible you don't see the issue on Alpha because IPF uses more memory - and
    you are stablizing on Alpha before you hit a quota limit. It is also
    possible that the memory footprint of the device specific layer is different
    if the graphics adapters are not identical - the Radeon server will use a
    lot more memory that a VX1 or TGA2 for example. Or it is possible there is
    a memory leak in the XServer (to be honest, I know that the code leaks like
    a sieve - the MIT folks were terrible at cleaning up memory).

    The first thing to do is to increase pagefile quota in the server. The
    temporary workaround is to periodically restart the server instead of ending
    the session and logging back in (@SYS$MANAGERECW$STARTUP RESTART)

    There is (or should be) a graphics update patch for V8.3 I64 that you should
    apply, since it fixes many problems.




  3. Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processingcrashing

    On Jan 3, 7:15 am, "FredK" wrote:
    > "mjjerabek" wrote in message
    >
    > news:1503a949-aa96-4fbd-9ceb-c277361f5d06@i7g2000prf.googlegroups.com...
    >
    > > The last time we had a DECwindows problem, posting it here help as
    > > much as calling HP technical support, so here the scoop ...

    >
    > I suggest the call to support. We can't fix things that we don't know
    > about.


    Already done ... I called HP first and then posted here second.

    It turns out from testing that the "memory leak" is caused because I
    am using a 24bpp displays. If I switch the display to 16bpp as
    suggested by HP technical support, and repeat my test, the problem
    does not appear. My application runs as either PseudoColor or 24bpp
    TrueColor, so if one of my customers has not used the enhanced color
    features in my application, I will temporarily switch them to
    PseudoColor until a fix from HP can be generated. I have never tested
    my application as 16bpp, but it should work. I will have to do some
    small testing to validate that my application features don't break
    under 16bpp.

    >
    > Now to answer some misconceptions...
    >
    > Logging out of a session resets the server, but it does not restart the
    > process.
    >
    > The most common cause of server page count growth is pixmaps that are
    > created and never deleted. In addition, it is possible to fragment heap
    > space because alloc/free does not do garbage collection.
    >
    > The X11 server code source is identical between Alpha and IPF. But it is
    > possible you don't see the issue on Alpha because IPF uses more memory - and
    > you are stablizing on Alpha before you hit a quota limit. It is also
    > possible that the memory footprint of the device specific layer is different
    > if the graphics adapters are not identical - the Radeon server will use a
    > lot more memory that a VX1 or TGA2 for example. Or it is possible there is


    We have a 100 or so DS10/DS20 machines running with radeon cards at
    24bpp with no problems. This is exclusively a IPF issue.

    Also, it does not matter whether we use an I64 machine with management
    console hosted radeon, or an addon radeon card for systems with no
    management console, the problem happens everywhere.

    Also, this is exclusively a HP application problem. I can crash the x-
    server by logging into a CDE or old DECwindow session, creating a
    DECterm, logging out, and repeating this sequence a 100 or so times.
    My customer tend to have 24x7 coverage with 3 shifts per day. Their
    systems tend to crash after about a month. The old legacy AXP systems
    that sit right next some of these I64 systems have no worries.

    This problem is extremely reproducible. Generate a rx26xx system
    running basic OpenVMS V83. Added the UPDATE5 patch for rx2660 systems
    so the management console radeon gets recognized, and run my test. The
    problem always happens.

    > a memory leak in the XServer (to be honest, I know that the code leaks like
    > a sieve - the MIT folks were terrible at cleaning up memory).
    >
    > The first thing to do is to increase pagefile quota in the server. The
    > temporary workaround is to periodically restart the server instead of ending
    > the session and logging back in (@SYS$MANAGERECW$STARTUP RESTART)


    Done. It was the first lesson taught at a AXP to I64 porting class I
    attended that HP taught last year. My DECW quotas turn out to be a bit
    more generous than the suggested quotas from that class and from HP
    technical support (yesterday).

    >
    > There is (or should be) a graphics update patch for V8.3 I64 that you should
    > apply, since it fixes many problems.


    This problem happens whether the graphics patch #1 is installed or
    not. I also added the Motif ECO2 to the mix hoping that it would
    contribute to a solution, but nothing changed.

    As a side question, am I the only person using OpenVMS/DECWindow with
    24bpp displays. I can not believe no one else has seen this problem.

    This problem has been elevated to HP engineering. I will continue to
    post progress and the eventual solution.

  4. Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing


    "mjjerabek" wrote in message
    news:f0db0db6-3a7a-4142-ac51-64d331861c1f@d21g2000prf.googlegroups.com...
    > On Jan 3, 7:15 am, "FredK" wrote:
    >> "mjjerabek" wrote in message
    >>
    >> news:1503a949-aa96-4fbd-9ceb-c277361f5d06@i7g2000prf.googlegroups.com...
    >>


    > As a side question, am I the only person using OpenVMS/DECWindow with
    > 24bpp displays. I can not believe no one else has seen this problem.
    >


    24 bit is the default for the Radeon, so I expect that most customers are
    using 24 bit. It is entirely possible that customers don't log in/out
    enough times between boots to see a problem.

    The Radeon code and server code is common between Alpha and IA64 - so that
    too is a mystery.

    One thing that changing the depth to 16bpp does is to disable 3D and run the
    server in a mostly PIO mode instead of DMA. You might as an experiment try
    editing DECW$DEVICE_CONFIG_GH.COM and comment out the adding of the OpenGL
    extension to the extension list, and

    $ define /system DECW$SERVER_NOACCEL 1

    This will disable loading the OpenGL direct rendering code.





  5. Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processingcrashing

    On Jan 3, 3:22 pm, "FredK" wrote:
    > "mjjerabek" wrote in message
    >
    > news:f0db0db6-3a7a-4142-ac51-64d331861c1f@d21g2000prf.googlegroups.com...
    >
    > > On Jan 3, 7:15 am, "FredK" wrote:
    > >> "mjjerabek" wrote in message

    >
    > >>news:1503a949-aa96-4fbd-9ceb-c277361f5d06@i7g2000prf.googlegroups.com...

    >
    > > As a side question, am I the only person using OpenVMS/DECWindow with
    > > 24bpp displays. I can not believe no one else has seen this problem.

    >
    > 24 bit is the default for the Radeon, so I expect that most customers are
    > using 24 bit. It is entirely possible that customers don't log in/out
    > enough times between boots to see a problem.
    >
    > The Radeon code and server code is common between Alpha and IA64 - so that
    > too is a mystery.
    >
    > One thing that changing the depth to 16bpp does is to disable 3D and run the
    > server in a mostly PIO mode instead of DMA. You might as an experiment try
    > editing DECW$DEVICE_CONFIG_GH.COM and comment out the adding of the OpenGL
    > extension to the extension list, and
    >
    > $ define /system DECW$SERVER_NOACCEL 1
    >
    > This will disable loading the OpenGL direct rendering code.


    In additional testing I found yet another radeon/I64 problem. As I
    said before I would be telling my customer who can to use PseudoColor/
    8bpp visuals with my application. Before I did this I decided, all
    things being considered, to test it out on a few I64 systems we have.
    PseudoColor is how we ran our application for 15 years on Vaxen and
    Alphas under VMS, but I had a bad feeling.

    On an rx2620 with an add in radeon and no management console, I set
    the visual number to 3, the BPP to 8, the pixel resolution to
    1280x1024@75Hz and restarted DECwindows. The display came up
    Technicolor (all the colors were wrong). I was amazed. I tried this
    same test on an rx2660 (copied the decw$private_server_setup file from
    the rx2620) using the management console video card and everything
    worked perfectly. I am most likely going to open an additional service
    call (tomorrow) on this problem, but ???

    Please note, I have been also doing all of these tests on a DS10 with
    an add in radeon card with no troubles. The DS10 is running VMS 7.3-2
    with DECwindows 1.2-6 and all the ECO's. The I64 machines are running
    VMS V83, with DECWindows 1.6, at least UPDATE3, and all the DECwindows
    ECOs. All machines have at least 2GB of ram and the quotas for the x-
    server are generous.

    I will try (tomorrow) as you suggested in you comments above. It will
    be a good data point for technical support. I will continue to
    post progress and the eventual solution.


  6. Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processingcrashing

    mjjerabek wrote:
    > On Jan 3, 3:22 pm, "FredK" wrote:
    >
    >>"mjjerabek" wrote in message
    >>
    >>news:f0db0db6-3a7a-4142-ac51-64d331861c1f@d21g2000prf.googlegroups.com...
    >>
    >>
    >>>On Jan 3, 7:15 am, "FredK" wrote:
    >>>
    >>>>"mjjerabek" wrote in message

    >>
    >>>>news:1503a949-aa96-4fbd-9ceb-c277361f5d06@i7g2000prf.googlegroups.com...

    >>
    >>>As a side question, am I the only person using OpenVMS/DECWindow with
    >>>24bpp displays. I can not believe no one else has seen this problem.


    I've never seen it, but I seldom log off my I64 console. (I'm the
    only person who uses the graphics console, I just lock the screen
    when I go home and unlock it in the morning. I usually create about
    a dozen DECterms when I log in, and usually leave them up until I
    log out, so if there is a memory leak as you describe, I probably
    wouldn't notice it.) Usually I only log out if I need to reboot for
    some reason, which would clear any such problem. (rx2620, console
    Radeon graphics, default settings, VMS V8.3, DECwindows V1.6 with
    all patches.)



    >>
    >>24 bit is the default for the Radeon, so I expect that most customers are
    >>using 24 bit. It is entirely possible that customers don't log in/out
    >>enough times between boots to see a problem.
    >>
    >>The Radeon code and server code is common between Alpha and IA64 - so that
    >>too is a mystery.
    >>
    >>One thing that changing the depth to 16bpp does is to disable 3D and run the
    >>server in a mostly PIO mode instead of DMA. You might as an experiment try
    >>editing DECW$DEVICE_CONFIG_GH.COM and comment out the adding of the OpenGL
    >>extension to the extension list, and
    >>
    >>$ define /system DECW$SERVER_NOACCEL 1
    >>
    >>This will disable loading the OpenGL direct rendering code.

    >
    >
    > In additional testing I found yet another radeon/I64 problem. As I
    > said before I would be telling my customer who can to use PseudoColor/
    > 8bpp visuals with my application. Before I did this I decided, all
    > things being considered, to test it out on a few I64 systems we have.
    > PseudoColor is how we ran our application for 15 years on Vaxen and
    > Alphas under VMS, but I had a bad feeling.
    >
    > On an rx2620 with an add in radeon and no management console, I set
    > the visual number to 3, the BPP to 8, the pixel resolution to
    > 1280x1024@75Hz and restarted DECwindows. The display came up
    > Technicolor (all the colors were wrong). I was amazed. I tried this
    > same test on an rx2660 (copied the decw$private_server_setup file from
    > the rx2620) using the management console video card and everything
    > worked perfectly. I am most likely going to open an additional service
    > call (tomorrow) on this problem, but ???
    >
    > Please note, I have been also doing all of these tests on a DS10 with
    > an add in radeon card with no troubles. The DS10 is running VMS 7.3-2
    > with DECwindows 1.2-6 and all the ECO's. The I64 machines are running
    > VMS V83, with DECWindows 1.6, at least UPDATE3, and all the DECwindows
    > ECOs. All machines have at least 2GB of ram and the quotas for the x-
    > server are generous.
    >


    Didn't you assert previously that this was an I64 problem and not an
    Alpha problem? If it hasn't been tried on an Alpha with VMS 8.3 and
    DECwindows V1.6, it could very well be a generic VMS 8.3 problem and
    not an I64-specific problem.


    > I will try (tomorrow) as you suggested in you comments above. It will
    > be a good data point for technical support. I will continue to
    > post progress and the eventual solution.
    >



    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  7. Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing


    "mjjerabek" wrote in message
    news:461adcf1-dc61-44ca-9621-379a117ee6bc@i7g2000prf.googlegroups.com...
    > On Jan 3, 3:22 pm, "FredK" wrote:
    >> "mjjerabek" wrote in message
    >>
    >> news:f0db0db6-3a7a-4142-ac51-64d331861c1f@d21g2000prf.googlegroups.com...
    >>
    >> > On Jan 3, 7:15 am, "FredK" wrote:
    >> >> "mjjerabek" wrote in message

    >>
    >> >>news:1503a949-aa96-4fbd-9ceb-c277361f5d06@i7g2000prf.googlegroups.com...

    >>


    > Alphas under VMS, but I had a bad feeling.
    >
    > On an rx2620 with an add in radeon and no management console, I set
    > the visual number to 3, the BPP to 8, the pixel resolution to
    > 1280x1024@75Hz and restarted DECwindows. The display came up
    > Technicolor (all the colors were wrong). I was amazed. I tried this
    > same test on an rx2660 (copied the decw$private_server_setup file from
    > the rx2620) using the management console video card and everything
    > worked perfectly. I am most likely going to open an additional service
    > call (tomorrow) on this problem, but ???
    >


    There is an ECO patch kit that *should* be available to fix this and other
    problems (for V8.3, we will also be doing a V7.3-2 and V8.2 kit). The
    workaround is to use the other video connector.

    The Radeon card has two connectors (DVI and analog) and we run the same
    video out both of them - but each has a seperate RAMDAC. The driver
    developer was pre-enabling a feature he never completed... and broke the
    code that updates *both* of the RAMDACs. So you get the correct colors on
    one, and bogus colors on the other (which never gets updated).

    The problem has been out there since V8.3.




  8. Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing


    "Richard Maher" wrote in message
    news:flmndf$ctl$1@news-01.bur.connect.com.au...

    >
    > So when it comes to VMSINSTAL, 7.3-2 was "beyond support" back in April
    > last
    > year and 8.2 was "lightly used", but all of a sudden when it comes to
    > Daddy's little DECwindows, no expense and engineering/kitting effort shall
    > be spared?
    >
    > Just more of the same from the same :-(
    >
    > Regards Richard Maher
    >


    You are a little butterfly of happyness aren't you. The kit rolls up a
    number of fixes that had been supplied to customers as one final official
    patch kit. Did we "have to do it"? No. But it was the right thing to do.

    What is the chip on your shoulder made of?





  9. Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing

    Hi,

    "FredK" wrote in message
    news:flke43$6a6$1@usenet01.boi.hp.com...
    > (for V8.3, we will also be doing a V7.3-2 and V8.2 kit).


    And in: -
    http://groups.google.com/group/comp....6d51b15237dde2
    on 25-Apr-2007 a FredK wrote:-
    >>>>>>>>>>>

    To be honest, we try to generate patch kits for the "mainstream" versions -
    even when the mainstream is sometimes beyond support end of life (like
    V7.3-2). V8.2 falls into the category of "lightly used" - so patches there
    tend to get generated when a customer requests one.
    <<<<<<<<<<<

    So when it comes to VMSINSTAL, 7.3-2 was "beyond support" back in April last
    year and 8.2 was "lightly used", but all of a sudden when it comes to
    Daddy's little DECwindows, no expense and engineering/kitting effort shall
    be spared?

    Just more of the same from the same :-(

    Regards Richard Maher

    "FredK" wrote in message
    news:flke43$6a6$1@usenet01.boi.hp.com...
    >
    > "mjjerabek" wrote in message
    > news:461adcf1-dc61-44ca-9621-379a117ee6bc@i7g2000prf.googlegroups.com...
    > > On Jan 3, 3:22 pm, "FredK" wrote:
    > >> "mjjerabek" wrote in message
    > >>
    > >>

    news:f0db0db6-3a7a-4142-ac51-64d331861c1f@d21g2000prf.googlegroups.com...
    > >>
    > >> > On Jan 3, 7:15 am, "FredK" wrote:
    > >> >> "mjjerabek" wrote in message
    > >>
    > >>

    >>news:1503a949-aa96-4fbd-9ceb-c277361f5d06@i7g2000prf.googlegroups.com...
    > >>

    >
    > > Alphas under VMS, but I had a bad feeling.
    > >
    > > On an rx2620 with an add in radeon and no management console, I set
    > > the visual number to 3, the BPP to 8, the pixel resolution to
    > > 1280x1024@75Hz and restarted DECwindows. The display came up
    > > Technicolor (all the colors were wrong). I was amazed. I tried this
    > > same test on an rx2660 (copied the decw$private_server_setup file from
    > > the rx2620) using the management console video card and everything
    > > worked perfectly. I am most likely going to open an additional service
    > > call (tomorrow) on this problem, but ???
    > >

    >
    > There is an ECO patch kit that *should* be available to fix this and other
    > problems (for V8.3, we will also be doing a V7.3-2 and V8.2 kit). The
    > workaround is to use the other video connector.
    >
    > The Radeon card has two connectors (DVI and analog) and we run the same
    > video out both of them - but each has a seperate RAMDAC. The driver
    > developer was pre-enabling a feature he never completed... and broke the
    > code that updates *both* of the RAMDACs. So you get the correct colors on
    > one, and bogus colors on the other (which never gets updated).
    >
    > The problem has been out there since V8.3.
    >
    >
    >




+ Reply to Thread