Tips that may Help to Solve your Issue in Less Timed
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 http://ark.intel.com/ 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 easily reproduce 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 occurring) and Bad commit id (where regression is occurring ; 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 :^)
Did you find the information on this page useful?