OS2 World Community Forum
WebSite Information => Comments, Suggestions & Questions => Topic started by: Pete on December 04, 2023, 02:37:01 pm
-
Hi All
Over the past couple of days I have noticed os2world.com causes lots of peak cpu activity, far more than usual, to show in Warpcenter cpu monitor - even if all that is open is the homepage.
Is this some sort of runaway script? I ask because cpu activity does not stop when I close os2world and open a different website that I know - and have double checked - does not cause lots of peak cpu activity and only closing the browser (Seamonkey) gets rid of the cpu's peaking - very pretty it is in 12 colours.
I have also run Seamonkey visiting several websites that do not cause cpu peaking, then visited os2world which causes cpu's to start peaking, then closed os2world and revisited previous websites which all now show cpu's peaking.
Anyone else seeing this?
Regards
Pete
-
Hmmm... Should have checked what Dooble (qt5) does - no cpu's peaking at all.
Seems to point at a Seamonkey problem but it is a problem that has only just surfaced.
Guess it could be a script from a url blocked in Dooble but allowed by NoScript in Seamonkey...
Any thoughts?
Regards
Pete
-
I was noticing similar yesterday (currently on Linux). Wonder if it is another GIF causing the CPU problem.
-
Pete, try right clicking on the page, choose "View Page Info", it takes a while of 100% cpu to open the page info thingy, choose the media tab, and click the "Block images from www.os2world.com" tickbox and see if that fixes the high CPU load.
Then untick it and see if CPU load stays low. Weirdly enough it does stay low here.
There's 7 GIF's, have to test them individually.
-
Hi Dave
No, "Block images from www.os2world.com" makes no difference.
I have attached 2 images showing this cpu activity:
desktop1a.jpg shows small activity starting seamonkey then opening theartofsound website
desktop2a.jpg is around a minute later after loading os2world
This continuous cpu peaking only seems to happen with os2world.com, and continues after leaving the website, hence my suspicion of some sort of runaway script...
Regards
Pete
-
Here, the CPU metre calms down to one CPU using about 1-2% after some seconds, about 5% typing this. Try doing a CTRL-F5 to force a reload of the page, perhaps both logged in and logged out. If that doesn't work, it may be a profile problem.
I've had similar now and again, never tracked it down to a particular page, might have been OS2World, the only fix that I found was reverting to an older profile from before the CPU usage thing hit. One of the reasons I use session manager add-on.
I have discovered with the Mozilla apps, it is important not to shut them down while they're busy.
-
Hello
Now that I'm back, I want to check this, but I'm now sure what it should be failing.
I remember that Dave told me about a .gif file that was causing problems in SeaMonkey and Firefox (OS/2 Only), but now we will have to which is the new issue.
Regards
-
Hi Martin, hope you had a good trip. I don't think it is a GIF issue that Pete is experiencing. For me things are low CPU. Unluckily SeaMonkey and Firefox seem to get stuck using a lot of CPU occasionally.
-
Hi All
It seems that whatever has been causing cpu peaking on os2world has now gone away - see attached Normal01.jpg
Changes this end:
1] I logged out of both website and forum on my last visit
2] Moved Gotcha! Quiet out of Startup folder - probably totally irrelevant
I have obviously logged in to the Forum to post this, logged in at os2world.com and started Gotcha Quiet! none of which have started cpu's peaking.
Maybe Martin found something to tweak? - In which case, Thanks Martin.
Regards
Pete
-
O.T....
Pete, where does that CPU meter in your screenshots come from? Is it a 3rd-party replacement or is it just so old I don't recognize it? (I rewrote "Pulse" 4 years ago in XWP 1.0.13.)
-
Hi All
Posted last message too soon as the cpu peaking is back ...
I've tried with 2 newly created, standard - no extensions added, profiles to see if this is profile related and I get similar behaviour.
The cpu peaking with the 2 new profiles seems to be centred on https://www.os2world.com/cms/ as selecting to open a forum post in a new tab then switching to that tab "calms" cpus down - until switching back to https://www.os2world.com/cms/
I've tried to show this with the attached files
home.png - 1st peak shows Seamonkey having just loaded os2world followed by a small (2 second?)gap then continuous peaking
forum.png - switched to a forum topic, cpus not peaking
home_af.png - after closing forum tab, back to cpus peaking
Opening a forum post in a new tab and switching to that tab does not "calm" cpu's in my usual profile, they carry on peaking. So my usual profile may have a problem...
The cpu's peaking with the new profiles after loading os2world homepage should not be a profile problem though.
Could it be a Seamonkey/support dll problem?
@Rich
Yep, it is an oldie
It is Ye Olde Warpcenter cpu meter - I prefer Warpcenter to Xcenter.
Regards
Pete
-
Hi Pete, try going to about:config and changing layout.frame_rate. Try 1, -1 and large numbers. IIRC, have to restart between changes.
Did you say you are using no-script? Do you have os2world scripting disabled?
-
Hi Dave
Changed layout.frame_rate to 1 and restarted Seamonkey.
Seems to have cured the cpu peaking problem but introduced noticable sluggishness into Seamonkeys response time.
Changed layout.frame_rate to -1, restarted Seamonkey.
No cpu's peaking and Seamonkey seems as responsive as I am used to.
Yes, NoScript in use with options to Allow os2world if needed.
Thanks
Pete
-
OK, I usually have scripting on OS2World turned off. It does seem like the gif bug. See https://bugzilla.mozilla.org/show_bug.cgi?id=1744499 (https://bugzilla.mozilla.org/show_bug.cgi?id=1744499) and, with better examples, https://bugzilla.mozilla.org/show_bug.cgi?id=1793279 (https://bugzilla.mozilla.org/show_bug.cgi?id=1793279).
Thing is we don't have the a refresh driver (idea is only draw during refresh cycles) and fake it, which is what that preference is about and why it is much worse on our platform.
The usual workaround for sites that we can control is to change the gifs to pngs. I did that for a bunch of sm/ff theme gifs. Not all gifs cause the problem and it may well be one frame animated gifs or our bug is different. One way to test is to load each gif one by one to see which produces the high CPU load.
The refresh driver was introduced with 45esr.
https://github.com/bitwiseworks/mozilla-os2/issues/208 (https://github.com/bitwiseworks/mozilla-os2/issues/208) delayed/choppy response
https://github.com/bitwiseworks/mozilla-os2/issues/277 (https://github.com/bitwiseworks/mozilla-os2/issues/277) the gif bug
-
I had written a device driver to sync on the VGA sync signal:
https://github.com/lerdmann/vsync
And here, it has already been discussed:
https://github.com/bitwiseworks/mozilla-os2/issues/220
It reads the VSYNC sync bit from some VGA register and blocks on it to toggle (waits for the beam to return from bottom right to top left, so to say). It is somewhat system friendly in that it will yield the CPU if the yielding flag indicates that there is some other thread waiting to be continued.
1) I have no clue if every graphics card still contains the original VGA register set
2) I have no clue how and where to integrate this into Firefox
If someone could either point me to the place in Firefox where to add this or if someone could build Firefox (of which I also have no clue) then maybe it would be worth giving it a try.
Lars
-
Hi Dave
I reset layout.frame_rate to 0 and had a look at the links in your post.
No reaction from Seamonkey here ie no cpu peaking, no animated gifs either...
Regards
Pete
-
Hi Pete, my system was busy at the time so just assumed it was the same bug. I was looking for the one that fixed our problem, which IIRC, I only saw referenced as being fixed. The problem was partially Gimp producing broken GIF's that triggered the animation even though not animated, or might have been one frame.
-
Hi Lars, I'll see if Mozilla still builds here. Have to restore from a backup and my first try was the wrong one.
Stupid Intel USB3 is slow, 3 hours to restore the tree, currently going at 2.4 MB/S, maxes out around 6. The addon USB3 card I had max out at about a 100 MB/S. Speed is just about as slow under Linux too.
-
I had written a device driver to sync on the VGA sync signal:
https://github.com/lerdmann/vsync
And here, it has already been discussed:
https://github.com/bitwiseworks/mozilla-os2/issues/220
It reads the VSYNC sync bit from some VGA register and blocks on it to toggle (waits for the beam to return from bottom right to top left, so to say). It is somewhat system friendly in that it will yield the CPU if the yielding flag indicates that there is some other thread waiting to be continued.
1) I have no clue if every graphics card still contains the original VGA register set
2) I have no clue how and where to integrate this into Firefox
If someone could either point me to the place in Firefox where to add this or if someone could build Firefox (of which I also have no clue) then maybe it would be worth giving it a try.
Lars
Hi Lars, finally got Firefox building again, moved computers and had to restore environment and fix the tree.
Pushed the latest to https://github.com/dryeo/mozilla-aos (https://github.com/dryeo/mozilla-aos) branch esr45.9.
The vsync stuff is scattered around thebes, such as https://github.com/dryeo/mozilla-aos/blob/esr45.9/gfx/thebes/VsyncSource.cpp (https://github.com/dryeo/mozilla-aos/blob/esr45.9/gfx/thebes/VsyncSource.cpp). The Windows implementation might be a good start, https://github.com/dryeo/mozilla-aos/blob/esr45.9/gfx/thebes/gfxWindowsPlatform.cpp#L2733 (https://github.com/dryeo/mozilla-aos/blob/esr45.9/gfx/thebes/gfxWindowsPlatform.cpp#L2733)
Whether using the VGA registers will work is a good question. I doubt it on a UEFI install, I haven't had any luck accessing the registers there, and it is loaded at a weird address. Might be possible to get info from Arca Noae how to access it in their VGA BIOS.
Might work on a legacy install. The screensaver has a fall back of directly manipulating the VGA registers to put the monitor to sleep (set VSYNC/HSYNC to zero), which doesn't seem to work on recent hardware.
-
Hi Dave
Retested with the new profiles - standard Seamonkey, no addons.
Both those show the gif bug ie https://bug1793279.bmoattachments.org/attachment.cgi?id=9296847 causes cpu peaking.
Regards
Pete
-
I had written a device driver to sync on the VGA sync signal:
https://github.com/lerdmann/vsync
And here, it has already been discussed:
https://github.com/bitwiseworks/mozilla-os2/issues/220
It reads the VSYNC sync bit from some VGA register and blocks on it to toggle (waits for the beam to return from bottom right to top left, so to say). It is somewhat system friendly in that it will yield the CPU if the yielding flag indicates that there is some other thread waiting to be continued.
1) I have no clue if every graphics card still contains the original VGA register set
2) I have no clue how and where to integrate this into Firefox
If someone could either point me to the place in Firefox where to add this or if someone could build Firefox (of which I also have no clue) then maybe it would be worth giving it a try.
Lars
Hi Lars, finally got Firefox building again, moved computers and had to restore environment and fix the tree.
Pushed the latest to https://github.com/dryeo/mozilla-aos (https://github.com/dryeo/mozilla-aos) branch esr45.9.
The vsync stuff is scattered around thebes, such as https://github.com/dryeo/mozilla-aos/blob/esr45.9/gfx/thebes/VsyncSource.cpp (https://github.com/dryeo/mozilla-aos/blob/esr45.9/gfx/thebes/VsyncSource.cpp). The Windows implementation might be a good start, https://github.com/dryeo/mozilla-aos/blob/esr45.9/gfx/thebes/gfxWindowsPlatform.cpp#L2733 (https://github.com/dryeo/mozilla-aos/blob/esr45.9/gfx/thebes/gfxWindowsPlatform.cpp#L2733)
Whether using the VGA registers will work is a good question. I doubt it on a UEFI install, I haven't had any luck accessing the registers there, and it is loaded at a weird address. Might be possible to get info from Arca Noae how to access it in their VGA BIOS.
Might work on a legacy install. The screensaver has a fall back of directly manipulating the VGA registers to put the monitor to sleep (set VSYNC/HSYNC to zero), which doesn't seem to work on recent hardware.
The driver does not use the VGA BIOS in any way. It directly accesses the legacy VGA registers.
In PCI config space, it looks for a VGA compatible device when it loads and if it cannot find one, it outputs an error message and aborts. Maybe that is the way to test ...
-
it looks for a VGA compatible device when it loads and if it cannot find one, it outputs an error message and aborts. Maybe that is the way to test ...
Lars, the best way to test is to post the binary so people can test... ;)
-
Yes, of course. I have built it, I just need to upload to GitHub...
-
I have now created a release on github.com/lerdmann/vsync/releases.
-
I have now created a release on github.com/lerdmann/vsync/releases.
Doesn't seem to be there. Perhaps just post here for testing purposes
-
Here it is.
-
Unluckily, all that happens when running test.exe after installing the device driver is it instantly locks up the system needing a power off to recover (USB Keyboard). Tested on a legacy and a EUFI install.
-
That would mean that there is no HW that would offer the legacy VGA register set.
Can you provide PCI.EXE output for that system?
The driver checks for a VGA device on the PCI bus and should fail to load if it does not find any.
-
Sure.
-
Hm, your PCI exe output lists a "VGA device".
Can you try the attached ? There is an issue: a VGA compatible color device should have its register block be located at 0x3Dy and a mono device at 0x3By but it looks like many devices have their register block located at 0x3By even if they are color devices.
I have now hardcoded the register block at 0x3By in VSYNC.SYS. Can you try if that makes a difference ?
-
Unluckily, same result, as soon as test.exe is launched, hard lockup where only the power button works. No forcing a dump with the USB keyboard to avoid the power off.
-
Ok, then it seems that either modern Video devices no longer have a VGA compatible register set or that I somehow would have to enable the VGA part but I would not know how to do that.