dvbloopback driver lockups in kernel 4.3.0

[mrvanes]

I use endriss' media_build_experimental for ddbridge module and I've applied the mutex patch to 4.3.0 (but I don't think that's necessary since media_build_experimental has it's own patched dvb-core.c?). Anyway, this results in frequent lockups like other kernels before without patches.

[bas-t]

You are right, when using Endriss sources, you don't have to patch dvbdev.c

Assuming your ddbridge module (and the rest of the media stack) is installed ok, please use the stable branch of 'descrambler' for a standalone version of ffdecsawrapper userspace prog.

git clone -b stable https://github.com/bas-t/descrambler.git && cd descrambler ./configure

This repo is deprecated. View the README

[bas-t]

Oh, one more thing, if you are building endriss sources, you should add the dvbloopback module to those sources, as per: https://raw.githubusercontent.com/bas-t/dvbloopback/master/README.txt

[mrvanes]

I'd love to discard the deprecated repo, but I find the "way to go" on descrambler a bit rough on the edges, do you have a wiki explaining this route in detail? I took me a while to discover that dvbloopback you refer to is a seperate repo, which can do some magic, but I don't know if it can do endriss magic? It can also compile ffdecswrapper, but that's not in dvbloopback? How would it know about my ffdecswrapper clone, or does configure/make pull that in?

[bas-t]

Just give me some time, I'll add endriss magic to the dvbloopback repo. And yes, it pulls in descrambler, more magic... However, when I'm done, you'll be the one that alerts me if the magic stops working for you, as I cannot use endriss sources myself. It contains the wrong version of saa716x (for me that is). Agree to become my 'eyes' on that particular part of the script?

[mrvanes]

For now I just adjusted my "build_dvb" script that pulls-in and patches everything I need, since the adjustments to the endriss tree are quite straight forward (I assume I can echo "foobar" >> Kconfig to make the additions work?). I just have to check the descrambler magic tonight, because I don't see how that works If the only reason I pull dvbloopback is to copy it to media_build_experimental? Why would I still compile dvbloopback in it's own tree then? And yes, I'll let you know if something breaks ;)

[bas-t]

Well, the reason for using the new dvbloopback repo is mainly because I don't want to compile the dvbloopback module against a compiled source. I want it inside of that source tree prior to compiling it. That can save a lot of headaches! Plus, while manipulating any given source tree anyway, I can do some magic, I like that very much too. As for ffdecsawrapper being in a separate repo: that's for three reasons: one being that I can use any branch it has with any branch of dvbloopback. Second: legal issues, while dvbloopback is legal anywhere on this planet (afaik), ffdecsawrapper itself not so much. So best to keep them separated. And last, but not least: while the dvbloopback module should always be compiled with the gcc/g++ version your kernel is build with, I want to be free in my choice of compiler where it comes to the ffdecsawrapper userspace prog. That is very important to me. And needless to say, it's much simpler to do this with separate repo's.

Anyway, I missed your comment, I'm nearly done adding 'endriss magic' to the dvbloopback repo. Awell, maybe somebody else will use it, you apparently don't need it.

[bas-t]

Hi, I just discovered that the v4l branch that is downloaded by the endriss source tree, contains an obsolete version of (or gets patched in a way it should not) linux/drivers/media/Kconfig. In the section 'config MEDIA_CONTROLLER_DVB' it should state that it depends on 'BROKEN'.

But it does not. This is a 100% sure road to disaster. Just so you know. Regards, Tycho.

[mrvanes]

I did some quick tests and copied dvbloopback to endriss' tree + modified the Kconfig+ files, but didn't find a compiled dvbloopback module afterwards. I was going to ask for more help now. I'll checkout the new endriss magic in dvbloopback, or does that break also because of the previous statement?

Or short: help?!

[mrvanes]

I made a litle mistake while patching the Kconfig and Makefile before (missed /pci/) and now have a compiled dvbloopback.ko module in endriss' tree! Next step: see if it works, but due to conflicting family interrests I can't test right now ;)

[bas-t]

I get that! I'll push my testing branch (in witch the new 'endriss magic' resides) as soon as I've decided on how to handle the forementioned 'config MEDIA_CONTROLLER_DVB' anomaly. And maybe other error check failures... That'll be tomorrow, I guess. I'll keep you posted.

