Hauppauge Nova-T 500 work…

In an effort to empty out my backlog of issues, I spent most of last night looking at the Hauppauge Nova-T 500 and the various issues people have reported with regards to the dib0700 1.20 firmware.

Now, there are some people who might argue that the breakage is my fault, since I was the developer who pulled in the version 1.20 firmware and made it work (required to address i2c bugs preventing the dib0700 from working with the xc5000 tuner chip). And those people would be correct in doing so. 😉

Let’s talk about the issues…

The first issue is one related to rebooting. People have noticed that with the new firmware, if you reboot the box the card stops working. However, if you power off the computer and turn it back on, the card works. Some have claimed the behaviour as “seeing mt2060 i2c errors after rebooting”. I have reproduced the issue, and can confirm that in fact it has nothing to do with the mt2060. The entire dib0700 gets into a hung state, and the USB host controller halts the device, cutting off all communication with the bridge. The fact that people report this as “mt2060 errors” is because that is the first operation attempted when tuning, so those are errors seen in the dmesg output.

The other issue is what users have described as “mt2060 errors after several hours of use, which go away if I disable RC polling”. This is described in some detail on this Launchpad ticket, among other places:


I haven’t seen this firsthand yet, but I did spend some time looking at the IR changes that were required to make the 1.20 firmware work, and discovered something interesting: the IR polling doesn’t have it’s own thread, and uses the kernel’s global workqueue. As a result, the changes for 1.20 actually cause the global workqueue to be blocked for 50ms at a time, and then unblocked for 50ms, and so on. In other words, the global workqueue is in a completely blocked state 50% of the time, which could cause problems with whatever else in the system relies on the global workqueue (like say, the keyboard driver).

I actually discovered this because I thought perhaps the polling with a timeout on the bulk pipe was the problem, so I changed the timeout to zero (blocking indefinitely until data arrives), and as a result my keyboard stopped working.

I don’t yet know whether this is related to the mt2060 i2c errors, but it’s definitely a *bad* thing and should probably be corrected.

At this point, I will see if I can come up with a reproducible sequence to cause the mt2060 errors, and then see if moving the IR polling to its own thread has any effect. Unfortunately, because the errors are intermittent and supposedly only occur after several hours, this is likely to be a time consuming process.

10 thoughts on “Hauppauge Nova-T 500 work…

    • Guillem,

      No, I am referring to the Nova-T 500, not the Nova-TD 500. The Nova-TD 500 has a dib0710 (and two ariel inputs), whereas the Nova-T 500 uses a Via PCI to USB bridge and only has a single input.



  1. The ASUS U3100 Mini DVB-T which uses the dib0700 shows similar symptoms after a reboot. I notice the light on the U3100 stays on when I shut down the computer. I need to physically unplug it and reconnect it before rebooting to get it to work again. Any ideas?

    • Kevin,

      At this point I don’t have any specific advice. I’m working on narrowing down the problem (and in fact I fixed the other dib0700 issue mentioned in the post yesterday).


        • Hello Kevin,

          Yes, it would be great if you could try out that tree. When you test, you should *not* have “disable_rc_polling=1” present in the modprobe.conf, since the whole point of the change is that the board should work properly without any special modprobe parameters.



          • Hi,

            I couldn’t get the “dib0700-ir“ code to work on Ubuntu 9.10 with stock (2.6.31-16-generic) kernel. Is it supposed to work with the stock kernel? I did a make, make install, and restart.

            When I tried to Watch TV in MythTV 0.22 the PC pretty much locked up. The keyboard became less responsive and I could not reliably switch to a terminal window to work out what was going on. Reset button did the trick. The following error was reported in “/var/log/mythtv/mythtvbackend.log“:

            DevRdB(/dev/dvb/adapter0/frontend0) Error: Driver buffers overflow

            I tried with RC polling enabled. I also tried with RC polling disabled and had the same problem which suggests my problem may not be related to the code you changed.

            I can try again with debugging turned on for the dvr-usb-dib0700 and dvr-usb modules. Or possibly apply your change as a patch to the version of the driver included in the 2.6.31-16-generic kernel (hopefully it is tagged in an hg or git repository).

            Let me know if you want me to do anything else.

          • Hello Kevin,

            Before you go any further, please try the mainline tree at http://linuxtv.org/hg/v4l-dvb and see if the problem occurs there as well. If it does, please send mail to the linux-media mailing list asking for help (as the changes would be unrelated to my IR patches).


  2. Hi,
    Thank you very much for your work. The “hang after reboot” issue has been screwing me for a long time, effectively since the new 1.20 firmware was introduced (but which finally fixed the infamous “nova-t 500 disconnect” bug…). Sadly this issue has been there for a long time, and even if it was repeteadly reported in LinuxTV mailing lists nobody seemed to care a lot about it…

    I really hope you are able to fix this one. Count on me for testing, if needed.


    • Hi Eduard,

      Yeah, it’s a tough situation. Many people reported significant improvement in terms of the disconnects when I introduced the 1.20 firmware, so I couldn’t just revert it (and 1.20 was actually required for certain boards). The cost was the reboot issue and the mt2060 errors (both of which were reported exclusively against the Nova-T 500). Now that I finally have a board and some free time, I’m hoping to nail down those issues (in fact, I think I may have resolved the issue forcing people to stick “disable_rc_polling=1” into their modprobe.conf).

      Regarding the “nobody seems to care”, there is definitely some truth to this. There are very few actual developers contributing to the codebase, and there are considerable constraints related to who has which boards and access to the appropriate signal sources. The developers are unpaid and work on the areas that interest them, which is unfortunately not always the same things that some users want them to work on. I guess you could argue that “you get what you pay for” in terms of support.


Leave a Reply