Guest screen update does not always work f.i. when Seamonkey was started before VBOX

[andib]

Host IBM 14.106 kernel, Intel 4 real cores, eCS2.x with most probably all available updates including yum/rpm ones. Latest Panorama.

Guest WinXP

VBOX 5.0.6_OSEr143 runs fine as long as I start it before Seamonkey 2.35. Start SM when VBOX is running does not work. When I start SM before VBOX then screen update (redraw) in VBOX does not work. Moving a Host window over VBOX redraws that part of VBOX window correctly.

AFAIK this is a known problem when starting VBOX from VBOX-Manager.

Even closing SM and starting VBOX afterwards does not help. Only Host reboot. So I guess there is some dll which is loaded by SM (and VBOX Manager) which does trigger this problem.

Reboot Host, start VBOX, close VBOX, start SM, close SM, start VBOX - all works okay.

close VBOX, start SM, start VBOX while SM is running --> guest screen redraw does not work (some parts are redrawn very slow though)

HTH to narrow down the problem.

[Valery V. Sedletski]

2andib: Maybe, this is just #57 ? Window may be not redrawn if there's some delay due to a PM lockup for several seconds, or minutes. Usually this is observed when there's a disk access this time. So, as I suspect, there's a disk activity, which causes some delay in GUI thread, so PM queue locks up and window is not redrawn. Also, I use VBox with Seamonkey too, and I don't see something special when I start Seamonkey before or after VBox. So, I don't think this is some DLL loaded by Seamonkey. BTW, with which Seamonkey version is that observed?

P.S. If selector window is running (You called it VBox Manager), then it communicates to a VM window, to take its screenshots, which are needed for displaying the preview. So, when selector window is waiting for a screenshot, it could block and lock up the PM message queue. So, the probability of a PM lockup is increased. But I doubt that Seamonkey may influence if VM window is not redrawn similar way.

P.P.S.: Maybe, these are VAL problems, so you have too little shared memory to run both VBox and SM? What VIRTUALADDRESSLIMIT do you have?

[andib]

I'm not sure if it is related to #57. Currently I can not reproduce it that easily than I could a few days ago.

SM2.35, Tried with VAL1536 and 2048.

But now I also doubt it is DLL related. System seems to run out of some resources but don't think it is memory cause I checked with Above512. Hm, more questions than answers :-(

[Valery V. Sedletski]

VAL=1536 or 2048 is way too little, as VBox allocates VM memory from a high private arena. I use VAL=3072. But you need to set THREADS and PROCESSES to a reasonable values, like THREADS=128, PROCESSES=511, as default values take too much memory. Also, please check if you set JFS cache to a reasonable value, as default one is 20% of available memory, which, in case you have about 3 GB of RAM, is 600 MB,which is too large. So, you need to limit it too.

Above512? What do you mean?

[Allan]

I do not agree with your here Valerius. I use 1536 for VAL too, and I have no problems running Vbox and SM together - although the tested SM here is 2.7
IMO using VAL larger than 2048 just creates a number of other problems - which is exactly why l8r eCS version turned this value down again.
You say that Vbox allocates from private high arena. It is possible, it allocates some amount from that, but with a tested guest here (XP) set to max 512MB RAM, Vbox allocates 100MB from lower shared mem pool - and 400MB from high shared mem pool. I can not see, how much it might have allocated from the private pools, but SM 2.7 also grabs 200-400MB from high shared arena.
BTW, with VAL=1536 I have 1.4GB private high arena and 1,35GB shared available after boot.
About JFS, you are unfortunately also wrong. It is correct, that JFS will grab 20% of system memory - but it will never grab more than 64MB by itself. Only if you specify it on IFS line in config.sys, you can add more than 64MB. JFS should work with up to 1GB cache - but that requires VAL = 512 or less - not very usefull, these days.

For Andy: I know, that for my tests of SM 2.28 , I grabbed a lot of the DLL-hell it requires, and put it directly into the SM dir. For the test of Vbox5 I did something similar in a Vbox-subdir, and uses beginlibpath with Vbox to load/find them.
I know for sure, these dlls most likely are different versions - so these 2 apps would most likely kill each other - dependent with was loaded first.
Is it possible, you did something like that ?

[andib]

@Yoda & DLL-hell - after some reservations at the beginning I started to follow the yum/rpm route long time ago. I cleaned my system and do have the latest stuff installed by rpm. Usually no conflicting DLLs here. The only DLL problem here which needs LIBPATHSTRICT is FF and SM - both of them use a different xul.dll.

VAL - my main system with 3328MB visible can't even boot with VAL=2048 so I'm using 1536 since many years. VBOX WinXP guest with 500MB RAM runs happily with that beside all the other stuff.

[Valery V. Sedletski]

