I finally spent the day and gathered up all the various patches I had kicking around for the HVR-950q. They can be found here:
http://git.kernellabs.com/?p=dheitmueller/cx23885_fixes.git;a=shortlog;h=refs/heads/950q_fixes
This includes the longstanding bug at startup that would cause the xc5000 to not properly bind on the digital side, a rather nasty case that hangs the analog video decoder in adverse signal conditions, and a case where sometimes digital tuning succeeds but doesn’t ever return a transport stream to userland. It also resolves the confusion users see when the run tools like azap and the SNR is bouncing between 0x0190 and 0x0000.
I’ve got a few other things cooking in this area such as reviewing/refining/testing Mark Lord’s proposed changes for speeding up the firmware load, as well as some other reliability improvements.
It’s probably worth noting that this patch series does *not* address a known issue reported on the MythTV mailing lists with regards to a BUG() occurring in res_free().
Update: I just took a quick look at the code related to res_free(), and I suspect the problem is simply a missing res_check() call in au0828-video.c:vidioc_streamoff(). Should be just a two line fix bug I am not setup to test it (I don’t have a Myth box at my disposal). Speak up in the comments if you’re able to compile your own kernel and want to try the fix.
Update (2): A patch fixing the res_free() bug was added to the series after this post was originally written. So if you install the current tree you will have the fix.
Hi Devin,
I have a problem where on Ubuntu 12.04 the hvr 950q causes a kernel bug to occur. Is there a chance this would fix this? So far, the only way to get the hvr to work has been to stick with Ubuntu 11.10. And even that has had its share of failure. Whenever I try to switch channel, I get brought back to the main mythtv screen with a “error program jump file” ( the error message is approximate, I’m not at home right now)
You seem to know the hvr 950q very well. If you can point me in the right direction I would be forever greatful. Thanks
Hello prochefort,
Without knowing specifically what you mean by “kernel bug”, I cannot comment on whether the patch series will actually help you. That said though, a bunch of bugs were fixed so you would be well served to give it a try.
Cheers,
Devin
i have a problem with my dmb-th card. after a patch on the frontend.c, an error shown and saying xc5000 is not supporting dmb-th anymore. i guess it is due to a missing swich-case of SYS_DMBTH in the set_params function.
Hello Chancho,
General questions about driver support should be directed to the linux-media mailing list (not posted on completely unrelated blog posts).
That said, while I did do quite a bit of work on the xc5000 driver, I never added support for DMB-TH (although technically the tuner should support it). If you would like to continue this discussion, please start a thread on the linux-media mailing list.
Devin
This is great news. I’ve been trying to get an install of Mytbuntu 12.04 (x64 mythtv 0.25) working with two identical 950q’s. I haven’t been able to find the secret sauce of module load timing to work around the “xc5000: Device not found” issue that I assume is related to the udev issue that you patch here. Incidentally, I also have a 950 that I would like to add at some point.
I’ll be trying to build this snapshot sometime this week and give this a go. I’m not sure what trigger the res_free() bug, but if you’d like to supply the patch and some information on how to trigger, I’d be happy to try to help test.
Thanks so much for your continued work on this! -Jim
Hello Jim,
The “Device not found” issue is indeed the same issue that I refer to with udev. With this patch series, you should no longer encounter that problem and should be able to use the standard module loading.
The fix for the res_free() bug is the fifth patch on that tree (i.e. au0828: fix case where STREAMOFF being called…”). I pushed it after I wrote the original blog post, and I forgot to stick an update onto the end of the post to make clear the patch is now in the series.
Devin
Thanks for the response and info Devin. I had looked at some of the patch comments and thought the STREAMOFF related on may have been what you were talking about in blog post, so great that was included in this tree.
I got this snapshot built and installed today, and so far it seems very promising! I was able to give my two 950q’s a bit of a workout with mythtv and tuning does seem snappier, which is very cool. I won’t be able to finish migrating my old install until later this week, but I’ll be beating on it more then.
One interesting testing note, though – I still get the “xc5000: Device not found at addr 0x61 (0xffff)” error very reliably if I don’t use the xc5000 no_poweroff=1 option. I went through several reboots randomly changing only adding/removing that single option, and reproduced that result without fail.
I stumbled on this as I was copying my old options file from my older mythtv installation mainly to turn on logging. But I had also previously added the no_poweroff option to address some stability issues (but not the “Device not found” issue…hadn’t been affected), so that was coincidentally added with the debug logging option. I initially assumed the debug option was responsible for the fix by introduction some delays, but I elimated that and turned out to the only the no_poweroff=1 option.
Let me know if you’d like further info – would be most happy to help your efforts if possible. Again, thanks so much for the work and all the interesting posts about it that you’ve collected here. Magical stuff.
Hello Jim,
Thanks for the feedback!
Interesting that you’re still seeing the “Device not found” error when no_poweroff isn’t present. Admittedly I hadn’t tried removing no_poweroff so it’s possible I missed some edge case. I’ll be taking a look later this week. Could I get you to pastebin your dmesg output from startup when the option is removed?
Also, does this happen when you only have a single tuner installed? I’m wondering if the fact that you have two 950q tuners connected has any correlation with the problem.
Devin
Yes, glad to supply the output. I tested with 1 and two tuners, and it didn’t seem to matter.
Here the dmesg with 1 tuner attached, not using no_poweroff: http://pastebin.com/6X2umBsB
…and with two tuners attached not using no_poweroff: http://pastebin.com/g9dynQgS
And just so you don’t have to take my word for it ;), a successful initialization with 1 tuner attached with only difference using no_poweroff=1: http://pastebin.com/RqDqPTsz
…and with two tuners attached using no_poweroff=1: http://pastebin.com/hFJ31Fee
Other than this, seemed great when I was using it again for a while last night. Tuning is sped up to the point where it really doesn’t bother me vs using the built in television tuner, so that’s terrific. Great work and appreciate whatever you can figure out about this. I’ll keep an eye on this post, or feel free to email if I can supply other info. -Jim
Hi Jim,
Thanks for providing this info. Assuming I can reproduce the issue here, it should be pretty easy to debug. It only took about a half hour to debug the other race condition once I had a system setup with the appropriate kernel source (just needed to add some logging and a few dump_stack() calls).
Devin