ssh -Y vbox_guest '<browser>' crashes host system

pinned

Member

Reaction score: 3
Messages: 22

When I attempt to load a GUI application (for example a browser like chromium or firefox) via ssh from a guest VM in VirtualBox , the host FreeBSD system crashes. This has happened several times after upgrading from 12.0 to 12.1.

My host system is a ThinkPad E490 running 12.1-RELEASE-p3. The DE is gnome3-lite.
It has drm-kmod-g20190710 and drm-fbsd12.0-kmod-4.16.g20200221 installed, with kld_list="/boot/modules/i915kms.ko" in /etc/rc.conf

All other graphical operation run just fine. I can directly access the VM GUIs with no problem.
I prefer to run them headless, and SSH into them to run a few apps.

The crashes occur when attempting SSH -Y (or -X) to devuan ascii guests, as well as freebsd guests. So, I'm not really sure what could be the root cause of the issue.

A bug report (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234422) from Dec 2018 hints at a similar issue. Here it states that this is not a problem with the drm-kmod port itself but with the actual DRM. So maybe that's what it is?

This is what I see in dmesg, with the timestamp around the time of the crash.

Code:
Apr 24 20:24:19 tpe490 devd[55378]: check_clients:  dropping disconnected client
Apr 24 20:24:19 tpe490 gdm[32739]: GdmDisplay: display lasted 0.096668 seconds
Apr 24 20:24:19 tpe490 devd[55378]: check_clients:  dropping disconnected client
Apr 24 20:24:19 tpe490 gdm[32739]: GdmDisplay: display lasted 0.098910 seconds
Apr 24 20:24:19 tpe490 devd[55378]: check_clients:  dropping disconnected client
Apr 24 20:24:19 tpe490 gdm[32739]: GdmDisplay: display lasted 0.097236 seconds
Apr 24 20:24:19 tpe490 gdm[32739]: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors
Apr 24 20:24:38 tpe490 login[57913]: ROOT LOGIN (root) ON ttyv4
Apr 24 20:25:19 tpe490 devd[55378]: check_clients:  dropping disconnected client
Apr 24 20:27:01 tpe490 shutdown[69518]: power-down by root:
Apr 24 20:27:02 tpe490 kernel: , 40187.
Apr 24 20:27:03 tpe490 kernel: , 28378.
Apr 24 20:27:03 tpe490 kernel: .
Apr 24 20:27:03 tpe490 ntpd[15948]: ntpd exiting on signal 15 (Terminated)
Apr 24 20:27:05 tpe490 kernel: , 15948.
Apr 24 20:27:05 tpe490 syslogd: exiting on signal 15
Apr 24 20:27:54 tpe490 syslogd: kernel boot file is /boot/kernel/kernel

There are several Xorg.n.logs for today. Xorg.0.log does not have anything relevant. This from Xorg.5.log

Code:
[    20.841] (EE) open /dev/dri/card0: No such file or directory
[    20.841] (WW) Falling back to old probe method for modesetting
[    20.841] (EE) open /dev/dri/card0: No such file or directory
[    20.841] (WW) Falling back to old probe method for scfb
[    20.841] scfb trace: probe start
[    20.841] (II) scfb(1): using default device
[    20.841] scfb trace: probe done
[    20.841] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[    20.841] (EE) Screen 0 deleted because of no matching config section.
[    20.841] (II) UnloadModule: "modesetting"
[    20.841] (EE)
Fatal server error:
[    20.841] (EE) Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices
[    20.841] (EE)
[    20.841] (EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
[    20.841] (EE) Please also check the log file at "/var/log/Xorg.5.log" for additional information.
[    20.841] (EE)
[    20.842] (EE) Server terminated with error (1). Closing log file.

Anyone else encounter this issue? Or can point me in the right direction? Thanks!
 
OP
P

pinned

Member

Reaction score: 3
Messages: 22

Code:
$ export LIBGL_ALWAYS_SOFTWARE=1
Thanks! This worked on both, FreeBSD and Devuan guests. I was able to run browsers and other apps via SSH without any crashes.

As you asked, I attempted glxinfo and glxgears as well. But these did not work on any of the guests.
Code:
$ glxinfo 
name of display: localhost:10.0 
Error: couldn't find RGB GLX visual or fbconfig 
$ glxgears 
Error: couldn't get an RGB, Double-buffered visual
 

kpedersen

Son of Beastie

Reaction score: 2,169
Messages: 3,007

Thanks! This worked on both, FreeBSD and Devuan guests. I was able to run browsers and other apps via SSH without any crashes.

I am glad that this is working for you. If it runs fast enough for you (via LLVMpipe software rendering) then that is great. However bear in mind that it will not be using your GPU so videos might be quite slow.

You might want to have a fiddle and see if any of these options can allow you to use the GPU but without crashing the host: https://www.mesa3d.org/envvars.html

It basically seems like a bug in GLX (or DRI?) but it might be possible to avoid it with the above.

One I have personally had success with is MESA_GL_VERSION_OVERRIDE which allows my older Thinkpad to run stupid software that they developer thinks is OpenGL 3 only when they only use OpenGL 2 functionality. Though I am fairly certain this is not causing the problem you are experiencing.
 
OP
P

pinned

Member

Reaction score: 3
Messages: 22

Thanks for the tip. At the moment, my use case for this is only for web app dev and to use citrix receiver. So far I haven't experienced any noticeable slowness. I'll test those options out nonetheless.
 

stream

Active Member

Reaction score: 6
Messages: 103

I had the same problem described in the OP.
I recently installed drm-kmod, and successfully ran X11 without xorg.conf, and "vesa" driver.

But when I ssh -Y to VM, it crashed my host, i.e. freebsd system. What is the purpose of LIBGL_ALWAYS_SOFTWARE, and where should it be placed- in the host or the VM, or both.
 

Alain De Vos

Son of Beastie

Reaction score: 794
Messages: 2,586

I think it prevents GPU hardware accelaration on the GPU card and just uses the CPU.
 

stream

Active Member

Reaction score: 6
Messages: 103

it still crashes if I do ssh -Y ###

But works only on ssh -X ###

The problem is that citrix does not lauch. Yikes. painful..
 

zeising@

Member
Developer

Reaction score: 22
Messages: 30

This should have been fixed in the last round of errata and security fixes for FreeBSD 11.3, 11.4 and 12.1.
 
Top