• MarkLinimon
• WorkAreaGraphics
• Debugging

Debugging Graphics Problems

If you are having problems with Graphics on FreeBSD, you may be asked to provide information from your system.

Here are some things that you need to know.

Getting Information

• dmesg(8)

  • Everyone should become familiar with dmesg. (If the output is incomplete, you many need to look at /var/run/dmesg.boot.)

  • Here are the relevant details from one very simple x86 system with graphics on the motherboard:

vgapci0: <VGA-compatible display> port 0xdc80-0xdcff mem 0xf6000000-0xf6ffffff,0xc0000000-0xdfffffff,0xf4000000-0xf5ffffff irq 24 at device 0.0 on pci2
vgapci0: Boot video device
[...]
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0

• kldstat(8)

  • kldstat -v gives you detailed information about which devices are built into your kernel, and also, which other modules have been loaded.

  • To find out if you have the drm2 module loaded, and if so, where it came from:

    • kldstat -v | grep drm2

Debugging Tips

Complaints From glxinfo/glxgears

If you get libGL error: failed to open drm device, try the following suggestion from CarlosPuga:

  pw groupmod video -m <youruser>
  cat >> /etc/devfs.rules << EOF
  add path 'dri/*' mode 0666 group video
  add path 'drm/*' mode 0666 group video
  EOF

Kernel Features

• It is useful to see what features the kernel reports as being available, especially in regards to driver features exposed via the linuxkpi. On FreeBSD these are mapped to sysctl compat.linuxkpi. The best way to see what's available for your driver is to execute sysctl compat.linuxkpi after you loaded the driver. For description of what these parameters do, call sysctl with the description flag.

  • % sysctl -d compat.linuxkpi.enable_fbc

    compat.linuxkpi.enable_fbc: Enable frame buffer compression for power savings (default: -1 (use per-chip default))

DRM-specific issues

• Periodically you will have a kernel panic but a core will not be recorded. You can test setting this sysctl knob which will prevent you from entering ddb on panic which has been found to unreliable in some circumstances:

  • debug.debugger_on_panic=0

• Also, adding this to your /boot/loader.conf can help in these scenarios:

  • dev.drm.skip_ddb="1"

• The following can be useful for providing context and can be set in /boot/loader.conf to ensure debug output remains enabled. The one problem with it is that debug output will slow things down enough to mask many problems:

  • dev.drm.drm_debug_persist="1"

• Want to enable all DRM related debug flags at runtime? There is a knob for that:

  • dev.drm.drm_debug=-1

KMS Drivers

• KMS drivers through linux-kpi report debugging information using debugfs. To mount it:

  • # mkdir /debug && mount -t debugfs none /debug

Hardware Acceleration

• To test how hardware acceleration is working you may want to run glxgears, but by default it may force syncing with your display (60fps for example). To disable this you can invoke glxgears like so:

  • $ env vblank_mode=0 glxgears