Sorry, you need to enable JavaScript to visit this website.

Home / Intel® Graphics for Linux* / Documentation / Bugs and Debugging / Intel® Graphics for Linux* - Tips that may help to solve your issue in less time

Tips that may help to solve your issue in less time

Published by:
Last modification:
Feb 17, 2017

Tips that may help to solve  your issue in less time

Here are some tips that certainly can foster issue resolution:
  • Check if the issue you are facing is already reported thanks to the search function of Bugzilla. If so, please report your issue there with details, otherwise create a new issue,

  • Verify that your issue exists with the latest Intel® Graphics Stack Recipe (ie DRM kernel, libdrm, xf86-video-intel, mesa, libva vaapi – i915 driver, firmware) since it may be already fixed,

  • Verify on your CPU/GPU specification in order to confirm that the issue you are facing is in the boundary of these specifications,

  • Try to reproduce issue using default options (no specific i915  parameter in command line),

  • Be specific: Each bug report is for only one issue/problem. If you found several issues in one test, please split them into several bugs,

  • On a case of IGT test failing, note that test tries to tell you why something is failing and therefore, file separate bugs for each distinct case of failure,

  • Add as much accurate details as possible, including hardware and software configuration, logs,  gdb trace, … and clear steps to allow us to reproduce easily the issue,

  • Always add drm.debug=0xe to the kernel command line to get details in kernel log,

  • When attaching the dmesg also make sure that it is complete and contains everything from the first boot messages. If there's too much in dmesg so that the kernel dmesg buffer overflows and overwrites early boot messages, you can extend the dmesg buffer by adding log_buf_len=4M on the kernel cmdline. Increase the size even more if that's not enough. For kernel bugs always attach dmesg,

  • Mark old attachments as obsolete (this is only required if there are already quite a few attachments on the bug) to be able to keep a quick overview,

  • In a case of a regression, always add Good commit id (where regression was not occuring) and Bad commit id (where regression is occuring ; please note that Bad commit id must be more recent than Good commit id), and if you can, try to use git-bisect and provide bisect information such as commit that causes regression, Note that successful bisecting should be done before setting Status = ASSIGNED and Assignee = <Submitter/Author of Offending Commit> as it is assumed that reverting or fixing will be done by this person with existing knowledge.

  • If you can quickly fix the bug, just do it and submit a patch :^)






















Was this information helpful?