Yes, VAL=1536 is too little for VBox. And it has no sense to use less than 3072 nowadays. (you just use VAL=3072-x, if you increase JFS cache by x MB. But usually, JFS cache fit well into 1 GB of kernel memory). I have 3500 of RAM available on my machine, but this does matter nothing. I cannot allocate more than 2200 MB for usermode apps, and cannot allocate more than 1700 MB for a single VM. Though, 3500 MB is available. So, if it is available, according to Theseus, this does not mean you can use it. You can just have too little virtual address space, because it can be occupied by a shared memory, but you need private memory, or vice versa. With JFS, I had *BIG* problems when I didn't set it up explicitly. Yes, it uses 20% of available RAM for cache. It grabs all the RAM it needs, not only 64 MB at a time. I had DLL's each time rewritten by JFS cache, so after each reboot I had them corrupted, so I needed to reinstall them each time over. When I set the cache size to a reasonable value, everything went fine. (Yes, DLL's needed by VBox, were rewritten. Don't know why the cache size influences on that, in theory, here cache timings matter, like maxage/diskidle/bufferidle. But yes, here I had DLL's corrupted -- probably when flushing, or not flushing, cache, to the disk).

VBox should not allocate from shared pools, as it only uses shared memory for loading DLL's. For allocating VM memory, it uses malloc(), so it tries to allocate from high priivate arena, when possible.

[Valery V. Sedletski]

You say that Vbox allocates from private high arena. It is possible, it allocates some amount from that, but with a tested guest here (XP) set to max 512MB RAM, Vbox allocates 100MB from lower shared mem pool - and 400MB from high shared mem pool. I can not see, how much it might have allocated from the private pools, but SM 2.7 also grabs 200-400MB from high shared arena.

Maybe, from private arena here? As it is definitely should not use shared one.

[Valery V. Sedletski]

2andib:

VAL - my main system with 3328MB visible can't even boot with VAL=2048 so I'm using 1536 since many years. VBOX WinXP guest with 500MB RAM runs happily with that beside all the other stuff.

Did you tried to reduce THREADS/PROCESSES and JFS cache and set VAL to 3072 or 2500-2800?

I have two machines, on one, which has 3500 MB available, I have VAL=3072, on another, 3000 MB is available, and VAL is 2500. And everything works fine. If 3300 MB is available, you probably could feel fine with VAL=2700 or 2800.

[andib]

Usually I set JFS /​CACHE:128000. Setting VAL to high and HPFS386 complains about too less memory and I can't boot this system.

THREADS=128, PROCESSES=511

I've THREADS=500. A value of 128 as you suggested seems very very low to me. I've set PROCESSES=200.

TOP goes up to 'Proc:64 Thrd:211'. XWP-Kernel page shows 95 processes and 337 threads running. I don't think I can lower my values much further.

[Allan]

Replying to andib:

@Yoda & DLL-hell - after some reservations at the beginning I started to follow the yum/rpm route long time ago. I cleaned my system and do have the latest stuff installed by rpm. Usually no conflicting DLLs here. The only DLL problem here which needs LIBPATHSTRICT is FF and SM - both of them use a different xul.dll.

LIBPATHSTRICT can cause many side effects, as you know. Vbox also uses code from mozilla tree, that could be a reason ( just a guess ). Maybe try to avoid it as a test, or use it in both places.

Using LIBPATHSTRICT will of course also use much more shared mem - could be another thing to look at.

VAL - my main system with 3328MB visible can't even boot with VAL=2048 so I'm using 1536 since many years. VBOX WinXP guest with 500MB RAM runs happily with that beside all the other stuff.

You mention in another place, that you use HFFS386. Now, it doesn't surprise me anymore, that you can't. HPFS is from another decade - it also requires system mem - which all need to be deduced from VAL. Things like EARLYMEMINIT - which can help on moving some of the ussaga from other booting drivers doesn't work either when using HPFS386.

Do you really _need_ HPFS386 ?

Andy, I really have to say, that using HPFS386 and VBOX is really pushing OS/2 in 2
different directions, and you can't do both. HPFS386 was the fast way 20 years ago.
It may still be so today for you - but it is an impossible approach.
Please consider testing Vbox5 on a system without it (and I mean at least make a clean test partition without it with eCS 2.2b2 or something like that).

[Valery V. Sedletski]

2andib: Sorry, THREADS=511 and PROCESSES=128, of course. And VAL=3072-(JFS_cache)-(HPFS386_cache). And, do you really need hpfs386? I only use HPFS for boot disks. Other disks should be JFS. And, for small boot disks, plain HPFS is sufficient. Also, I never saw the number of processes > that limit.

PS: did you tried EARLYMEMINIT=TRUE? It may help when having insufficient memory sometimes.

[Allan]

Replying to valerius:

Yes, VAL=1536 is too little for VBox. And it has no sense to use less than 3072 nowadays. (you just use VAL=3072-x, if you increase JFS cache by x MB. But usually, JFS cache fit well into 1 GB of kernel memory).

For me, 1536 works fine a a single XP guest using 512MB. If I start 2 guests, Vbox just freezes anyway for now, so no reason for more.

I have 3500 of RAM available on my machine, but this does matter nothing. I cannot allocate more than 2200 MB for usermode apps, and cannot allocate more than 1700 MB for a single VM. Though, 3500 MB is available. So, if it is available, according to Theseus, this does not mean you can use it.

I haven't tried setting VAL so high (I have 8GB here with OS/2 liking the usual 3.3GB), as I have not needed it - and I know how many other things, it can kill. I know for sure, that if you run a lot of apps, you'd better keep it low. Of course, if just trying to run Vbox5, and getting most out of it, you can make that value high, but it will kill most end-user system setting it to 2048 or higher

With JFS, I had *BIG* problems when I didn't set it up explicitly. Yes, it uses 20% of available RAM for cache. It grabs all the RAM it needs, not only 64 MB at a time.

All my JFS's grab only 64MB if IFS line has no /cache statement. What is your buildlevel of JFS.IFS ?

I had DLL's each time rewritten by JFS cache, so after each reboot I had them corrupted, so I needed to reinstall them each time over. When I set the cache size to a reasonable value, everything went fine. (Yes, DLL's needed by VBox, were rewritten. Don't know why the cache size influences on that, in theory, here cache timings matter, like maxage/diskidle/bufferidle. But yes, here I had DLL's corrupted -- probably when flushing, or not flushing, cache, to the disk).

