• 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

Problems with Firefox 4.0.1 under OS/2 Warp 4

Started by ppgrainbow, 2011.05.11, 04:40:05

Previous topic - Next topic

ppgrainbow

Has anyone run into this problem lately?

For me, it's been nearly two weeks since I reinstalled OS/2 Warp 4 under Virtual PC 2004 and most recently, I'm starting to have some problems lately.

When I right click on the search engine box whatever it's in Google or Yahoo!, a bunch of dialog boxes corrupt the display, Firefox 4.0.1 crashes and I end up receiving this error message:

SYS3171: A program in this session encountered a problem and cannot continue.

When I click on Display register information, I get the following according to this screenshot: http://imageshack.us/m/12/658/pmmergeerror.png

The error message in this screenshot mentions PMMERGE.DLL and that due to insufficient stack space, the exception was not dispatched. The PMMERGE.DLL file that I'm using is from FixPak 15 (datestamp 19 October 2000, 9:04 PM).

The right click problem does not effect SeaMonkey 2.0.14 (Gecko 1.9.1) and the legacy Mozilla web browser. This only occurs in the latest version of Firefox built under Gecko 2.0.

Is there a way to fix the PMMERGE.DLL problem to make it work properly with Firefox 4?

miturbide

Hi

are you using Warp 4.52? any fixpack?
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

ppgrainbow

#2
Quote from: miturbide on 2011.05.11, 05:22:02
Hi

are you using Warp 4.52? any fixpack?

The latest version of OS/2 Warp that I'm using is Fixpack 15 (Warp v4.5) with the internal revision 14.104_W4 (11 August 2005) and remarkably, Firefox 4 still works.

EDIT: I'm currently in the command prompt and I'm gonna try to replace the version of PMMERGE.DLL with a updated version from July 2001 (46701_FIX.ZIP). If not, then I will try a version of PMMERGE.DLL from 2004. :)

EDIT 2: Neither the updated versions of PMMERGE.DLL worked. The July 2001 version of PMMERGE.DLL had no effect and the 2004 version caused OS/2 to not boot at all. It looks like that I'm gonna be stuck with the version of PMMERGE.DLL until there is a way to fix the right click crashing issue. :(

RobertM

Except as a fix for a specific version, or when you are sure there are no prerequisites, PMMERGE should not be replaced on it's own. For some of the PMMERGE releases, there are other files that are inter-related that need to be replaced as well.

Now, on to the problem at hand. PMMERGE will flake out for a variety of reasons, as it is used by numerous OS/2 subsystems. If something is wrong with a printer driver/subsystem, this will cause your issue when presentation spaces are being created. The same applies to certain video drivers, certain WPS enhancements that are interfering, and too numerous other things to fix.

You can:
- Try removing any/all printer objects
- Ensure no Firefox enhancements are running (such as the REXX stuff)
- Ensure you have no additional DIFFERENT copies of PMMERGE running (not a good thing if the WPS is using one version, while everything else is force-loading another)
- Reinstall FP15 and ensure that PMMERGE (and other related files) are properly processed by the FP installer and locked file handler
- Ensure you are not "mix-and-matching" eCS and Merlin/Aurora/Warp files (re: note above about certain versions of PMMERGE having other upgrade/update pre-requisites).
- Switch to standard GENGRADD SVGA

Kinda vague and non-direct steps, huh?

Sans a need in FF4.0.1 for a specific version of PMMERGE, you'd need to step-through debug the processes to figure out why PMMERGE is crashing.

Here's an interesting read:
http://home.clara.net/orac/os2/pmmerge.htm

