OS/2, eCS & ArcaOS - Technical > Internet

PMMail and EARLYMEMINIT=TRUE problem?

<< < (3/4) > >>

Dariusz Piatkowski:
Hi Neil,


--- Quote from: Neil Waldhauer on October 10, 2019, 05:25:39 pm ---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.

--- End quote ---

Nah, nuthin'...that's the funny (although maybe quite reasonable outcome given the possible scenario that Doug outlined). The app simply hung the system, in that soft-hang, which is why CTL-ALT-DEL still worked. But no TRP, no LOG, nothing else.

Well, now that this is behind me though, no sense spending any more time of this. Sometimes I honestly just thank the Almighty that things still keep on working...LOL!

Doug Bissett:

--- Quote ---Well, now that this is behind me though, no sense spending any more time of this. Sometimes I honestly just thank the Almighty that things still keep on working...LOL!
--- End quote ---

It will work, until they create enough DLLs to fill it up again. When that happens (when, not if), we have no other place to go, unless somebody knows about something else that will reduce the amount of lower shared memory that they require. One of the main problems, is that older programs need to be updated to use upper shared memory space, but, in many cases, we don't even have the source, so it isn't possible. Those who are porting new programs, or if they have the source for an older program, need to take steps to reduce the need for lower shared memory space. At least that will buy us some more time.

I will note, that VBox (running under OS/2) is using HUGE amounts of lower shared memory space. On the other side, CLAMD is automatically using HUGE amounts of upper shared memory space. Depending on the VIRTUALADDRESSLIMIT settings, there is a lot more upper shared memory space available, but it is not unlimited. There is now memory available in PAE memory. See the QSINIT documentation for more information. The "problem" is, that there is no easy way to actually use that memory in a program. So far, the only user, that I know about, is the PAE RAMDISK (see QSINIT). It seems to me, that CLAMD could use that memory, rather than filling up upper shared memory (but I don't have to do it).

Lars:
I had a look at the QSINIT SDK code: there is a "mode" to start the HD4DISK.ADD with the /i parameter. In that case, no disk will show up but instead, the memory allocated for the RAM disk will be accessible as ordinary memory via IOCTL calls (you can read from and write to it).
However that will only allow one app to use that memory at a time, it can only read/write in blocks of 512 bytes and of course you will have no RAM disk. I guess that is not a good solution to the problem.

Roderick Klein:

--- Quote from: Doug Bissett on October 11, 2019, 05:45:39 pm ---
--- Quote ---There is now memory available in PAE memory. See the QSINIT documentation for more information. The "problem" is, that there is no easy way to actually use that memory in a program. So far, the only user, that I know about, is the PAE RAMDISK (see QSINIT). It seems to me, that CLAMD could use that memory, rather than filling up upper shared memory (but I don't have to do it).

--- End quote ---

As it is right now OS/2 will *never* be able to use the memory above the 4 GB RAM for a program to allocate RAM.
And updating the kernel is very very time and labour intensive task. It would require massive patching to make this possible. You would need to change the memory routines that allocate memory to make this work.

The API in the QSINIT loader has no memory management. What I mean with this is that if you use that API the loader offers you can overwrite the memory the ram disc is using.

That said I did talk to Dmitry from BWW at Warpstock Europe in Cologone in 2016. And they do have an idea how OS/2 can use the memory the loader offers above the 4 GB boundary, without changing the kernel.
If hope I explain this correctly but OS/2 would kind of get the same idea you as you had with expanded memory.
You would get a memory buffer below the 4 GB of RAM and that would be used to push data to and from above the 4GB.

Note expanded memory on DOS does have somewhat of a negative image as it was not always easy to setup.
This idea would be transparant for the user. Todo would:

Something that would need manage the memory. As in keep track of which memory is used by who. If an application crashes or shutdown that the memory is freed! To get this to work this would require also an application be modified to use this mechanisme.  This idea would especially be usefull for programs requiring large amount of memory and especially usefull for LIBC applications (large ported applications).

Roderick
--- End quote ---

Roderick Klein:

--- Quote from: Dariusz Piatkowski on October 08, 2019, 02:16:51 pm ---So I figured I would try a few different options in order to improve the configuration of my system, but as I did I came up with this surprising (to me anyways) discovery:

Setting EARLYMEMINIT=TRUE in CONFIG.SYS causes my PMMail to crash the whole machine...not a hard crash, but CTRL-ALT-DEL is the only way out.

This is applicable to PMMail 3.22.00.2301 (32534).

Has anyone encountered this before? Any ideas what may be causing the symptom I'm seeing?

--- End quote ---

While I read what your writing I have a hard time believing earlymeminit=true is the cause of this.
Unless you are using HPFS386 then earlymeminit=true is nono.
The usage of earlymeminit=true is simply just about  a requirement for OS/2 to even function.
Certain older *ISA* SCSI card do not work and HPFS386 file system. Other then that no documented defects
have been found.

eCS has been using this setting since just about day 1 and ArcaOS as well. The only thing it does is that it makes no longer limits the amount of memory OS/2 can use for loading device drivers. Without its 16 MB and in that space ACPI.PSD, the kernel IFS drivers etc all need to be loaded! If you go above the 16 MB without the system your system will crash somewhere during startup. Why because the kernel ran out of memory.

I have yet to year somewhat of a theory as to why earlymeminit=true would cause applications to crash.
As in drivers allocate RAM and the kernel knows which memory area's are allocated by drivers. That RAM can not be assigned to applications..

Roderick

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version