AcpiDaemon start

[Igor]

I have clarified an interesting pattern.
After moving acpidaemon in Startup.cmd

Code: [Select]

detach acpidaemon.exe, the system has never been hanging when loading.
At the same time, when the demon started in the config - at the first launch of Villo in 80% of cases, during a reboot of another 10%.
Also, loading without detection of the mouse ceased to occur (USB start error).
Such errors at starting regularly occurred. The system is loaded, but the USB does not function.

I use mainly OS4 core.

[Dariusz Piatkowski]

Hmm...always had it in CONFIG.SYS, never tried in startup.cmd, but I am not experiencing the sort of issues you are seeing.

[Igor]

Hmm...always had it in CONFIG.SYS, never tried in startup.cmd, but I am not experiencing the sort of issues you are seeing.

I understand that these are synchronization errors between different processes. They are not always manifested and only on certain hardware.

[roberto]

Hello, I have tested what you say and it also works better for me in the startup folder, and removing it from the config.sys.
 But not on all computers.
Saludos

[David Graser]

Hello, I have tested what you say and it also works better for me in the startup folder, and removing it from the config.sys.
 But not on all computers.
Saludos

I agree.  The system seems more stable with it moved to the Startup folder.

[David Graser]

The system seems more stable with it moved to the Startup folder.  Firefox was always crashing until I did this.

One other thing I am trying.
 
I downloaded a program called The PM Queue Size Patch.
 
These patches may provide tremendous stability in OS/2 systems
that suffer from desktop hangs, no-input in shells, invalid switching
between the desktop and Window/DOS applications, and other
ailments.  These patches are not meant to be a complete OS/2 fix,
but may be lots of help. I followed its instruction and added the necessary line to the

startup.cmd:

@ECHO OFF
RUN=E:\OS2\ACPIDAEMON.EXE
PMQSIZE E:\OS2\DLL\PMWIN.DLL 190 /Q
exit

I added the /Q because the cmd prompt window would come up showing what it was doing.  However, I could not get it to close until I added /Q

THEORY:

Every PM thread that sends PM messages or receives posted
messages must have a queue to hold those messages until they are
processed. Messages are very frequently put into those messages queues
to be processed as the thread is able.  If more messages are put into
the queue than the queue can hold, then it is reasonable to expect
problems in the system, ranging from trivial glitches to system
hangs.  The default size for these queues in OS/2 is only 10 messages.
This seems very small considering the number of message-generating
activities going on in a busy OS/2 system.

Many OS/2 users experience problems in running OS/2 that I speculate
are caused, or at least exacerbated, by this too-small queue.

Two partitions appear to be running great with these two changes.  The big thing is moving the

RUN=E:\OS2\ACPIDAEMON.EXE

to the startup.cmd

[Roderick Klein]

If you think there is an issue and you reproduce this on one machine you have with the ArcaOS kernel loaded open a ticket via https://mantis.arcanoae.com.
Attach a testlog and describe how you can reproduce a hang.

Roderick Klein

[David Graser]

If you think there is an issue and you reproduce this on one machine you have with the ArcaOS kernel loaded open a ticket via https://mantis.arcanoae.com.
Attach a testlog and describe how you can reproduce a hang.

Roderick Klein

Hi Roderick

For me, Firefox would always crash and I would have to restart it.  Moving that statement to the startup.cmd and keeping my fingers crossed, it has not crashed in two days.  Before, it was all the time.  On two partitions, not one crash so far.

[Roderick Klein]

If you think there is an issue and you reproduce this on one machine you have with the ArcaOS kernel loaded open a ticket via https://mantis.arcanoae.com.
Attach a testlog and describe how you can reproduce a hang.

Roderick Klein

Hi Roderick

For me, Firefox would always crashed and I would have to restart it.  Moving that statement to the startup.cmd and keeping my fingers crossed, it has not crashed in two days.  Before, it was all the time.  On two partitions, not one crash so far.

Having worked on eCS for 10  years i would be carefull to conclude that certain patches work.
It could but, so much happens in code of the OS st startup. It could be something else.
If you think you can reliably reproduce this issue on Arcaos open a ticket please.
If you discuss it here and its an issue it will never get fixe in Arcaos.

Roderick

[Rich Walsh]

I downloaded a program called The PM Queue Size Patch.

From the "Presentation Manager Programming Guide and Reference":

WinCreateMsgQueue(hab, lQueuesize);

lQueuesize (LONG) - input
Maximum queue size.

This parameter is ignored for versions higher than version 3 of the OS/2 operating system. The lQueuesize parameter is dynamically allocated. The maximum queue size should be set to zero.

For version 3 and lower of the OS/2 operating system, this parameter is the maximum number of messages that can be queued.

0 - Use the system default queue size which is 10 messages.

Other - Maximum queue size.

[David Graser]

What you are saying is that this programmer did not have all his facts straight.  This patch that I applied said it was for Warp version.  So, is this patch ignored after it is applied by Warp and later?

[Dave Yeo]

It says "version 3 and lower", Warp was version 3. Wouldn't be surprised if FP17changed that as it had the SIQ fix in it.

[Rich Walsh]

What you are saying is that this programmer did not have all his facts straight.

No, He was correct in **1995**

This patch that I applied said it was for Warp version.

On or around April 25, 1995 (the date of the package), that was Warp *v3*.

So, is this patch ignored after it is applied by Warp and later?

I'm not willing to try it to find out. All I know is that it attempts to fix a problem that doesn't exist on Warp v4.5. Even without access to the PM Ref, I still wouldn't have tried a fix that doesn't mention 4.5 but does mention 2.x. If it were genuinely useful, most everybody would know about it and be using it - but they're not. That should tell you something...

[Roderick Klein]

If you think there is an issue and you reproduce this on one machine you have with the ArcaOS kernel loaded open a ticket via https://mantis.arcanoae.com.
Attach a testlog and describe how you can reproduce a hang.

Roderick Klein

Hi Roderick

For me, Firefox would always crash and I would have to restart it.  Moving that statement to the startup.cmd and keeping my fingers crossed, it has not crashed in two days.  Before, it was all the time.  On two partitions, not one crash so far.

[Roderick Klein]

What you are saying is that this programmer did not have all his facts straight.  This patch that I applied said it was for Warp version.  So, is this patch ignored after it is applied by Warp and later?

Over the years I have heard more claims that certain patches magically fix something. My take on it is the only to way find out for real is with process dump or a memory dump.
The problem is when the PMSHELL comes up so much code is running and that can trigger other things. A great example was the looping sound example where the startup system sound would loop.
People thought it was a bug in Uniaud. It turned out it was a bug in SND.DLL that deals with the system sounds. David found it while looking at under the kernel debugger.
So yes it MIGHT fix it, but please do not make assumptions to quickly. Moving things around in memory by making buffers bigger, changing load order is not yet an indication its really fixed.
But rather worked around by accident.

Roderick Klein