kernel

Differences between revisions 8 and 9
⇤ ← Revision 8 as of 2014-01-03 03:28:10 →
Size: 214
Editor: penalvch
Comment: Redid /Include so all of the upstream procedure is captured.
← Revision 9 as of 2016-09-11 17:11:46 → ⇥
Size: 338
Editor: penalvch
Comment: Added source URL for page in # comment as FYI.
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
# The page contents are sourced from https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_upstream_kernel_bugs

Introduction

  • If your downstream bug report on Launchpad has been marked Triaged, and a Ubuntu community member asked you to read this, thank you for doing so! By reading and following this completely, you are maximizing the speed with which your bug will be fixed. Please take care to read every step carefully.

First step: Prepare the Kernel.org format information

  • Note the below Kernel.org format was taken directly from upstream.

  • Warning /!\ Please ensure you follow the below format word for word. Just because you tested the latest mainline kernel, may have bisected a kernel regression, or others say they are experiencing the same problem, doesn't mean you should omit anything. Providing this information is vital for a developer to fix your problem, and to maximize the chance of your bug being addressed.

  • Warning /!\ Please take care that when you provide the below information, check that you are booted into the newest available upstream mainline kernel only. Folks have had their bug marked Triaged, sent their e-mail, but had a newer kernel release come out without them realizing this. Hence, if upstream didn't ignore your report altogether, they will ask you to test this in the newest release that just came out and you didn't check for. Failure to do this may have negative unintended consequences. The Ubuntu kernel is the Ubuntu Community's responsibility, the upstream mainline kernel is the Kernel.org Community's responsibility, of which Ubuntu is a part of.


[1.] One line summary of the problem:
Please paste the Bug Description, and remove all references to Ubuntu and Ubuntu's kernels. The reason for this is that the issue you are reporting is an upstream one.

[2.] Full description of the problem/report:
2a. While booted into the newest upstream mainline kernel only, how is the bug reproducible on a keyboard click for click basis?
2b. Is this a regression? If so, after commit bisecting, what is the commit that caused the regression?

[3.] Keywords (i.e., modules, networking, kernel): Please do not put anything here. This is how there is no known keyword system.

[4.] Kernel version (from /proc/version):
While booted into the newest upstream mainline kernel only, please execute the following in a terminal and paste the results:
cat /proc/version

[5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt)
This is only relevant if you had a kernel oops crash (ex. flashing Caps Lock light). While booted into the newest upstream mainline kernel only, if you have a kernel oops, one may consult http://www.kernel.org/doc/Documentation/oops-tracing.txt . If this is too daunting please ask for help.

[6.] A small shell script or example program which triggers the problem (if possible)
This is for advanced community members. If you feel comfortable enough, please do it. It is not critical if you are unsure on how to do this.

  • Warning /!\ For input problems only
    For reports that would normally be sent to the linux-input mailing list, as requested by the maintainer, please do not send any of the information from section [7.] through [7.7] below.

[7.] Environment
Please execute the following in a terminal, and paste the results:
lsb_release -rd

[7.1.] Software (add the output of the ver_linux script here)
While booted into the newest upstream mainline kernel only, this is found in the directory:
/usr/src/linux-headers-<VERSION>/scripts

where <VERSION> is the version of the kernel you are using, found in the directory /usr/src. You may run the script by changing to the directory via a terminal, and paste the results:
sh ver_linux

[7.2.] Processor information (from /proc/cpuinfo):
While booted into the newest upstream mainline kernel only, execute the following in a terminal, and paste the results:
cat /proc/cpuinfo

[7.3.] Module information (from /proc/modules):
While booted into the newest upstream mainline kernel only, execute the following in a terminal, and paste the results:
cat /proc/modules

[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
While booted into the newest upstream mainline kernel only, execute the following in a terminal, and paste the results:
cat /proc/ioports
cat /proc/iomem

[7.5.] PCI information ('lspci -vvv' as root)
While booted into the newest upstream mainline kernel only, execute the following via a terminal, and paste the results:
sudo lspci -vvv

[7.6.] SCSI information (from /proc/scsi/scsi)
While booted into the newest upstream mainline kernel only, execute the following via a terminal, and paste the results:
cat /proc/scsi/scsi

[7.7.] Other information that might be relevant to the problem (please look in /proc and include all information that you think to be relevant):
While booted into the newest upstream mainline kernel only, execute the following via a terminal, and paste the results:
ls /proc

[X.] Other notes, patches, fixes, workarounds:

[X.1] Bluetooth problems only - Please execute the following in a terminal and post the results:
sudo cat /sys/kernel/debug/usb/devices

[X.2] Please provide a link to your Launchpad bug report.

[X.3] Any further debugging information from http://www.kernel.org/doc/Documentation/ using the newest upstream mainline kernel available, and all relevant comment information not included in the Bug Description. Doing this makes it easier for kernel developers to review your problem without having to dumpster dive through various links, and increases the chance of your problem being reviewed. If you are unsure about anything asked for, or intend on not following this format, you are reducing the chances of having your problem reviewed. Instead, one would want to get help, until all issues are cleared up.

Second step: Prepare your email to be sent

Now that you have prepared the Kernel.org format information, the next step is formating your email correctly. Specifically:

  1. When sending an email, do so in plain text, not html. Otherwise, it will be flagged as SPAM, and silently discarded without notification to you. For more on this and other reasons your post would be flagged as SPAM, please see here.

  2. Do not send attachments. Instead, post all information in the body of your e-mail.

Third step: With the Kernel.org format send to appropriate maintainers

Reporting Graphics card driver bugs

All other drivers send an E-Mail TO: the maintainers and CC: the maintainer mailing list

  1. Please ensure you send your email TO: all maintainers of the driver in the TO: field, and put the mailing list in the CC: field. A list of both may be found here. The 'M:' is the Maintainer, and the 'L:' is the mailing list. If no list is specified, send an e-mail TO: the maintainers of the relevant driver.

  2. If this is a regression, also put the submitter of the regression commit in the TO: field.

  3. If the author of the driver (which may or may not be the current maintainer) appears still active in development, or the driver isn't listed, one would want to put the author in the TO: field. They may be found via a terminal:

    modinfo DRIVER
    Where DRIVER is the name of the kernel driver.

  4. Please ensure you post in your Launchpad report a URL of your e-mail from the mailing list found from the mailing list archives. It can take a few hours to days for the e-mail to show up to the respective archive.

* Please note that for non-WiFi USB bugs, the USB maintainer(s) do not want anyone to create a Bugzilla report. For more on this, please see this upstream report comment. If you do open an upstream report anyways, it will be immediately closed, and may cause negative unintended consequences.

Fourth step: No response from maintainers

If no response to your email has been received within a week, and the issue is still reproducible with the latest mainline kernel available, then if the issue is related to:

Negative unintended consequences

  • If you contact upstream, please follow the Kernel.org format created by Kernel.org developers. Failure to follow these directions exactly as shown may have the following negative unintended consequences:
    • May likely result in your bug requiring upstream developers to ask unnecessary follow up questions that should have been provided upfront.
    • May likely result in your bug being promptly ignored by the kernel maintainer, sub-maintainer, or community developer(s) responsible to fix your kernel bug.

    • May create friction between you, the Ubuntu Community, and the kernel.org developers, which is not very Ubuntu.

CategoryKernel

Bugs/Upstream/kernel (last edited 2019-02-11 14:01:08 by penalvch)