How to File i915 Bugs ¶

Checklist before filing a bug ¶

Have you tried a recent kernel?

The issue may have been fixed already. Please try the most recent mainline or development kernel listed at kernel.org or, preferrably, the latest drm-tip graphics development branch from the drm-tip repository. (For kernel build instructions, see How to Build the Kernel.)
Are you running a supported kernel version?

Please see the supported kernel versions at kernel.org. If your kernel version isn’t listed, please upgrade to a supported version, or contact your kernel provider instead.
Are you running an upstream kernel?

If not, the issue might be in a downstream modification of the kernel, and we can’t help. Please try a recent mainline kernel (see above), or contact your kernel provider instead.
Is i915 the right component?

Do you have an Intel GPU? Is this a kernel bug?
Does the bug report exist already?

The issue may have been filed already. Please see the drm-intel issue tracker. When in doubt, always err on the side of filing a new bug report. It’s easier to close duplicates than to untangle reports with multiple issues.
Are you willing to follow-up with the bug?

In most cases, the initial information is not sufficient. The developers will request you to provide additional information, and even try changes to the kernel or driver. It’s often not possible for the developers to replicate your exact hardware and software environment to reproduce the issue.
Are you filing a security bug?

Please refer to security bugs. This channel offers no confidentiality for responsible disclosure.

Filing a bug ¶

Please file issues in the drm-intel issue tracker. Please be sure sure to include the following information:

A clear title 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.
Which platforms and features are affected (if you can).
The following information about your system:
- Kernel version, Linux distribution, and architecture. Easiest is to copy-paste the information printed by uname(1):
```
uname -a
```
  or, if you prefer to hide your hostname:
```
uname -srvmo
```
- The PCI device information as printed by lspci(8):
```
lspci -vnn -d :*:0300
```
- Machine or mother board model (use dmidecode(8) if needed)
- Attach full dmesg(1) output with debug information
  
  Add drm.debug=0xe log_buf_len=4M ignore_loglevel parameters to the kernel command-line, reboot, and reproduce the issue. Attach full dmesg all the way from boot to the problem.
See the following sections for relevant details depending on your issue.

Details on display issues ¶

Please consider adding the following extra information on display issues, as necessary:

Display connector, such as HDMI, DP, eDP, etc.
Desktop environment.
xrandr(1) output:
```
xrandr --verbose
```
Screenshot or photo (a picture is worth a thousand words).
VBT dump. See Video BIOS Tables (VBT).
Register dump. See How to Dump Registers. (Only if specifically requested by the developers.)

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 | bzip2 > 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 close the duplicates.

Details on suspend/resume issues ¶

Please see How to Debug Suspend-Resume Issues on suspend/resume issues.

Regressions ¶

Did something use to work, and then stopped working after a kernel update? This is called a regression.

When filing regressions, please indicate a known working kernel version, and a known broken kernel version.

Better yet, if you can git-bisect(1) the regression, it’s often the quickest way to both pinpoint and resolve the issue. Please add the git bisect log to the issue after finding the first bad commit.

Dos and don’ts ¶

Do:¶

Please attach logs and lengthy outputs to the issue, using the paperclip attach icon.

Don’t:¶

Please don’t add logs or outputs to external sites and link them. Attach instead.
Please don’t add logs or lengthy outputs inline in the comments. Attach instead.
Please don’t merely link to external bug reports. Include the gist of the issue in the description.
Please don’t use the GitLab confidential checkbox. (“This issue is confidential and should only be visible to team members with at least Reporter access.”)

After filing a bug ¶

Please follow-up on the issues you’ve filed. Please provide the information requested by the developers to debug and resolve the issue.

Bug reports abandoned by the reporter often end up being unresolved and abandoned altogether.