There have been a high amount of bugs in JFS - and all IBM versions are totally dangerous to use (and yes, I have been bid by that a lot too). AFAIR you need at least the one from eCS 2.2b2 or anyone l8r, to have a chance of a somewhat user friendly version - all previously will hurt you, sooner or l8r.

VBox should not allocate from shared pools, as it only uses shared memory for loading DLL's. For allocating VM memory, it uses malloc(), so it tries to allocate from high priivate arena, when possible.

This is not what I see. I'll add some numbers in a while - don't wanna risk doing it right now - if Vbox should crash the system after all this txt ;-)

[Allan]

Replying to Yoda:

VBox should not allocate from shared pools, as it only uses shared memory for loading DLL's. For allocating VM memory, it uses malloc(), so it tries to allocate from high priivate arena, when possible.

This is not what I see. I'll add some numbers in a while - don't wanna risk doing it right now - if Vbox should crash the system after all this txt ;-)

I run the test:
A i from before staarting test
B is after startein Virtualbox.exe
C is after starting guest, and waiting to (XP) fully booted and was idle
D Is after guest and Vbox is shutdown

Will be added as test.sip

[Allan]

mem usage for an XP client

[Valery V. Sedletski]

2Yoda: very strange, because malloc should use private memory. Are you sure you didn't confused one with another?

[Valery V. Sedletski]

I have:
1) before starting VBox:

27. QSV_MAXHPRMEM = 1879048192 (1835008K -> 1792.000M).
28. QSV_MAXHSHMEM = 1828585472 (1785728K -> 1743.875M).
29. QSV_MAXPROCESSES = 128.
30. QSV_VIRTUALADDRESSLIMIT = a0000000

2) after booting winxp:

27. QSV_MAXHPRMEM = 1879048192 (1835008K -> 1792.000M).
28. QSV_MAXHSHMEM = 1697968128 (1658172K -> 1619.309M).
29. QSV_MAXPROCESSES = 128.
30. QSV_VIRTUALADDRESSLIMIT = a0000000

Yes, it looks that shared memory is used. No idea why. Malloc should not use shared memory. So, or Theseus lies, or I don't know.

[Valery V. Sedletski]

RAM Usage by Process:

--------- private --------   ------ owned shared ------
   bytes   Kbytes   Mbytes      bytes   Kbytes   Mbytes   who
--------   ------   ------   --------   ------   ------
01285000    18964   18.520   00856000     8536    8.336   VIRTUALB
00100000     1024    1.000   0028F000     2620    2.559   VBOXXPCO
00726000     7320    7.148   00316000     3160    3.086   VBOXSVC
03051000    49476   48.316   21420000   544896   532.125   VIRTUALB
018EA000    25512   24.914   0003E000      248    0.242   THESEUS4
--------   ------   ------   --------   ------   ------
17736000   384216   375.211   24BCC000   601904   587.797   total RAM in use
82F49000   2145572   2095.285   free RAM
--------   ------   ------
BF24B000   3131692   3058.293   total of all RAM pages found (Pvt + Shr + Free)

So, you can see from here that VirtualBox.exe uses 532 MB of shared memory. And only 48 MB of private memory. Very strange.