| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| pentarex | hey guys do you know if you can stream dvb-t with nginx | [09:53] |
| *** | pentarex has quit IRC (Quit: pentarex) | [09:53] |
| ........................................................................ (idle for 5h55mn) | ||
| ParkerR_ | I'm having a weird issue with xc5000. On kernel 3.18.6-1-ARCH the firmware does not seem to unload after exiting a viewer (VLC playing ATSC channels). This then causes a kernel panic when I unplug my DVB adapter. I tried unloading via rmmod but it won't unload xc5000 due to it being in use. I don't remember this behavior on earlier kernel versions. Has anybody else run into this? (I saw the panic in
journalctl once but havent been able to capture it again) It's using the latest xc5000 firmware dvb-fe-xc5000-1.6.114.fw | [15:48] |
| ............... (idle for 1h14mn) | ||
| pentarex | guys anyone here? | [17:06] |
| ParkerR_ | Maybe | [17:06] |
| devinheitmueller | ParkerR_: Are you using the HVR_950q? | [17:07] |
| ParkerR_ | devinheitmueller: 850 but yes
Very similar hardware | [17:15] |
| devinheitmueller | Yes, I am famiilar with it (I wrote the driver)
The panic is a known regression introduced in a recent kernel. Pardon, it's an oops, not a panic. | [17:16] |
| ParkerR_ | Ahh good to know | [17:16] |
| devinheitmueller | I wrote a patch, but haven't had a chance to submit it upstream yet.
A pretty nasty double-free condition that took several hours to chase down. Thanks Shuah. :-) | [17:16] |
| ParkerR_ | Heh
Glad it got indentified | [17:17] |
| devinheitmueller | Gotta love those "corrupts random memory so something in the future will crash and burn giving you no idea where the corruption came from" | [17:18] |
| ParkerR_ | devinheitmueller: Is the patch in the upstream linuxtv sources yet? | [17:18] |
| devinheitmueller | No. | [17:18] |
| ParkerR_ | Ahh | [17:18] |
| devinheitmueller | I have it here in a local tree but haven't submitted it. | [17:18] |
| ParkerR_ | Wasnt sure if you mean mainline linux or the linuxtv sources
*meant | [17:18] |
| devinheitmueller | In this case, neither. | [17:18] |
| ParkerR_ | Cool
devinheitmueller: is there any workaround in the meantimes? (Not big enough of an issue that I feel like compiling my own kernel) *meantime | [17:18] |
| shuah | devinheitmueller: something introduced in au0828 ? | [17:19] |
| devinheitmueller | Don't unplug the device. :-) | [17:19] |
| ParkerR_ | :D | [17:19] |
| devinheitmueller | shuah: No it was some changes you made to xc5000.
Let me boot my laptop and I'll send the patch to the ML now. | [17:20] |
| ParkerR_ | Woo you might make the 4.0 kernel! (I love Linus) | [17:20] |
| devinheitmueller | ParkerR_: in this case, it really should be backported to linux-stable as well. | [17:21] |
| shuah | those changes have been in for a sometime. | [17:21] |
| devinheitmueller | Yeah, it's been broken for a few months. Pretty surprised you didn't hit it. Don't you ever unplug your 950q? | [17:21] |
| ParkerR_ | https://plus.google.com/+LinusTorvalds/posts/jmtzzLiiejc | [17:21] |
| shuah | devinheitmueller: I unplug it routinely - I wonder if you are missing a patch that fixed the problem
shuah will wait for your patch :) | [17:22] |
| ParkerR_ | devinheitmueller: I unplug it so often because my area has crap ATSC reception and I use it with my laptop :P | [17:25] |
| shuah | devinheitmueller: curious do you have this commit - 4961a5323f5d873e2170c5ef4f48538930e6df3e | [17:25] |
| ParkerR_ | So I pick up a channel (barely) watch for a little bit then move onto other things | [17:25] |
| devinheitmueller | shuah: You're in the right area. Yes, I do have that commit. One sec. | [17:27] |
| shuah | hmm. there is another commit that went in after that - dc89cfcf33bfd15ad335207062c1f87b6074f222
This changes the same path | [17:29] |
| devinheitmueller | sent. | [17:30] |
| shuah | ok
devinheitmueller: ok please take a look at this commit - dc89cfcf33bfd15ad335207062c1f87b6074f222 | [17:30] |
| ParkerR_ | Well whatever devinheitmueller found is affecting me in 3.18. Are those commits before or after? | [17:32] |
| shuah | the above commit removes the priv->firmware check prior to calling release_firmware(priv->firmware); | [17:32] |
| devinheitmueller | That won't help, although I guess that patch could be rewritten to always call release_firmware() and then always set priv->firmware = NULL. | [17:32] |
| ParkerR_ | Aha Dec 7 for 3.18 | [17:33] |
| devinheitmueller | Oh I love useless cleanup changes that require patches to be rebased. | [17:33] |
| ParkerR_ | That commit on the 5th
Maybe it didn't make it? | [17:33] |
| devinheitmueller | ParkerR_: that patch Shuah is referring to won't fix the problem. | [17:33] |
| ParkerR_ | Ahh | [17:34] |
| devinheitmueller | It is just a minor cleanup which will result in my patch not applying cleanly. | [17:34] |
| ParkerR_ | devinheitmueller: Have a link to your submitted patch? | [17:34] |
| shuah | I do think the commit dc89cfcf33bfd15ad335207062c1f87b6074f222 is causing the issue. Yes priv->firmware = NULL doesn't hurt, but if you notice hybrid_tuner_release_state(priv); which releases priv right after that | [17:34] |
| devinheitmueller | It was just sent to linux-media | [17:34] |
| shuah | devinheitmueller: which one the commit 4961a5323f5d873e2170c5ef4f48538930e6df3e does fix the double free problem though | [17:35] |
| devinheitmueller | shuah, I think you're missing the point. The issue is that xc5000_release gets called twice on hybrid devices. hybrid_tuner_release_state() is not expected for priv to always be freed. | [17:35] |
| shuah | devinheitmueller: what I am saying is that you are really undoing dc89cfcf33bfd15ad335207062c1f87b6074f222 and the adding priv->firmware = NULL in your patch - isn't that the case? | [17:37] |
| devinheitmueller | shuah: 4961a5323f5d873e2170c5ef4f48538930e6df3e fixes a use-after-free condition.
dc89cfcf33bfd15ad335207062c1f87b6074f222 just removes an if under the assumption that you don't need to check for a NULL. That said, priv->firmware needs to be *set* to NULL so that the second call in to xc5000_release() doesn't call release_firmware() with a garbage pointer referring to the already-freed memory. The key change is setting priv->firmware to NULL. The fact that I only do it when it's not already NULL is just a patch conflict. | [17:38] |
| shuah | right 4961a5323f5d873e2170c5ef4f48538930e6df3e fixes the use-after free case
Right I see what you are saying. thanks for finding it | [17:40] |
| devinheitmueller | cancel_delayed_work(&priv->timer_sleep);
release_firmware(priv->firmware); hybrid_tuner_release_state(priv); doh, typo. | [17:41] |
| shuah | right I think not checking made things worse with dc89cfcf33bfd15ad335207062c1f87b6074f222 :) Good now that the root-cause is fixed | [17:42] |
| devinheitmueller | Anyway, I can rebase it if Mauro complains, or he can just do it when he merges it (since it's a trivial fix).
.... I've already spent ten minutes too long talking about this problem than I have available. :-) | [17:42] |
| ParkerR_ | Heh | [17:44] |
| shuah | oh well :) | [17:44] |
| devinheitmueller | Ok, back to work. ParkerR_: if you can't figure out how to apply that patch, ping me again. Good luck! | [17:47] |
| ParkerR_ | I think I could manage the patch it's just compiling it that might be trickier. Short of compiling a whole new kernel... wonder if I could do it with the linuxtv build script | [17:49] |
| devinheitmueller | You should be able to just install the media_build tree, rather than the entire kernel.
ls | [17:49] |
| ParkerR_ | Disclaimer: Advanced-ish linux user that hasn't really delved into programming/kernel compiling past localmodconfig
:) | [17:50] |
| devinheitmueller | http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers#Retrieving_and_Building.2FCompiling_the_Latest_V4L-DVB_Source_Code | [17:51] |
| ParkerR_ | Yeah thats the linuxtv build script I was thinking of
:D Ive only used it on debian forever ago. Should it work on Arch just fine +? Aha developer approach sound like what I need Only having to modify one driver *sounds devinheitmueller: thanks for the pointer | [17:52] |
| devinheitmueller | np | [17:58] |
| ..... (idle for 24mn) | ||
| ParkerR_ | devinheitmueller: "File not found: /lib/modules/3.18.6-1-ARCH/build/.config at ./scripts/make_kconfig.pl line 33, <IN> line 4" All I have in that build folder is vmlinux | [18:22] |
| devinheitmueller | ParkerR_: you probably don't have the linux-headers package installed (or whatever it's called on arch) | [18:23] |
| ParkerR_ | devinheitmueller: derp I did not. Thanks | [18:23] |
| *** | devinheitmueller has quit IRC (Quit: devinheitmueller) | [18:35] |
| ............. (idle for 1h4mn) | ||
| mrec | devinheitmueller: do you know the power consumption of those ATSC devices? | [19:39] |
| devinheitmueller | Which ATSC devices?
I do take measurements, but they obviously vary by device. | [19:39] |
| mrec | hauppauge 950/850? | [19:39] |
| devinheitmueller | Hmm.... | [19:41] |
| mrec | we're at 290mA for AnalogTV with our new devices, ATSC is more 320-350 I think; Standby is 50mA; S-Video/Composite 190mA | [19:41] |
| devinheitmueller | Let me look.
The xc5000 runs pretty hot. The new HVR-955q does a good bit better I suspect. | [19:41] |
| mrec | I wonder that anyone is still using xceive I guess that product just fades out completely now | [19:42] |
| devinheitmueller | I don't think anyone is using it in new designs.
And it can no longer be sold in the US as a result of a patent issue. | [19:42] |
| mrec | what patent? | [19:43] |
| devinheitmueller | There was a lawsuit between Silicon Labs and Xceive. All public record, so you can Google it. | [19:43] |
| mrec | I wonder how hauppauge is doing, their financial report was very negative a few years ago | [19:45] |
| devinheitmueller | Not too good, I imagine.
I can't find my notes, but I think the 950q drew somewhere around 420ma in both digital and analog mode. | [19:45] |
| mrec | we've been at 510mA before modifying our device, now it's quite nice | [19:47] |
| devinheitmueller | 190ma for CVBS is pretty good. Are you still on Empia, or have you moved to Polaris? | [19:47] |
| mrec | we split up with Empia 2 years ago, letting them die alone | [19:48] |
| devinheitmueller | :-) | [19:48] |
| mrec | we're using various chipsets now and even assemble by ourselves | [19:48] |
| devinheitmueller | Nice.
I assumed you had just gone with an ODM. | [19:48] |
| mrec | we have our own assembly line nowadays | [19:49] |
| devinheitmueller | Makes sense. Certainly gives you more control over the process. | [19:49] |
| mrec | due to the small volume outsourcing is not such a good idea | [19:49] |
| awalls | awalls only ever does small volume prototypes. Always expensive. :( | [19:50] |
| mrec | we hand pick and placed the first prototypes
6 hours per device and another 6 hours for debugging in the worst case | [19:50] |
| awalls | Ugh. SMT components are so small. You can sneeze and they'll blow away like dust. | [19:51] |
| mrec | SMT line is quite expensive, but once we had it it was worth it | [19:51] |
| awalls | Yes.
Very nice form factors. | [19:51] |
| devinheitmuell-1 | Sorry, internet dropped out. | [19:52] |
| mrec | I recently added support for settopboxes to our units
http://sundtek.de/images/atsc_scanning_small.jpg the driver translates the ATSC transport stream to DVB-T | [19:53] |
| devinheitmuell-1 | Yeah, we've done some work with some ODMs with MOQ of 500, but indeed getting good volume pricing as well as timely builds is a challenge. | [19:53] |
| mrec | so the settopbox image won't need to be modified | [19:53] |
| *** | devinheitmueller has quit IRC (Quit: devinheitmueller) | [19:53] |
| devinheitmuell-1 | Hmm, so is this screenshot of a STB that already has DVB-T support, and you've tweaked the driver to treat ATSC as DVB? | [19:54] |
| mrec | rewriting the ATSC tables to DVB-T yes
http://sundtek.de/images/wxia_tv.jpg | [19:54] |
| devinheitmuell-1 | That's a neat idea. Does DVB-T support AC-3 audio though? | [19:54] |
| mrec | yes
since ATSC doesn't have a provider name, time to put our name into it hah | [19:54] |
| devinheitmuell-1 | Hmm, I didn't realize that. Assumed DVB-T only supported MP2, AAC, EAAC, etc. | [19:55] |
| mrec | in Europe some countries also put h264 inside the transport streams
however DVB-T is dead 2016 or 17 Germany will shut down DVB-T | [19:55] |
| devinheitmuell-1 | Right. That said, I didn't think anybody making DVB-T hardware was prepared to pay the Dolby royalty. | [19:56] |
| mrec | they don't need to pay the dolby royalty
as long as they don't provide a software with their tuners whatever is inside the transport stream that has nothing to do with the hardware manufacturers, they have to pay the DVB-T royalty fee | [19:56] |
| devinheitmuell-1 | Ah, had assumed the patent portfolio covered Europe as well.
RIght, but I assumed the DVB-T royalty didn't include an AC-3 license. Hence the hardware manufacturer would have ot pay the royalty for the decoder. | [19:58] |
| mrec | it does not, so if you don't support it with the software no one cares | [19:59] |
| devinheitmuell-1 | Gotcha. | [19:59] |
| mrec | I figured out no one cares if the volume is too small anyway
not worth the effort even mid size companies are violating several licenses in Europe, no one cares because there's just no money in it | [19:59] |
| devinheitmuell-1 | Oh I don't doubt it. There's the law and then there's actual enforcement. | [20:01] |
| mrec | hauppauge and those ones entered at the beginning where everyone was watching them
not really in Europe. Even the disposal rule, the government does not care about small fishes competitors might stand up, but I haven't seen any competitor doing something against another one | [20:01] |
| devinheitmuell-1 | I was less concerned about criminal enforcement than civil litigation.
(i.e. Dolby suing the hardware manufacturer) | [20:02] |
| mrec | if they make dolby accessible
just don't ship any codecs and you're fine with it DVBViewer is doing it that way and they tried to sue DVBViewer because those guys have many customers | [20:03] |
| devinheitmuell-1 | Sure, for software codecs I can totally see that. | [20:04] |
| mrec | DVB-T has nothing to do with Dolby to my understanding
whatever is inside the transport stream is not part of the DVB-T license | [20:05] |
| devinheitmuell-1 | Hmmm, perhaps you've misunderstood my point. Dolby owns the patents on AC-3. Anything with an AC-3 decoder has to pay a royalty to Dolby. Hence if a certain DVB-T settop box had the ability to play AC-3 content would be responsible for a royalty. That's why many STBs don't support AC-3 decoding at all. | [20:06] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