From there, you can see just how involved PMMERGE is with... well... almost everything. :(


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


ppgrainbow

Quote from: RobertM on 2011.05.11, 23:33:45
Except as a fix for a specific version, or when you are sure there are no prerequisites, PMMERGE should not be replaced on it's own. For some of the PMMERGE releases, there are other files that are inter-related that need to be replaced as well.

Now, on to the problem at hand. PMMERGE will flake out for a variety of reasons, as it is used by numerous OS/2 subsystems. If something is wrong with a printer driver/subsystem, this will cause your issue when presentation spaces are being created. The same applies to certain video drivers, certain WPS enhancements that are interfering, and too numerous other things to fix.

You can:
- Try removing any/all printer objects
- Ensure no Firefox enhancements are running (such as the REXX stuff)
- Ensure you have no additional DIFFERENT copies of PMMERGE running (not a good thing if the WPS is using one version, while everything else is force-loading another)
- Reinstall FP15 and ensure that PMMERGE (and other related files) are properly processed by the FP installer and locked file handler
- Ensure you are not "mix-and-matching" eCS and Merlin/Aurora/Warp files (re: note above about certain versions of PMMERGE having other upgrade/update pre-requisites).
- Switch to standard GENGRADD SVGA

Kinda vague and non-direct steps, huh?

Sans a need in FF4.0.1 for a specific version of PMMERGE, you'd need to step-through debug the processes to figure out why PMMERGE is crashing.

Here's an interesting read:
http://home.clara.net/orac/os2/pmmerge.htm

From there, you can see just how involved PMMERGE is with... well... almost everything. :(


Okay. I tried switching to GENGRADD and it wasn't much of a help.

I pulled up this utility called SysInfo/2 and I found that it's still using the S3 Trio32 driver with just 4 MB of video memory. I got OS/2 Warp 4 configured to used 16 MB of video RAM.

The kernel level that I got recently installed is 14.104a, the highest that it will go for OS/2 Warp 4. Internel revision 14.104a is from the most recent WSeB CP2/Warp 4 CP2 postfix. I was wondering if 14.104a is causing problems with the most recent version of Firefox.

If that's the case, I might have to follow your advice and reinstall FixPack 15 to see if the crash goes away and if all of the above isn't helping, I will most likely have to conclude that Firefox 4 (and future versions of Firefox) is NOT 100% compatible with OS/2 Warp 4 running under Virtual PC 2004.

If all else fails, then other alternates would be to revert back to Firefox 3.6. However, if I wanted to use Innotek Java 1.4.2, I would have to revert futher back to Firefox 3.5 (which recently reached end of life after Firefox 4.0.1 was released).

But anyways, Firefox 3.6 worked. At least that I'm experiencing no crashes in relations to right clicking the mouse. :)

RobertM

I'll try it on one of my WSeB  machines tonight.

Questions:
(1) Are you sure the Trio32 supports 16MB? If not, that may be part of the problem.
(2) Is the machine SMP?
(2a) If not SMP, did you ensure you installed the w4 kernel (not the UNI or SMP)?
(2b) If SMP, if the machine was Warp 4 (not WSeB), have you ensured you have updated all of the files that go along with the SMP "add-on"?


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


ppgrainbow

Quote from: RobertM on 2011.05.12, 04:02:53
I'll try it on one of my WSeB  machines tonight.

Questions:
(1) Are you sure the Trio32 supports 16MB? If not, that may be part of the problem.
(2) Is the machine SMP?
(2a) If not SMP, did you ensure you installed the w4 kernel (not the UNI or SMP)?
(2b) If SMP, if the machine was Warp 4 (not WSeB), have you ensured you have updated all of the files that go along with the SMP "add-on"?

I'm not using WSeB and the machine is not SMP. The W4 kernel, 14.104a that I installed is correct. Unless there are workarounds, it turns out that Firefox 3.6, Seamonkey 2.0.x and any Mozilla product built on Gecko 1.9.2 will most likely be the last release that will work on OS/2 Warp under Virtual PC. However, I may eventually be wrong.

If you have found any issues running Firefox 4 on WSeB, let me know and it'll be taken from there.

RobertM

Well then, I wonder if FF4.0.1 is doing something that's making PMMERGE hit something in Ring 2... not sure how decent the implementation is in VPC, but I do know there were problems with its implementation in various other virtualization tools (from flawed support to virtually non-existent support).


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


ppgrainbow

Quote from: RobertM on 2011.05.12, 05:38:57
Well then, I wonder if FF4.0.1 is doing something that's making PMMERGE hit something in Ring 2... not sure how decent the implementation is in VPC, but I do know there were problems with its implementation in various other virtualization tools (from flawed support to virtually non-existent support).

It seems that Firefox 4 doesn't work too well when it runs on OS/2 under Virtual PC. Simply right-clicking the mouse causes it to crash under VPC 2004 (and even VPC 2007). To make matters even worse, older versions of Firefox might not even run too when running OS/2 under QEMU either since it's much slower than VPC. It seems that the emulated S3 Trio video card with 16 MB of memory may not be capable of running the latest version of Firefox afterall. :(

Not every software works when running OS/2 under Virtual PC or QEMU, ya know.

I don't know if I'll have the time to test Firefox 4 on other operating systems under VPC 2004.

miturbide

I have also some stability problems with Firefox 4.0 and 4.0.1 running on eCS 2.0 as a guest on Virtualbox 4.0.4. I had already opened a ticket to Mensys. It is trap 000e in OS2KRNL in this case.
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

ppgrainbow

Quote from: miturbide on 2011.05.12, 19:26:29
I have also some stability problems with Firefox 4.0 and 4.0.1 running on eCS 2.0 as a guest on Virtualbox 4.0.4. I had already opened a ticket to Mensys. It is trap 000e in OS2KRNL in this case.

Oh dear, while the problems with Firefox 4 are as bad on OS/2 Warp 4, the situation appears to be much worse on eComStation. I'm gonna try to search for articles on how to get FF4 to work on Warp 4 (under VPC); otherwise, I will eventually be stuck on Firefox 3.6, which will be supported by Mozilla for a very short period of time.

RobertM

Hi,

Apologies for not being clear. If various versions of Firefox are making extensive calls to code that OS/2 runs in CPU Ring 2, that may be the problem. I was extremely busy last night so did not have time to test FF4 on WSeB. I will try tonight. I've got one UNI and a couple SMP setups (all running on "bare metal"), and will see what happens.

Ring 2 support isn't the best in some virtualization software. OS/2 is one of the rare operating systems that actually uses the CPU's various protection levels for code, kernel and driver protection. Last I read, the NT line (ie: Windows 7 downward) still make (at best) minimal real use of actual hardware based code protection. As it is, I cannot remember any other OS that uses Ring 2... but it's been a problematic experience.

Anyway, one of the systems I have is running a real-deal S3 (albeit with less memory) and OS/2 is using it via GRADD... so, I will test that implementation as well. I do know that earlier versions (the v3 line and I think even a couple early Minefield versions) ran fine on the S3 in that system, even under SMP.

Best,
Robert


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


RobertM

Hmmm... for some odd reason, my post from this morning is showing now... oh well.

ok... some things to do and try and some notes:

(1)
The aforementioned Ring 2 issue is not fixable except by those who write the virtualization software. A trap 000e can indeed be related to a privilege issue - namely something that is supposed to be running in Ring 2 flaking out because of poor virtual Ring 2 CPU support.

(2)
It is possible that the virtual machine's virtual hardware caching mechanism (ie: all but the CPU cache) is causing issues. Try disabling the same "real box" cache options that you would disable on a Warp 3 or Warp 4 system for the installation stage. Not sure if this is possible as I have not played with the newer versions of VPC/VirtualBox.

(3)
Check the settings for danis506 and disable all the "advanced" features such as busmastering and such. Under decent load, with a poor implementation, these too can cause a trap 000e. Anyone who remembers early releases of Dani's drivers when certain chipsets had flaky support for various HDD features probably remembers this happening.

(4)
Double-check your memory-conflicting settings in config.sys. The most relevant ones are VIRTUALADDRESSLIMIT, MAXTHREADS and cache settings for JFS (and/or HPFS386) - and possibly those of the swap file.

(5)
IF the virtual BIOS has such settings, disable any advanced features for the S3 card... such as shadow buffering, etc.

Not sure how helpful that is, as I've got no experience on the newer virtualization software, but those are all issues that, under various real hardware scenarios, have caused trap 000e's on Warp, WSeB and eCS.


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


ppgrainbow

Quote from: RobertM on 2011.05.13, 04:11:31
Hmmm... for some odd reason, my post from this morning is showing now... oh well.

ok... some things to do and try and some notes:

(1)
The aforementioned Ring 2 issue is not fixable except by those who write the virtualization software. A trap 000e can indeed be related to a privilege issue - namely something that is supposed to be running in Ring 2 flaking out because of poor virtual Ring 2 CPU support.

(2)
It is possible that the virtual machine's virtual hardware caching mechanism (ie: all but the CPU cache) is causing issues. Try disabling the same "real box" cache options that you would disable on a Warp 3 or Warp 4 system for the installation stage. Not sure if this is possible as I have not played with the newer versions of VPC/VirtualBox.

(3)
Check the settings for danis506 and disable all the "advanced" features such as busmastering and such. Under decent load, with a poor implementation, these too can cause a trap 000e. Anyone who remembers early releases of Dani's drivers when certain chipsets had flaky support for various HDD features probably remembers this happening.

(4)
Double-check your memory-conflicting settings in config.sys. The most relevant ones are VIRTUALADDRESSLIMIT, MAXTHREADS and cache settings for JFS (and/or HPFS386) - and possibly those of the swap file.

(5)
IF the virtual BIOS has such settings, disable any advanced features for the S3 card... such as shadow buffering, etc.

Not sure how helpful that is, as I've got no experience on the newer virtualization software, but those are all issues that, under various real hardware scenarios, have caused trap 000e's on Warp, WSeB and eCS.

For some reason, after you posted your comment, I can't seem to access my own thread. Anyways, let me go through this over..

1. I pretty much admit that Virtual PC doesn't handle Ring 2 too greatly well and TRAP 000E errors are clearly attributed to poor virutal Ring 2 CPU support.

2. As for "real box" caching options, I never heard of it. I don't think that it's possible with Virtual PC 2004 or Virtual PC 2007.

3. I'm not using the DANIS506.ADD driver, I'm using the IBM1S506.ADD. With all of the advanced features turned off, I don't know if replacing it with the DANIS506.ADD will fix the problem or not. As for this parameter in Line 2 of the CONFIG.SYS file:

IFS=C:\OS2\HPFS.IFS /CACHE:2048 /CRECL:4 /AUTOCHECK:CD

The HPFS.IFS driver is only allocating 2 MB of cache, should I (1) modify these values or (2) disable caching alltogether?

4. As for the SWAPPATH and VIRTUALADDRESSLIMIT parameters, I had set a 1 GB (1048576) swapfile and set the virtual address limit to 2 GB (2048)? Should I fix this or leave it alone? The swapfile is placed on the second hard drive under the SWAPPER directory.

MEMMAN=SWAP,PROTECT
SWAPPATH=D:\SWAPPER 1048576 1048576
VIRTUALADDRESSLIMIT=2048

5. The virtual BIOS has no advanced settings for the S3 Trio card at all.

If you found a fix to this problem or if there isn't one, please let me know. I can hardly access the OS/2 World.com website as it has been having problems off and on.

RobertM

#14
(1) That will hopefully be a problem that improves for VirtualBox... I have my suspicions... as to why.

(2) In the virtual BIOS, (dsiable) video card cache, system cache (NOT the CPU cache), shadow cache/buffers, ROM/BIOS cache(s). Assuming such settings exist. I have not used the new versions of VPC, so I have no clue which (if any) are still there.

(3a) IBM1S506/Dani... possibly... especially if the partition size is something too large for IBM1S506

(3b) HPFS cache... irrelevant. My suggestion only applies to the HPFS386 cache, which is an entirely different beast (and to the JFS cache).

(4a) How much memory is allocated to the VM? You shouldn't need a swap file of a gig. Try 64MB to 256MB. OS/2 is very efficient at enlarging or shrinking from the preset value (if needed). On my server (with 4GB memory), my swap file is 2MB. Depending on how much "real" memory the OS/2 session sees, a very large initial swap file size may be problematic. Not 100% sure on this one, as it's from memories of far older versions of OS/2, and the kernel has changed considerably since then.

(4b) I use a virtual address limit of 1536 or 1792. With a big enough JFS cache, or a big thread pool, hitting 2048 for that setting will cause problems.


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