[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]

Debian Linux Kernel Handbook
Chapter 9 - Reporting and handling bugs

9.1 Bug handling policy for the kernel team

9.1.1 Required information

Submitters are expected to run reportbug or other tool that runs our bug script under the kernel version in question. The response to reports without this information should be a request to follow-up using reportbug. If we do not receive this information within a month of the request, the bug may be closed.


9.1.2 Severities

Many submitters report bugs with the wrong severity. We interpret the criteria as follows and will adjust severity as appropriate:

critical: makes unrelated software on the system (or the whole system) break...

The bug must make the kernel unbootable or unstable on common hardware or all systems that a specific flavour is supposed to support. There is no 'unrelated software' since everything depends on the kernel.

grave: makes the package in question unusable or mostly so...

If the kernel is unusable, this already qualifies as critical.

grave: ...or causes data loss...

We exclude loss of data in memory due to a crash. Only corruption of data in storage or communication, or silent failure to write data, qualifies.


We include lack of support for new hardware that is generally available.

9.1.3 Tagging

We do not use user-tags. In order to aid bug triage we should make use of the standard tags and forwarded field defined by the BTS. In particular:

9.1.4 Analysis by maintainers

Generally we should not expect to be able to reproduce bugs without having similar hardware. We should consider:

9.1.5 Testing by submitter

Depending on the technical sophistication of the submitter and the service requirements of the system in question (e.g. whether it's a production server) we can request one or more of the following:

When a bug occurs in what upstream considers the current or previous stable release, and we cannot fix it, we ask the submitter to report it upstream at bugzilla.kernel.org under a specific Product and Component, and to tell us the upstream bug number. We do not report bugs directly because follow-up questions from upstream need to go to the submitter, not to us. Given the upstream bug number, we mark the bug as forwarded. bts-link then updates its status.

9.1.6 Keeping bugs separate

Many submitters search for a characteristic error message and treat this as indicating a specific bug. This can lead to many 'me too' follow-ups where, for example, the message indicates a driver bug and the second submitter is using a different driver from the original submitter.

In order to avoid the report turning into a mess of conflicting information about two or more different bugs:

Where the original report describes more than one bug ('...and other thing...'), we should clone it and deal with each separately.

9.1.7 Applying patches

Patches should normally be reviewed and accepted by the relevant upstream maintainer (aside from necessary adjustments for an older kernel version) before being applied.

9.1.8 Talking to submitters

We should always be polite to submitters. Not only is this implied by the Social Contract, but it is likely to lead to a faster resolution of the bug. If a submitter overrated the severity, quietly downgrade it. If a submitter has done something stupid, request that they undo that and report back. 'Sorry' and 'please' make a big difference in tone.

We will maintain general advice to submitters at http://wiki.debian.org/DebianKernelReportingBugs.

9.2 Filing a bug against a kernel package

Debian kernel team keeps track of the kernel package bugs in the Debian Bug Tracking System (BTS). For information on how to use the system see http://bugs.debian.org. You can also submit the bugs by using the reportbug command from the package with the same name. Please note that kernel bugs found in distributions derived from Debian (such as Knoppix, Mepis, Progeny, Ubuntu, Xandros, etc.) should not be reported to the Debian BTS (unless they can be also reproduced on a Debian system using official Debian kernel packages). Derived distributions have their own policies and procedures regarding kernel packaging, so the bugs found in them should be reported directly to their bug tracking systems or mailing lists.

Nothing in this chapter is intended to keep you from filing a bug against one of the Debian kernel packages. However, you should recognize that the resources of the Debian kernel team are limited, and efficient reaction to a bug is largely determined by the amount and quality of the information included in the bug report. Please help us to do a better job by using the following guidelines when preparing to file the bug against kernel packages:

9.2.1 Bisecting (finding the upstream version that introduced a bug)

When a bug is easy to reproduce locally but hard to get developers to reproduce (as is often true of workflow- or hardware-dependent bugs), it can be useful to compile and test a few versions to narrow down what changes introduced the regression.

To start, recreate the problem with a vanilla kernel:

     # apt-get install git build-essential
     $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
     $ cd linux

The above commands acquire a vanilla kernel. Configure, build and test a binary package as explained in Building a custom kernel from Debian kernel source, Section 4.5:

     $ make localmodconfig; # minimal configuration
     $ scripts/config --disable DEBUG_INFO; # to keep the build reasonably small
     $ make deb-pkg
     # dpkg -i ../linux-image-3.5.0_3.5.0-1_i386.deb; # substitute package name from the previous command
     # reboot

If the bug doesn't show up, try again with the official configuration file from /boot. (If it still doesn't show up after that, declare victory and celebrate.)

Initialize the bisection process by declaring which versions worked and did not work:

     $ cd linux
     $ git bisect start
     $ git bisect good v3.0; # or whichever was known to be good
     $ git bisect bad; # current version is bad

Now git checks out a version half-way in between to test. Build it, reusing the prepared configuration.

     $ make silentoldconfig
     $ make deb-pkg

Install the package, reboot, and test.

     $ git bisect good; # if this version doesn't exhibit the bug
     $ git bisect bad; # if it does
     $ git bisect skip; # if some other bug makes it hard to test

And on to the next iteration:

     $ make silentoldconfig
     $ make deb-pkg

At the end of the process, the name of the "first bad commit" is printed, which is very useful for tracking down the bug. Narrowing down the regression range with a few rounds is useful even if you don't get that far; in that case, run git bisect log to produce a log. If you are the visual sort of person, git bisect visualize with the gitk package installed can show what is happening between steps.

See Christian Couder's article "Fighting regressions with git bisect" from kernel.org or the git-doc package for details.

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ next ]

Debian Linux Kernel Handbook

version 1.0.16, Fri 14 Aug 12:53:11 CEST 2015

The Debian Kernel Handbook Project