#1196 Vice 3.4 on FreeBSD triggers heavy swapping activity

[Felix Palmen]

Since upgrading to 3.4, the vice binaries (x64sc, x64) somehow manage to get my machine into ever more intensive swapping until the system becomes completely unusable. As I don't see a suspicious SIZE or RES value in the output of top, it might be some "indirect" effect, triggering bugs in other libraries or drivers (rendering related maybe?)
Downgrading to 3.3 again solves the problem, builds created from FreeBSD ports (3.3_5 / 3.4_1)

Any idea what to test in order to identify the actual problem?

[compyx]

First off: I'm not a BSD user, so I'm not sure how much help I'll be.

When using VICE compiled from trunk on a FreeBSD 12.1 VM I don't see any memory use increase using OpenGL driver or Cairo running x64sc. I gave the VM 3GB mem and 2 CPU cores and installed xfce4.
I didn't install VBox guest additions yet, since last time I did that X11 failed to start, so the 'opengl' driver provided by Vbox is pretty crappy (menu and statusbar don't show, the emulated machines GtkGlArea flashes to black every second or so, probably in sync with updating the cpu/fps display).

The only VICE in my ports collection is vice 3.3, which seems to get built from the 3.3 tarball, which is quite a bit different from our current trunk. I installed ports during my FreeBSD install.

One thing you could try is running x64sc -gtkbackend 0 (with vice 3.4) to see if the OpenGL drivers somehow leak and Cairo doesn't.

Edit: I installed everything with pkg, rather than build from ports.

[Felix Palmen]

Thanks a lot compyx for actually trying something :) With your hints, I could analyze a bit further. First of all:

The only VICE in my ports collection is vice 3.3, which seems to get built from the 3.3 tarball, which is quite a bit different from our current trunk. I installed ports during my FreeBSD install.

FreeBSD ports are constantly updated in svn, but for fetching them with portsnap, there are two alternatives -- "current" snapshot or quarterly snapshot -- I guess the latter is the default. Vice 3.4 has been in the FreeBSD ports for a while now :)

I now fetched the latest svn trunk of vice (rev 37520) and built it with flags corresponding to what FreeBSD's port does using my build options -- just changed paths to have it in a different prefix:

./configure --prefix=/tmp/vice --enable-ipv6 --enable-external-ffmpeg --enable-x64 --disable-realdevice --disable-dependency-tracking --disable-silent-rules --enable-native-gtk3ui --disable-sdl2ui --with-sdlsound --without-alsa --without-pulse
MAKEINFOFLAGS="--no-split" gmake -j4
gmake install

The result is that my problem is indeed related to OpenGL. When running with -gtkbackend 0 option, everything is fine. Without that option, although there's no increase in memory usage of the x64sc process itself, the system starts swapping heavily after a while. Even after ending the process, the memory stays allocated -- the only way to recover is to reboot the system.

So I'm unsure this can be vice's fault, but the strange thing is I didn't find any other application triggering that behavior, and 3.3 (built from ports) also works fine with OpenGL.

One thing I was wondering about: In the 3.4 from ports, I had some kind of "audio button" in the lower right corner, this is gone with my build from trunk -- did I miss an option from the port or is this a change in the code since 3.4 release?

[compyx]

So we can conclude that the leakage using OpenGL has been introduced between the 3.3 and 3.4 tarball releases, and is probably (Free)BSD related as well, since we haven't had any complaints about this with Windows, Linux or MacOS.

What we usually do in these cases is a 'binsearch': pick the revision halfway between the 3.3 and 3.4 releases and see if the bug is there, if not: go up: pick a revision halfway between revision X and 3.4. If the bug isn't there pick the halfway revision between 3.3 and revision X. Recurse.
In this case, since we suspect OpenGL, we can reduce the number of revision needing checking by creating a list of commits that changed anything in our rendering and do a 'bsearch' with only those commits.

