Feedback

Your feedback is important to keep improving our website and offer you a more reliable experience.
Home / Intel® Graphics for Linux* / Documentation / Intel® Graphics for Linux* - How to report bugs

How to report bugs

Published by:
Last modification:
Sep 25, 2017

How to file a bug report

 

 

1 - Pick a culprit component

 

When you face a bug it can be on Kernel or on User Space, give your best guess and follow instructions below.
Finally, 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

 

Before filing the bug, please try to reproduce your issue with the latest kernel. Use the latest drm-tip branch from http://cgit.freedesktop.org/drm-tip and build as instructed on our Build Guide.

File your bug in https://bugs.freedesktop.org/, against product DRI and component DRM/Intel. Make sure to include the following information:

  • A clear subject describing the issue.
  • Steps to reproduce the issue. 
  • How often does the steps listed above trigger the issue? For example: always, 1 out 3 times.
  • Update "i915 platform" information field as well as "i915 feature" if you can.
  • The following information about your system:
    • -- system architecture: ("uname -m")
    • -- kernel version: ("uname -r"). Again, please consider using latest drm-tip from http://cgit.freedesktop.org/drm-tip
    • -- Linux distribution:
    • -- Machine or mother board model:
    • -- Display connector: (such as HDMI, DP, eDP, ...)
    •  A full dmesg with debug information and/or a GPU crash dump
      • To obtain a dmesg with debug information, add drm.debug=0xe to your kernel command line or, if you have display issues with kernel 4.1 or newer, use drm.debug=0x1e log_buf_len=1M instead. Then, reboot and reproduce the issue again. Make sure to attach the full dmesg all the way from boot.
      • In the case of a GPU hang, dmesg will contain a "GPU crash dump saved to /sys/class/drm/card0/error" message. The contents of that file are crucial to debugging the issue. Note that the contents of that file are generated by the kernel when it is read, so it will appear to have zero bytes. Reading the file contents with cat will produce the expected result. For example, use
        $ cat /sys/class/drm/card0/error | bz2 > error.bz2

        Note that a new bug is preferred over adding your GPU crash dump to an already open bug. Most often the cause for the GPU hangs are different, and it is easy for the developers to mark bugs as duplicate.

  • Other attachments if relevant:
    • screenshot or photo (a picture is worth a thousand words);
    • output of "xrandr --verbose" for display mode issue;
    • intel_reg_dumper output (see the guide) and VBIOS dump (see the guide) for display issues;
    • for GPU hang, get the last batch buffer (see the guide);
    • for suspend/resume problems, refer to the guide.
  • Add any relevant tags at the beginning of the bug title to get right attention:
    •   [BAT] : failure related igt basic (ideally should be [IGT][BAT])
    •   [IGT]: failure related to igt test
    •   [DRM-INTEL-FIXES] : bug occurred on drm-intel-fixes branch and require high attention since code is going to be merged soon.

 

  • When reporting a regression bug, this is critical that both Good commit (where issue is not occuring) and Bad commit (where issue is occuring) are provided in the bug description because it will argue on the fact this is regression. Moreover, rather than tags we are using some specific keywords to handle them:
  •   regression : indicates this defect is a regression and both Good & Bad commits are provided,
  •   bisect_pending : indicate that a bisect is not yet done and therefore result is pending,
  •   bisected : indicates that a bisect was done and result is available in bug comments.

Developers may ask for additional information. In that case, the bug status will be changed to NEEDINFO. Once you provide the requested information, change the status of the bug to its previous value.

1.2 - 2D xf86-video-intel

 

  • https://bugs.freedesktop.org
  • Category: Product=xorg. Component=Driver/intel.
  • A clear subject. Starting with [[Chipset] [Subsystem/Feature]] to highlight if needed, such as [915GM TV] or [EXA].
  • System environment:
      -- chipset: (such as G965)
      -- system architecture: ("uname -m")
      -- xf86-video-intel/xserver/ version: (If you build it yourself, provide the git commit id or stable release version. If it's shipped with distribution, xf86-video-intel and xserver version are available in Xorg.0.log.)
      -- kernel version: ("uname -r")
      -- Linux distribution:
      -- Machine or mobo model:
      -- Display connector: (such as HDMI, DP, eDP, ...)
  • Reproduce steps. Probability if not 100% reproducible.
  • Attachment:
    • Xorg.0.log
    • dmesg output (mandatory boot option "drm.debug=0x06")
    • xorg.conf (if you changed any default options)
    • screenshot or photo (optional, a picture is worth a thousand words)
    • output of "xrandr --verbose" for display mode issue
    • for GPU hang, get the last batch buffer (see the guide).
 

1.3 - 3D Mesa

 

  • For new platforms chipset i965/G35 and later: Component=Drivers/DRI/i965.
    • For old platforms (chipset i8xx/i915/i945/Q33/G33/Q35): Component=Drivers/DRI/i915. - If you are uncertain use Component=Drivers/DRI/i965.
  • A clear subject. Starting with [[Chipset] [Subsystem/Feature]] to highlight if needed, such as [915GM TV].
  • System environment:
      -- chipset: (such as G965)
      -- system architecture: ("uname -m")
      -- mesa/libdrm version: (If you build 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:
  • Reproduce steps. 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. Better do a power cycle, instead.

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?