OS/2, eCS & ArcaOS - Technical > Internet

PMMail and EARLYMEMINIT=TRUE problem?

<< < (2/4) > >>

Dariusz Piatkowski:
Sigurd's right on the money here...I used to run HPFS386 on all my drives, switched to JFS about a year ago (or so). With the HPFS386 cache sizes, even small ones, I was never able to use that setup.

Today...well, PMMail was the only app I noted failed consistently. There may be other ones as well, but given how important email is I never actually got beyond that testing criteria.

Here are some of the CONFIG.SYS entries:


--- Code: ---...
VIRTUALADDRESSLIMIT=2560
REM EARLYMEMINIT=TRUE
REM DLLBASING=OFF
...

--- End code ---

My JFS cache is set to 128Meg, and otherwise I do not think there is anything unusual about my setups.

Plenty of free shared memory (as reported by the 'Free Shared Mem' utility) over 150Meg.

Is there anything I can do to capture the crash I'm seeing? So far nothing in the LOG directory, nor in popuplog.os2.

Doug Bissett:
Take out both REMs, and you probably won't have any more problems, for a while. REM DLLBASING=OFF causes shared memory to allocate on memory boundaries, which causes a lot of fragmentation. You may have 150 M left, but if the biggest chunk is 20 K, you have a major problem.

Older systems would be slowed by using DLLBASING=OFF, but any system after the 486SX won't have any problems with it.

Recently, I have abandoned using 128 M for JFS cache too (no setting, which means 64 M), but the jury is still out on that one. I am inclined to think that it is okay at 128 M (at least it doesn't use lower shared memory, like HPFS does).


--- Quote ---Plenty of free shared memory (as reported by the 'Free Shared Mem' utility) over 150Meg.
--- End quote ---

Don't be fooled by that. I have seen lower shared memory drop from 180 M to about 5K, in seconds (another 6K, and the system would probably crash, or hang). The biggest "problem", that I have now, is trying to run VBox under OS/2, It uses huge amounts of lower shared memory, and I need to watch what I try to run at the same time.

Today, I also discovered that doing an update, with ANPM (RPM/YUM), can cause DLLs to lose their settings to load high. This can happen with DLLs that are used by Apache OpenOffice, and with Firefox (probably more). It is probably a good idea to use the HIGHMEM utility to redo those settings after each update. I use the AOO quick load, to keep those in memory, and set them to load both data and code, high. Firefox is probably better with only code loaded high, and use MOZTURBO to keep them loaded. Keeping the DLLs loaded helps to prevent shared memory fragmentation (as well as crashes, when they try to unload), which can cause problems, even when the system says it has lots of shared memory available.

Neil Waldhauer:
If no POPUPLOG.OS2 entry is created, then are any .TRP files created? If so, these could contain a clue to what is going wrong.

Dariusz Piatkowski:
Doug, everyone...


--- Quote from: Doug Bissett on October 10, 2019, 03:29:54 am ---Take out both REMs, and you probably won't have any more problems, for a while. REM DLLBASING=OFF causes shared memory to allocate on memory boundaries, which causes a lot of fragmentation. You may have 150 M left, but if the biggest chunk is 20 K, you have a major problem.

Older systems would be slowed by using DLLBASING=OFF, but any system after the 486SX won't have any problems with it...

--- End quote ---

Yup, that did it.

So both REMs got removed, which means I am now running with the following config:


--- Code: ---...
VIRTUALADDRESSLIMIT=2560
EARLYMEMINIT=TRUE
DLLBASING=OFF
...

--- End code ---

PMMail comes up fine, re-started multiple times, no issues found. So far the other major apps are chugging away as well.

Great pointer Doug, appreciate the insight.

Now off I go stripping out some hardware (like the SCSI AdvanSys card that's my scanner connector) to see if that will have any impact on me trying to actually run in the full 6-core CPU configuration.

xynixme:

--- Quote from: Doug Bissett on October 10, 2019, 03:29:54 am ---Today, I also discovered that doing an update, with ANPM (RPM/YUM), can cause DLLs to lose their settings to load high. ... It is probably a good idea to use the HIGHMEM utility to redo those settings after each update.
--- End quote ---

Yes, and of course the distribution method nor utility matters. With the ZIP files and without a @unixroot you'd probably be more aware of the issue of lost customized settings, because then there's nothing which hides the "complicated installation stuff" for you. I did see some firefox-highmem-45_9_0-1_oc00 file, but I couldn't care less which marked DLLs this distribution includes. Only the FF ones, like XUL.DLL, or all.

The under-(re)construction-installer for MozTurbo won't check DLLs to notice a changed setting, but it can be used to mark all qualifying DLLs again. Per relevant product (FF/SM/TB). Or use e.g. an own CMD file with ABOVE512.EXE or HIGHMEM.EXE indeed, to cover all relevant products with one CMD file.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version