Problem here is having a proper bare-metal FreeBSD install to work with, I don't have any spare HW to install FreeBSD on, unless FreeBSD has proper OpenGL drivers for ATI Mobility Radeon 5470. I have laptop with that, but under Linux xorg is too new to support the binary radeon drivers and thus it uses an open source driver which isn't that great.

As for the volume control on the taskbar: I removed it because the statusbar code needs refactoring: when using drive 10 and/or 11 the widgets for that overlap with the volume control, leading to a right mess. =)

[compyx]

I managed to install FreeBSD on my Acer laptop with i3 + radeon with xorg + Gnome3 and using the radeonkms driver. FreeBSD is pretty snappy on this old box (with SSD), but I've gotten two kernel panics now about DRI, once while typing in a terminal and once while letting x64sc run, which (didn't increase process/total mem usage for about 5 minutes before the kernel panic.

Should I try some other video driver? I installed everything with pkg, perhaps getting an up-to-date snapshot of ports and compiling the driver (and perhaps x11) will help?
I also don't seem to have sound yet, but with the kernel panics, I don't see much use in trying to configure that.

The laptop should be fine, although old (I removed the battery and installed an SSD), it has been running Debian just fine for about three years now. I developed most of the Gtk3 UI code on it.

[Felix Palmen]

Ok first of all, I can do this testing ... but it might take a while, cause as soon as I can confirm the leakage, I have to reboot the machine for the next test :) But I'd happily try, and if there's something to debug, I might be able to do this as well...

On the other hand, it could also be a good idea to first check whether anyone else can reproduce the problem. It might even be the case that newer VICE versions just trigger a bug hidden somewhere else, e.g. in the radeonkms driver I use (I use an older version cause the most recent one doesn't detect my display ...)

As for the problems you face so far:

• I assume you installed FreeBSD 12.1? There's a port/package with kms graphics drivers drm-fbsd12.0-kmod which is fine for both FreeBSD 12.0 and 12.1 -- but as far as I know, the package is compiled for FreeBSD 12.0 and doesn't work correctly with the 12.1 kernel -- you should get a ports tree, then do cd /usr/ports/graphics/drm-fbsd12.0-kmod; make install clean.
• The FreeBSD 12.x kernel still has deprecated old kms drivers included (they will be removed in the next release). Therefore you must load the correct driver using the full path. Add this line to /etc/rc.conf: kld_list="/boot/modules/radeonkms.ko.
• About sound, normally it should be enough to add this to /boot/loader.conf: snd_driver_load="YES".

[compyx]

Fuck me, laptop just died =)

Edit: tested another power supply, still dead.

So no FreeBSD testing from my end, at least not until I find the even older AMD-based laptop and move the SSD into that one.

[Felix Palmen]

As I said, I can do the suggested testing myself :) Could you give me the revision numbers of the 3.3 and the 3.4 release and all revisions in between that could be relevant?

I really hope FreeBSD didn't kill a laptop here :o This is really bad luck!

[compyx]

I did the kld_list="/boot/modules/radeonkms.ko, and all was well. And Gnome Hell was snappy. Since the laptop won't power up with two different power supplies, I suspect normal HW failure (it is 5-7 years old I think), it dying and me using FreeBSD is just a coincidence.

Anyway, I'll try to identify all commits having to do with rendering on Gtk3 between the 3.3 and 3.4 releases. Not today though, I'm having a drink honoring my dead laptop.

[gpz]

is this still a problem with 3.5 (or trunk)?

[Felix Palmen]

No. Sorry for not getting anywhere with testing...

But the problem vanished with 3.5, it's working perfectly fine on FreeBSD (with loaded radeonkms driver).

[gpz]

so we can close this, right? :)

[Felix Palmen]

definitely. Whatever caused it, it's not in 3.5 (at least for me).

[Felix Palmen]

Although it might also be related to me upgrading FreeBSD from 12.1 to 12.2 as well, didn't test on 12.1 again. But as 12.1 will be EOL soon anyways, that probably doesn't matter.

[gpz]

closing