Sorry, you need to enable JavaScript to visit this website.
Home / Intel® Graphics for Linux* / Programmer's Reference Manuals / Intel® Graphics for Linux* - How to report bugs

How to report bugs

Published by:
Last modification:
May 12, 2020


How to file a bug report


1 - Pick a culprit component

When you encounter a bug, it can be on Kernel or on User Space, make your best guess and follow the instructions below.
Please be specific
  - file separate bugs for each distinct case of failure; if you find several issues in one use case, please split them into several bugs.
  - report the defect by reporting root cause (fault, which can be seen in logs, for example) rather than just the symptom (such as a test or application is failing).

1.1 - DRM Kernel

Follow the bug filing instructions from the project's wiki.


1.2 - 3D Mesa

Mesa's issue tracker can be found on's gitlab.

Include the following details:

  • A clear subject. Starting with [[Driver] [Chipset] [Subsystem/Feature]] to highlight if needed, such as [IRIS ICL TransformFeedback].
  • System environment:
    • chipset: (such as G965)
    • system architecture: ("uname -m")
    • mesa/libdrm version: (If you built it yourself, provide the git commit id or stable release version. If it's shipped with distribution, provide libdrm version with "pkg-config --modversion libdrm" and mesa version with glxinfo output.)
    • kernel version: ("uname -r")
    • Linux distribution:
    • Machine or mobo model:
  • Steps to reproduce. Probability if not 100% reproducible.
  • Attachment:
    • dmesg output (mandatory boot option "drm.debug=0x06")
    • screenshot or photo (optional, a picture is worth a thousand words)
    • for GPU hang, get the last batch buffer (see the guide).
    • for 3D issues, run with LIBGL_DEBUG=verbose in the environment.


2 - Assistance to help debugging

  • Provide gdb backtrace. See the guide for how to use gdb for an X server crash.
  • For regression, try using git-bisect to locate the commit which caused the regression.
  • Compare with other products or configurations, if possible.
  • For VT switch problems, use intel_reg_dumper tool (see the guide) to dump the register info: 1) prior to VT switch 2) after VT switch.

3 - Tips

  • Specific: Each bug report is for only one issue/problem. If you found several issues in one test, please separate them into several bugs.
  • Close the bug if the originally reported issue is resolved. For new issues, open new bugs, instead of continuing the discussion in the old bug.
  • Attach a log, explicitly choosing "plain text (text/plain)" content type. Don't use zipped files (except on error state for gpu hang).
  • After answering developer's NEEDINFO, make sure 'NEEDINFO' is cleared in the keywords field and reassign it back to the developer owner.
  • Attach the monitor directly to the machine, rather than through a KVM or other devices.
  • Using warm reboot to try the new code is not completely clean for the gfx environment. We recommend doing a power cycle instead of warm reboot.

4 - Appendix: recommended general bug report template

Bug description:

System environment:
-- chipset:
-- system architecture: XX-bit
-- xf86-video-intel:
-- xserver:
-- mesa:
-- libdrm:
-- kernel:
-- Linux distribution:
-- Machine or mobo model:
-- Display connector:

Reproducing steps:

Additional info:


Was this information helpful?