Bug Report

From LinuxTVWiki
Revision as of 05:30, 17 September 2009 by CityK (talk | contribs) (some reworking -- add Hans daily build tests and some formatting etc)
Jump to navigation Jump to search

If you find a bug please report it on:

The Daily Automated Build Tests

Note: Regarding Errors Encountered When Building V4L-DVB Drivers from Source:

Hans Verkuil has set up an automated daily build of the V4L-DVB source code upon all supported kernels, as well as testing those very same upon several CPU architectures. A brief synopsis of the results from those tests is published each day on the LMML under a message subject heading prefix of "[cron job]". A link to more detailed results of these tests is also provided within that message or can be found directly from here.

So, if you do run into any problems during driver compilation, check the results of the above first to see whether or not it is a known issue. If it appears that this is indeed a new issue, please inform the developers, via the mailing list, as mentioned previously. Alternatively, you may wish to draw attention to this through one of the irc.freenode.net channels (#v4l or #linuxtv or #dvb).

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 also nice to add 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)

Finding the source of the error via a Hg Bisect (i.e. being proactive and helping out)

The following needs to be done:

  • Describe what a bisect is (i.e. the concept) and then how to perform a bisect
  • Hg Bisect info

Lastly, if you have an idea how to fix this bug please include the Bugfix in your email message!