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.