[bas-t]

I did not feel like pushing another branch, so I pushed the changes directly into the 'master' branch. It compiles ok, with LOTS of warnings regarding the ddbridge and saa716x modules though. I'm not going to fix those. I'm only providing the framework you need to compile the dvbloopback kernel module intree.

However, I guess that the current state of the dvbloopback repo gives you a fair chance to successfully run dvbloopback/ffdecsawrapper with your 4.3 kernel.

To test, just do:

git clone https://github.com/bas-t/dvbloopback.git && cd dvbloopback ./configure --v4l=endriss

When asked, please answer 'yes' to the question if you want to recompile ffdecsawrapper.

That's all for now, I hope that it works for you as I planned Best of luck, Tycho.

[bas-t]

Hi, I compile-tested against a 4.1 kernel yesterday, that went like I said. However, compiling endriss sources against a 4.3 or 4.4 kernel needs one or more extra patches. I'm sure you know, given: http://www.vdr-portal.de/board18-vdr-hardware/board102-dvb-karten/124665-aktuelle-treiber-f%C3%BCr-octopus-ddbridge-cines2-ngene-ddbridge-duoflex-s2-duoflex-ct-cinect-max-s8-sowie-tt-s2-6400-teil-3/index10.html

If you want, you can generate those patches and I'll apply them to my tree. They have to be like:

if LINUX_VERSION_CODE >= KERNEL_VERSION(4,2,0)

else

endif

However, again, you'll be the maintainer of such a patchset. As it is now, ufo supports linux kernels from 2.6.32 ... 4.1, as you (should) know. I'm not going to port endriss sources to newer kernels, I've got my own ports to maintain. (being the media stacks from both 3.10.93 and 3.18.24, with added drivers, just like ufo does)

[mrvanes]

Hmm... a lot of assumptions there... I used to read vdr-portal and ufo's forum but didn't feel welcome after I once mentioned I use his tree together with dvbloopback ;)

