How to Report Bugs
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 Freedesktop.org'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:
- Cchipset: (such as G965)
- System architecture: ("uname -m")
- Mmesa/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.
- 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
-- system architecture: XX-bit
-- Linux distribution:
-- Machine or mobo model:
-- Display connector:
Did you find the information on this page useful?