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