Bug Report

If you find a bug please report it on:

• The Linux-Media Mailing List (LMML)
  • You can also open a bug at Kernel Bugzilla
    

Note: If your error is encountered when building the V4L-DVB drivers from source, please first consult the results of the The Daily Automated Build Tests to see whether or not it is a known issue. If it appears that this is indeed a new issue, please inform the developers as outlined in this article.

Information You Should Provide When Reporting a Bug

Please include as much relevant information as possible to help diagnosis the problem. For example, a good problem report should include:

1. identification of the device with which you are having difficulty
2. the device's subsystem ID, taken from the output of lspci -vnn (for PCI/PCIe devices) or lsusb -v (for USB based devices)
3. the environment your running it under (e.g. Fedora 10, with kernel 2.6.27.5, 64-bit), and with what other hardware (e.g. ASUS Core 2 Duo motherboard)
4. a note of whether you're using the built in kernel drivers supplied by your distro or if you have installed the v4l-dvb driver set, or those from one of the LinuxTV developers' repos
5. the relevant portions of your dmesg log showing module probing and/or tuning (if applicable). It is also nice if you have added module debug options (for example: audio_debug, tuner_debug, tda9887 debug etc etc) for the driver module in question, and then provide the dmesg output.
6. cite the television standard applicable for your device (e.g. ATSC tuner card, PAL capture card)
7. Exact sequence of actions that causes your problem. If it is possible, try to provide a simple reproducible test case, as this makes it much easier to track down the actual problem.

Generally, "your problem" will likely be related to a driver, an app, or a combination of the two. It isn't always easy to tell where the exact problem lies. A big help is to check each part with various tools (for example, with analogue devices, you can try those in the V4L Test Suite).

You may also wish to seek the opinion of other users at the following mailing lists (though, they are largely deprecated now in favour of the LMML)

• the linux-dvb Mailing List (subscribers only) (for DVB devices) or
• the video4linux Mailing List (for V4L devices)

Alternatively, you may wish to draw attention to this or seek help through one of the irc.freenode.net channels (#v4l or #linuxtv or #dvb)

Finding the source of the error via git bisect (i.e. being proactive and helping out)

Note: Though some development is still done in conjunction with Hg repositories, most is now done with git. In other words, the following info is unlikely to be relevant, but for in a few remaining cases, as it is much more likely that you'd have to track down errors in commits to git repos instead of doing Hg bisects

When a driver used to work on earlier versions of the Kernel, but doesn't work on newer ones, that means that a regression happened. Finding what change broke a driver is not easy, and usually need to be done by someone with the hardware. Thankfully, the tool used to handle patches at the Kernel (git) has a tool to allow identifying what change broke a driver. It is called git bisect.

You could get more info about that and how to use at:

• Fighting regressions with git bisect
• Fully automated bisecting with "git bisect run"
• Using Git bisect to figure out when brokenness was introduced

Once the broken patch is identified, please report about that at the Linux-Media Mailing List.

Lastly, if you know or have an idea as to how to fix this bug, please submit a patch for it to the LMML.