On Mon, 4 Jun 2018 a bug that doesn't want replies (especially to the reporter)@freebsd.org wrote:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228755 Bug ID: 228755 Summary: libvgl under syscons causes system reboot (via SDL 1.2) ... I was attempting to get a GUI going without any X dependency under the FreeBSD CURRENT; not finding any documentation regarding the viability of vgl under newcons/vt, I set kern.tty to sc and (after a reboot) attempted to run the attached SDL code sample with SDL_VIDEODRIVER set to vgl.
vt has no support for most of the ioctls used by libvgl.
When executed as sudo (a requirement for directly using vgl), the system reboots immediately. Using the vgl-wrapped-in-a-service SDL_VIDEODRIVER=aalib as an unprivileged user instead does not result in the same behavior (but it doesn't work, either).
I don't know anything about SDL, but planned to fix and maybe improve libvgl someday. libvgl is too primitive even for me, and its demo is unimpressive. I thought that no one used it. Support for libvgl seemed to be quite broken. Its demo works surprisingly well under FreeBSD-5 (it supports many graphics modes that syscons didn't support under FreeBSD), but under -current its demo never works. I debugged this a bit further today. The breakage seems to be small. libvgl still calls mmap() with flags MAP_FILE, but that was never valid and now causes mmap() to fail. MAP_FILE is the non-flag 0. One of the flags MAP_SHARED or MAP_PRIVATE must be set unless the OS release is < P_OSREL_MAP_FSTRICT = 11000036. So libvgl's misuse of mmap() apparently became fatal in FreeBSD-11. When mmap() fails, libvgl cleans up. The failure usually occurs after a successful mode switch, so considerable cleanup is needed. This always works here. But the demo does no error checking and crashes with SIGBUS. It is hard to see how this could cause a reboot. After fixing libvgl to use MAP_SHARED, libvgl and the demo work much the same as in FreeBSD-5. Modes up to 1280x1024x8 work in both. Fancier modes fail in both. The only interesting difference is that mmap() fails for VGA mode 257 in -current both works in FreeBSD-5. The same (FreeBSD-5) libvgl and demo program apparently calculates a too-large frame buffer size in -current only, and mmapping this fails. mmap() also fails for 1920x1080x8. Getting this size wrong in the driver is more likely to cause a reboot than failing.
I have observed the same behavior with a statically-linked SDL1.2 compiled from sources and when linking against the system SDL1.2 as installed via pkg. I have not attempted to use vgl directly, and will endeavour to do so if I get the time, thereby cutting out SDL from the picture entirely (though it does not seem to be the problem as changing the video driver to something other than vgl does not cause this system reboot and using SDL1.2 with vgl under a different platform similarly does not cause any adverse effects).
Maybe SDL uses a fixed vgl or more direct initialization. I also have tty access fixes which break all mmaps on ttys, and had to not use them to test this. Bruce _______________________________________________ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