Tonight I managed to compile (I don't see the errors in adp1653 since I have a very light config only for ddbridge module and Kconfig fix was easy) and boot everything and found out the hard way that 4.3.0 + media_build_experimental + dvbloopback + descrambler are a clean path to certain lockups. I'll read up on the forum to see if it's worth upgrading to 4.3.0. It's not that things don't work, I just like to follow the mainline kernel progress.

I sure don't expect you to maintain media_build_experimental and I'm just a little lurker that now and then likes to upgrade my media center's kernel, so I'm not the right guy to do that either I guess.

[bas-t]

Hi, I sure made a lot of assumptions... Sorry about that.

[mrvanes]

Just to scratch my itch: I can make mythtv work with dddvb module from DD's git repository (no need for media_build_experimental). This brings it's own dvb-core module, which I can patch to skip mutex locks/unlocks and compile dvbloopback in the mainline kernel tree Then I need to take care DD's dvb-core module gets loaded and not the mainline and everything works! The only problem I still see is that eventually (couple of hours continuous watching) my system will lock-up hard using kernel 4.4.1, while 4.1.17 is solid as a rock for weeks in a row. I also tested using their dvb_usercopy since they export it in dvb-core, no difference. Need to test 4.1.17 with DD's dddvb module before drawing more conclusions.

I'm curious if you can make dvbloopback work with anything above and including 4.2.x?

[bas-t]

dvbloopback kernel module is in fact working with 4.4.1, that's an absolute positive.

[bas-t]

You may want to know: I moved to tvheadend/kodi a couple of weeks ago. That means I don't need dvbloopback/ffdecsawrapper anymore. Botomline: I'm not going to adderess any issues involving dvbloopback/ffdecsawrapper anymore. I'm addressing tvheadend/kodi issues now.

[mrvanes]

What combination of dvb-core and dvb_usercopy are/were you using in 4.4.1? I don't understand why you wouldn't need dvbloopback when you're using tvheadend/kodi. You still need to decrypt the mpg stream? Or are you using a HW CAM now? Anyway, thanks for all the work you did for dvbloopback, it's in a good shape as far as I'm concerned.

[bas-t]

I was using the default (patched) 4.4.1 dvb-core and dvb_usercopy. Tvheadend has ffdecsa built-in, so that's why I don't need dvbloopback and ffdecsawrapper anymore. The fact that tvheadend does it all by itself (well, it still needs oscam) is probably due to it being an European product, and we don't tend to conform to 'hollywood legislation' about alleged 'piracy' over here, as you might know...

[mrvanes]

Yup, I'm Dutch too. Thanks for explaining, I'll try to compile dddvb using 4.4.1's dvb-core and usercopy later, need to work out how to rip dvb-core out of their source first.

Btw, I have been curious for a long time why dvbloopback needs the mutex locks removed, I don't understand how correctly setting and removing a lock can obstruct dvbloopback's job? My intuition even feels against doing so?

[bas-t]

the locks are in dvb_device_open() and that's exactly where the communication (file ops) between the normal and the loopback interface happens. leaving it locked prevents all of that.

[bas-t]

The key words are: shared access The locks are intended to prevent just that.

[mrvanes]

ddbridge without included dvb-core was no option, managed to compile dvbloopback in ddbridge tree against that dvb-core, but that eventually results in a hard lock-up again. I'm done trying. Have no idea what to try next.

[bas-t]

Well, I remember having written a patch to ufo's media_tree in order to keep it compiling against 4.4.x Can't for the love of god remember why I did that, I don't own any DD hardware. I guess that patch could be an option (if you really need to run 4.4.x) Another option would be: take your loss and buy a couple of linux (mainstream) supported dvb adapters and move to tvheadend/kodi. It'd cost you some, but I guess that you'll be much more happy in the long run... BTW, if you own a motherboard that has sufficient PCI slots for your needs (as opposed to PCIe) I can supply you with those dvb-c adapters. Assuming that you use that kind. They are well supported as of linux 2.?.x

[mrvanes]

LIke I said it's no problem to keep using 4.1.x for now, it's stable and still supported. It's just frustrating I can't get is stable under 4.2 or higher (it's not a compilation problem, it locks-up after watching a while). The reason I use DD hardware is they're one of the few manufacturers that make dual DVB-C tuners on single PCIe card. I have a low-profile HTPC case that only supports one lying PCI(e) adapter...

[bas-t]

Maybe this is something for you: http://www.bettershopping.eu/de_US/shop/PC_Hardware/TV_Karten_Boxen/DVB-C_Kabel/ART01735_DVBSky_PCIe_DVB-C_T_T2_FTA_Twin_T982_CD.html

It works quite well from 4.1.x onward, I've got a couple of those myself, so I know they're good. Only drawback: no internal splitter, so you have to connect two separate coax cables to the input connectors. Nevertheless, I'd recommend those cards.

[mrvanes]

I have one of those lying around as a spare card in case ddbridge would give me too much headache! Good to hear it's supported on Linux! Haven't had the time to investigate.

[mrvanes]

Just for the sake of documentation, in case somebody would stumble accross this discussion.

I finally made it work for 4.4.1. There seemed to be one combination I hadn't tried, or messed up while testing:

• No media selection in mainline kernel
• Build inline dvbloopback in media_build_experimental tree, use dvb_usercopy

Too bad I can't make it work with a clean ddbridge clone, but hey, I've got 4.4.1 working! :)

[bas-t]

IMO this is a very poor job when it's ment to document the sequence of steps you went through to make it work for you.

Please write a full log of whatever you did, pastebin it somewhere and publish it's whereabouts here.

[mrvanes]

You're right and I will, but for now I'm back at 4.1.18 because the 4.4.1 setup failed again, but now only after a day.

[bas-t]

Bugger, cheers anyway.

[mrvanes]

In case you're interrested, I've found the source of my problems (and fix/workaround): https://bugzilla.kernel.org/show_bug.cgi?id=109051#c279

How's that for something unexpected!?

[bas-t]

I'll look at this sometime soon.

[bas-t]

I'm not interested. I don't use FFdecsawrapper anymore and I'm using nvidia hardware on all of my frontends.

Op 02-05-16 om 19:24 schreef Martin:

In case you're interrested, I've found the source of my problems (and fix/workaround): https://bugzilla.kernel.org/show_bug.cgi?id=109051#c279

How's that for something unexpected!?

— You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub https://github.com/bas-t/ffdecsawrapper/issues/47#issuecomment-216301745