• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

OpenOffice 2.4 problems

Started by cytan, 2009.01.12, 19:00:08

Previous topic - Next topic

cytan

Hi,
   I'm having trouble starting up OpenOffice 2.4 the second time (first time is ok) and I get the error:

*********************************
Execution Failed! Contact technical Support.

Return code:8
Failing module: F:\OpenOffice.org.2.0\Program\VCL680GO.DLL
*********************************

I have checked that I have sufficient shared memory using above512:

current free virtual address space in kB (private / shared):
  239808 / 111936 below 512MB line, 1376256 / 922860 above 512MB line

Looks like I have 111936kB of free shared memory space.

The checksum of VCL680GO.DLL is:

F:/OpenOffice.org.2.0/program@rachel%cksum vcl680go.dll
1666959025 3890149 vcl680go.dll


Note: I recently upgraded my D: drive to JFS from HPFS (NOT the F: drive which has always been JFS). The JFS statement in config.sys is now:

IFS=E:\OS2\JFS.IFS /LW:5,20,4 /AUTOCHECK:* /CACHE:512000

The old statement was:

IFS=E:\OS2\JFS.IFS /LW:5,20,4 /AUTOCHECK:* /CACHE:32768

I never had this problem when my D: drive was HPFS.

Thanks for any pointers!

cytan

RobertM

I'd start with dropping the JFS cache down to something minimal, such as 8192, then try again with no instances of Firefox loaded. Adjust VIRTUALADDRESSLIMIT statement perhaps as well.

I have problems with shared memory with various combinations of the following:
-Threads
-VirtualAddressLimit
-JFS/HPFS386 caches

It's quite a balancing act.

Are the free shared memory stats with OO not loaded, or during the loading process as it is failing?

Rob


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


cytan

The memory stats are after the first load of OO. With HPFS I've had OO open with 80MB of free shared memory. I'll try lowering the JFS cache size.

One interesting note: Boot fails and traps just before WPS comes up when the cache is set to 256000. Boots fine with 512000. Weird.

cytan

Quote from: RobertM on 2009.01.12, 20:39:26
I'd start with dropping the JFS cache down to something minimal, such as 8192, then try again with no instances of Firefox loaded. Adjust VIRTUALADDRESSLIMIT statement perhaps as well.

I have problems with shared memory with various combinations of the following:
-Threads
-VirtualAddressLimit
-JFS/HPFS386 caches

It's quite a balancing act.

Are the free shared memory stats with OO not loaded, or during the loading process as it is failing?

Rob

Pete

Hi Guys

Could the problems be "resource related"? ie lack of low memory.

You could try adding the below line to the config.sys file and see if it helps
EARLYMEMINIT=TRUE


I have not experimented with Cache size for jfs - that switch is not on the IFS=JFS line so cache defaults to 12.5% of physical memory.  Seems to work satisfactory for most apps...

Regards

Pete


StefanZ

For the JFS cache problems I already opened a support ticket on eComstation bugtracker (0002093: Strange behavior when huge cache assigned to JFS). It was stated that there are problems with allocation of "huge" file cache for JFS even when stated that cache size for JFS is actually limited only by amount or RAM available) and that this are some issues concerning eCS kernel. It was strongly advised that for stability reasons not to allocate more than 256MB of RAM.

When I was experimenting with this, I ran into problems when trying to allocate 512MB (and more). The problems varied from "application cannot start" on WPS to "out of resources" and hangs during boot.

The bottom line: If you try to allocate more than lets say 256MB of RAM, eCS will run into trouble sooner or later because of internal issues. So there should not be anything wrong with your PC or configuration. And - the effects can be probably different on different machines.

Hope this helps :)

cytan

Thanks for the info! I've lowered the amount of cache to 65536k to see if my problems persist. I think the main problem is that OO is a shared memory hog. I'm wondering whether the developers can keep this under control or reduce it? Comments from the developers will be most helpful.

cytan


Quote from: StefanZ on 2009.01.14, 15:35:54
For the JFS cache problems I already opened a support ticket on eComstation bugtracker (0002093: Strange behavior when huge cache assigned to JFS). It was stated that there are problems with allocation of "huge" file cache for JFS even when stated that cache size for JFS is actually limited only by amount or RAM available) and that this are some issues concerning eCS kernel. It was strongly advised that for stability reasons not to allocate more than 256MB of RAM.

When I was experimenting with this, I ran into problems when trying to allocate 512MB (and more). The problems varied from "application cannot start" on WPS to "out of resources" and hangs during boot.

The bottom line: If you try to allocate more than lets say 256MB of RAM, eCS will run into trouble sooner or later because of internal issues. So there should not be anything wrong with your PC or configuration. And - the effects can be probably different on different machines.

Hope this helps :)

DougB

You might be able to reduce the usage of shared memory space, by adding the line:
DLLBASING=OFF
near the top of your CONFIG.SYS. There is a minor performance hit, but you will never notice it, unless you are running on a 486 processor, but that will allow OS/2 to make more efficient use of shared memory space.

cytan

Quote from: DougB on 2009.01.15, 03:54:13
You might be able to reduce the usage of shared memory space, by adding the line:
DLLBASING=OFF
near the top of your CONFIG.SYS. There is a minor performance hit, but you will never notice it, unless you are running on a 486 processor, but that will allow OS/2 to make more efficient use of shared memory space.

Thanks, I already have that in my config.sys. I really hope that the developers are aware of the shared memory hog problem in OO.

cytan