From: "Steven Levine" <ecs-isp@2rosenthals.com>
Message-ID: <6592ee62.20.mr2ice.fgrirsq@earthlink.net>
Date: Mon, 01 Jan 2024 08:54:58 -0800
To: "eCS ISP Mailing List" <ecs-isp@2rosenthals.com>
In-Reply-To: <list-8792046@2rosenthals.com>
Subject: Re: [eCS-ISP] apache+php and VA limit

In <list-8792046@2rosenthals.com>, on 12/26/23
   at 02:01 PM, "Massimo S." <ecs-isp@2rosenthals.com> said:


Hi,

Happy New Year.

>after more than 3 weeks i've to say that raising the value of VAL has
>improved overall system stability

This is true for most systems.

>of course in that condition the server is not accessible, with mouse,
>keybord or remote

Does the mouse still move or is it stuck in place?

>it also save the previous DUMP and do the new one, so i've 2 dumps the
>situation good and the situation bad
>this could be of any help?

Hang on to them for now.  I'll let you know when I am ready to look at
them.  We won't know if they contain any useful clues until we look.

Based on the GETRAM output, you need to try to kill a few more processes
before attemping the setboot.

I would start with:

>0008    0.133M    0.027M       34        7  ACPIDAEM
>0019    0.414M    0.168M      106       43  PMSPOOL
>0020    0.066M    0.039M       17       10  CMD
>0022    0.188M    0.066M       48       17  CMD
>0059    3.684M    2.340M      943      599  GATEWAY
>0065   10.605M   10.047M     2715     2572  HTTPX
>0066    0.070M    0.039M       18       10  CMD
>0092    1.660M    3.699M      425      947  HTTPX
>0093    6.996M    3.691M     1791      945  HTTPX
>0094   12.320M    5.496M     3154     1407  HTTPX
>0095   12.293M    5.535M     3147     1417  HTTPX
>0096   12.297M    5.500M     3148     1408  HTTPX
>0097    0.293M    0.066M       75       17  CMD

Of course you will not be able to kill te stuck httpx and you need to
avoid killing your cmd.exe session.

The kernel is going to try to kill these process off on it's own.  You are
getting helping it out.

>0105    0.105M    0.012M       27        3  PROCDUMP

PROCDUMP should not be running.

>but if it's apache with his unkillable child all these improvements will
>not help for sure, since afaik in  some way it lock something in the file
>system that prevent the normal reboot with setboot /b

My experience is that unkillable processes do not prevent reboots.  The
kernel will attempt to kill all the existing processes, but it is fully
aware that the kill might fail and this will not prevent the reboot.

My gut feel is that this is more of a hardware issue.  A

>i also don't know if there something more powerful to the setboot /b that
>is able to reboot the system also in those situations

Don't you think that after all the years you have used OS/2, if such a
thing existed, you would already know about it?

BTW, which version of setboot are you using?  There's the AiRBoot version,
the IBM version and the dfsee version.  They all invoke the same IOCTL to
do the reboot.

Steven

-- 
----------------------------------------------------------------------
"Steven Levine" <steve53@earthlink.net>  Warp/DIY/BlueLion etc.
www.scoug.com www.arcanoae.com www.warpcave.com
----------------------------------------------------------------------