Bug Report: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
m (add note for current v4l list, some re-org, minor edits)
 
(23 intermediate revisions by 3 users not shown)
Line 1: Line 1:
If you find a bug please report it on:
If you find a bug please report it on:
* The [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media Linux-Media Mailing List] (LMML)
* the linux-dvb Mailing list (for [[DVB]] devices) or
** You can also open a bug at [http://bugzilla.kernel.org/ Kernel Bugzilla]<br>
* the linux-video mailing list (for [[V4L]] devices)
Please include all relevant information (what hardware, what environment) and try to provide a simple test case, as this makes it much easier to track down the actual problem. A good problem report should include:
# 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
# identification of the device
# the output of lspci -vnn
# the relevant portions of your dmesg log showing module probing and/or tuning. It also nice to add audio_debug options to modules, tuner_debug option to tuner module and debug option to tda9887, and then provide the dmesg output.
# Television standard for your country.
# Exact sequence of actions that causes your problem.


{{Note|If your error is encountered when building the V4L-DVB drivers from source, please first consult the results of the [[How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers#Building/Compiling_the_Modules|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.}}
Generally, "your problem" will likely be related to an app or the driver, 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]]).


==Information You Should Provide When Reporting a Bug==
Lastly, if you have an idea how to fix this bug please include the [[Bugfix]] in your email message!
Please include as much relevant information as possible to help diagnosis the problem. For example, a good problem report should include:
# identification of the device with which you are having difficulty
# the device's subsystem ID, taken from the output of lspci -vnn (for PCI/PCIe devices) or lsusb -v (for USB based devices)
# 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)
# 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
# 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.
# cite the television standard applicable for your device (e.g. ATSC tuner card, PAL capture card)
# 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 [http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb linux-dvb Mailing List] (subscribers only) (for [[What is V4L or DVB?|DVB devices]]) or
* the [http://www.redhat.com/mailman/listinfo/video4linux-list video4linux Mailing List] (for [[What is V4L or DVB?|V4L devices]])
Alternatively, you may wish to draw attention to this or seek help through one of the irc.freenode.net channels (#v4l - for webcams/analog TV issues or #linuxtv - for Digital TV issues)

==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:
* [https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html Fighting regressions with git bisect]
* [https://lwn.net/Articles/317154/ Fully automated bisecting with "git bisect run"]
* [http://webchick.net/node/99 Using Git bisect to figure out when brokenness was introduced]

Once the broken patch is identified, please report about that at the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media Linux-Media Mailing List].

Lastly, if you know or have an idea as to how to fix this bug, please [[Development: How to submit patches|submit a patch]] for it to the LMML.


[[Category:Development]]
[[Category:Development]]

Latest revision as of 12:39, 19 November 2015

If you find a bug please report it on:

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)

Alternatively, you may wish to draw attention to this or seek help through one of the irc.freenode.net channels (#v4l - for webcams/analog TV issues or #linuxtv - for Digital TV issues)

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:

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.