dvbloopback: Unknown symbol dvb_usercopy (err 0)

[Erik-NA]

Just updated both kernel and the TBS DVB S2 card v4l driver for TBS 6984 (http://www.tbsdtv.com/download/document/common/linux-tbs-drivers_150130.tar.bz2) patched with the linux-2.6.38-dvb-mutex patch.
When starting a fresh compiled (and github synced version) of ffdecsawrapper, the following error is displayed: " ERROR: could not insert 'dvbloopback': Unknown symbol in module, or unknown parameter (see dmesg)". Dmesg output: "dvbloopback: Unknown symbol dvb_usercopy (err 0)"
Running on Mythbuntu 14.04 using kernel 3.13.0-46-generic

[bas-t]

If you are using a 3.13 or up kernel, you need the newest kernel patch, that goes for v4l based sources too, no matter how old they are.
You may have to adjust it a bit, TBS official drivers use a v4l media_tree from the stone age.
An up-to-date version of the patch you need is here:
https://raw.githubusercontent.com/bas-t/ffdecsawrapper/master/linux-3.13-dvb-mutex.patch
The culprit lies in the last hunk: EXPORT_SYMBOL(dvb_usercopy);
Please report back.

Kind regards,
Tycho.

[mhlund]

I just updated my Ubuntu 14.10 to kernel 3.16.0-31-generic and have the same problem getting ffdecsawrapper to run. The configure script with kernel patching went ok, but when the startup script tries to load the dvbloopback module dmesg outputs "dvbloopback: no symbol version for dvb_usercopy" and then "dvbloopback: Unknown symbol dvb_usercopy (err -22)"

I think I have the latest kernel patch, included when pulling from the git repository..
My script for fixing ffdecsawrapper after installing new kernel looks like this:

rm -r ffdecsawrapper.old
mv ffdecsawrapper ffdecsawrapper.old
git clone https://github.com/bas-t/ffdecsawrapper.git
cd ffdecsawrapper
./configure

Regards,
Magnus

[bas-t]

Hi Magnus,
though the latest patch is included in my repo, it does not mean that you patched officiial TBS sources.
As in: patch whatever driver source you are using.
My configure script does not do that. It can patch a stock kernel for Debian/Ubuntu.
So, if your DVB adapters are supported by the (stock) kernel you use, you should be OK.
However, when you are using a out of kernel media stack, like official TBS drivers or Luis Alves opensourced TBS drivers,, you'll have to patch that media stack.

The ability to omit the internal 'dvb_usercopy' was introduced in FFdecsawrapper in 2d0afc3

But I hesitated to actually make it effective. So now I did. The patch exports 'dvb_usercopy' , so we should not need an internal copy anymore.
I compiled it without the internal usercopy, testing against Debian/Ubuntu 3.16 and vanilla 4.0-rc1. No propblems whatsoever, as far as FFdecsawrapper is concerned.

Well, as I announced, I can not test a minor part of the functionality anymore: decryption.
But you guys can do that for me, so please use proper patch and report back!

[bas-t]

@Erik-NA : your patch should look like this
http://pastebin.com/RUJB36xm

You'll have to find th proper arguement, like patch -p0 or p1 etc.

[Erik-NA]

It does not work. FFdecsawrapper starts, and also MythTV. But when checking status in MythWeb it says "Unable to connect to the master backend at 192.168.0.10:6543. Is it running?" which it normally does when ffdecsawrapper is not working.
Cannot find any clue in either ffdecsawrapper.log or MythTvbackend.log.

[Erik-NA]

I also made my own patch, which turned out to be exactly as yours.

[mhlund]

Hi!

I'm using a stock ubuntu kernel and have been running ffdecsawrapper successfully for at least a couple of years... The last successful kernel was 3.16.0-28-generic that I've been running since dec 21. Today I rebooted my mythtv-backend server with the new kernel 3.16.0-31-generic that I received with apt-get dist-upgrade the other day...

I then initiated the normal procedure, updating ffdecsawrapper (including the kernel patching) as described in my last post... It has always worked perfectly and I was surprised that it did'nt today...

Something must have happened in either the ffdecsawrapper codebase or the stock ubuntu kernel since december... I'll keep trying to find out what's wrong, but I wanted to give you some more information about my problems..

[bas-t]

@mhlund : is your DVB adapter supported by your kernel?
If not, what drivers are you using? And if so, are they v4l based?

@Erik-NA : please pastebin the output of dmesg

[mhlund]

Some information about my DVB-adapter from dmesg output...

[ 39.020618] cx88[0]: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [card=69,autodetected], frontend(s): 1
...
...
[ 39.229283] tveeprom 0-0050: Hauppauge model 69100, rev B4C3, serial# 7959059
[ 39.229287] tveeprom 0-0050: MAC address is 00:0d:fe:79:72:13
[ 39.229290] tveeprom 0-0050: tuner model is Conexant CX24118A (idx 123, type 4)
[ 39.229292] tveeprom 0-0050: TV standards ATSC/DVB Digital (eeprom 0x80)
[ 39.229294] tveeprom 0-0050: audio processor is None (idx 0)
[ 39.229296] tveeprom 0-0050: decoder processor is CX880 (idx 20)
[ 39.229298] tveeprom 0-0050: has no radio, has IR receiver, has no IR transmitter
[ 39.229300] cx88[0]: hauppauge eeprom: model=69100
[ 39.260013] Registered IR keymap rc-hauppauge
[ 39.260154] input: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci0000:00/0000:00:1e.0/0000:05:02.2/rc/rc0/input13
[ 39.260274] rc0: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci0000:00/0000:00:1e.0/0000:05:02.2/rc/rc0
[ 39.265654] IR NEC protocol handler initialized
[ 39.270853] IR RC5(x) protocol handler initialized
[ 39.276002] IR RC6 protocol handler initialized
[ 39.285709] IR JVC protocol handler initialized
[ 39.286199] IR Sony protocol handler initialized
[ 39.291446] IR SANYO protocol handler initialized
[ 39.296976] IR Sharp protocol handler initialized
[ 39.301277] IR MCE Keyboard/mouse protocol handler initialized
[ 39.307059] lirc_dev: IR Remote Control driver registered, major 249
[ 39.308131] input: MCE IR Keyboard/Mouse (cx88xx) as /devices/virtual/input/input14
[ 39.308282] cx88[0]/2: cx2388x 8802 Driver Manager
[ 39.308368] cx88[0]/2: found at 0000:05:02.2, rev: 5, irq: 18, latency: 64, mmio: 0xfc000000
[ 39.308522] cx88[0]/0: found at 0000:05:02.0, rev: 5, irq: 18, latency: 64, mmio: 0xfa000000
[ 39.308816] cx88[0]/0: registered device video0 [v4l2]
[ 39.308885] cx88[0]/0: registered device vbi0
[ 39.309016] cx88[0]/1: CX88x/0: ALSA support for cx2388x boards
...
....
[ 39.741945] cx88/2: cx2388x dvb driver version 0.0.9 loaded
[ 39.741949] cx88/2: registering cx8802 driver, type: dvb access: shared
[ 39.741952] cx88[0]/2: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [card=69]
[ 39.741954] cx88[0]/2: cx2388x based DVB/ATSC card
[ 39.741955] cx8802_alloc_frontends() allocating 1 frontend(s)
[ 39.754369] DVB: registering new adapter (cx88[0])
[ 39.754375] cx88-mpeg driver manager 0000:05:02.2: DVB: registering adapter 0 frontend 0 (Conexant CX24116/CX24118)...

/Magnus

[bas-t]

@mhlund : that's not an answer to my question

[mhlund]

I'm using the stock Ubuntu kernel in 14.10 and my card is supported in it.

... or maybe I don't understand your question?

[Erik-NA]

Dmesg output:
[ 222.399499] /usr/src/ffdecsawrapper/dvbloopback/module/dvb_loopback.c: Unregi stering ca loopback devices
[ 222.403295] removing dvblb proc adapter
[ 222.403298] dvblb init = 100
[ 222.403501] removing dvblb proc adapter
[ 222.403503] dvblb init = 100
[ 222.403704] removing dvblb proc adapter
[ 222.403706] dvblb init = 100
[ 222.403887] removing dvblb proc adapter
[ 222.403888] dvblb init = 100
[ 307.701922] dvbloopback: registering 4 adapters
[ 307.701968] DVB: registering new adapter (DVB-LOOPBACK)
[ 307.702435] DVB: registering new adapter (DVB-LOOPBACK)
[ 307.702933] DVB: registering new adapter (DVB-LOOPBACK)
[ 307.703378] DVB: registering new adapter (DVB-LOOPBACK)

[bas-t]

@mhlund well, if you don't have to compile out of kernel drivers, I guess this is clear. I'll think of any thinko I've maybe made with latest patches. While I'm at it , you should be fine using the stable branch.
So: git clone https://github.com/bas-t/ffdecsawrapper.git -b stable

@Erik-NA : shouldn't it show some firmware loading? Please also try the stable branch and pastebin the output of dmesg again.

[mhlund]

@bas-t Yep! That worked! Thanks!

[Erik-NA]

Ffdecsawrapper stable branch is working with the TBS-patch above!

[bas-t]

Hmm.. it should work with latest patches on master branch.
I don't know why it does not for you guys yet, I'll think about it.

Meanwhile: why does it work on all of my tests?
I'm obviously missing some clue.

[Erik-NA]

Have tested again with trunk and mythTv will not start. No clues is displayed in dmesg either.
Using the stable bransch I am experiencing a bit more stuttering compared to earlier. However, it is hard to say where the stuttering come from, it could be MythTv backend or frontend, it must not be from ffdecsawrapper.

[bas-t]

Huh? more stuttering? So you had stuttering before, that should not happen at all. But you are right, it is not a FFdecsawrapper issue.
Stable branch is exactly like master, only without the usercopy patches. So switching to stable branch can absolutely not cause (increased) stuttering
Mythbuntu on the other hand can... (and has more issues)
That's why I always compile MythTV from source.
Maybe myth not starting when using FFdecsawrapper's master branch is a (myth)buntu package issue. That would explain why the both of you are hit by this issue.

[mhlund]

Well, I don't think it's an issue with how mythbuntu packages mythtv that gives me the following errors when ffdecsawrapper tries to load the dvbloopback module into the kernel.

dvbloopback: no symbol version for dvb_usercopy
dvbloopback: Unknown symbol dvb_usercopy (err -22)

Mythbuntus kernel is the same as the ubuntu stock kernel so if there is a problem with the kernel in ubuntu it should be the same for all the different versions of *buntu...

I'm still trying to figure out what makes the stable branch work but not the master...

[bas-t]

@mhlund No, mythtv packaging is indeed not the cause of this error.
The error is caused by dvb_usercopy that is not exported.
You don't have

EXPORT_SYMBOL(dvb_usercopy);

in dvbdev.c (or it is misplaced, malformed or something)
So obviously your kernel is not patched correctly.
Maybe I can fix this in the scripts, when I have time...

It's the stuttering (and other issues I don't remember anymore) that are related to mythtv packaging. Mind you, mythtv packaging on Debian is even worse...

[Erik-NA]

Question: The mutex patch for 3.13 kernel differs from the 2.6.38 patch. Is this a consequence of changes in ffdecsawrapper?

[bas-t]

There is no such patch anymore, I don't support 2.x series kernels anymore.
However, any change in these mutex patches is only related to changes in the kernels. So not related to FFdecsawrapper

[bas-t]

Well, that was only partial true.
It's true that the mutex patches depend on the development of dvbdev.c.
On the other hand, I was not at all happy with the patch as it was in the first place. So I've been surching for a way to improve it. Then I stumbled upon a nice piece of code, written by Oliver Endriss, and I imported it. Since I don't want to test all 3.x kernel series < 3.13 again, I did not change those earlier patches. As far as I'm concerned, even 3.13 kernel is old. While the previous patch format sucks, it worked for those older kernels.

[bas-t]

Anyhow, Unknown symbol dvb_usercopy (err 0) is just a matter of using proper patch.
Mythtv not starting is not a FFdecsawrapper issue, moreover: I cannot reproduce this, so I'm closing this ticket now.

[mhlund]

I agree, but as the patch is included in this distribution and the configure script claims to patch the kernel I think it indeed is an issue in the FFdecsawrapper code if the correct patch is not used in the process...

[bas-t]

@mhlund : as I stated, I'll try to find some time to review the kernel patching routine, it might need some updates.

[bas-t]

@mhlund : dit you recieve the following message at the end of the ./configure process:

'Your kernel is properly patched. You should reboot your machine now.'

[bas-t]

@mhlund : second question, what gets downloaded when you do:

apt-get source linux-image-uname -r

Hmm, damned markdown: the uname -r part should be surounded by backticks.

[bas-t]

@mhlund :I found the cause. Though the kernel gets the right patch, it does not change Module.symvers file.
That's where FFdecsawrappers dvbloopback module gets the exported symbols from.
I'll see if I can change this without screwing things up.

[bas-t]

@mhlund : please test again, should be fixed now.

[mhlund]

@bas-t As far as I can see now it works after your latest patch... My kernel was already patched with the stable branch, but everything compiled ok, the modules were replaced in /lib/modules, and loaded after reboot.

Thanks! :)

[bas-t]

You are welcome!

[Erik-NA]

Today I reinstalled using kernel 3.16.0-31-generic. Imported my old mythtvdatabase, compiled the TBS driver with the new patch and ffdecsawrapper master bransch. MythTV will not start. No error in dmesg. FFdecsawrapper log says:

Mar  5 22:18:56.605 dvr: Starting thread on /dev/dvb/adapter7/dvr1
The thread scheduling parameters indicate:
policy = 0
priority = 0
Mar  5 22:18:56.605 : Listening on port 5456
sched_setscheduler: Operation not permitted
Mar  5 22:20:52.589 CAM(core.net): idle timeout, disconnected localhost:15000

I also removed the capture cards in the database and found out that Mythtvbackend setup freezes when configuring a new capture card, at the moment when I select the dvb loopback adapter.

I cannot swear that this is related to the TBS driver or ffdecsawrapper because of my reinstallation, but I'm starting to run out of clues now ...

[bas-t]

@Erik-NA
But I can swear that MythTv not starting is not FFdecsawrapper related.
You're not the only user that gets confused by the 'sched_setscheduler: Operation not permitted' log message. It just means that the user that is running MythTV is not allowed to do realtime prio mods at runtime, which is a good thing.
I think I'll remove it from normal log operations.

[Erik-NA]

Then, It can be related to the TBS driver and probably something related to the changes in the kernel in combination with the new Mutex patch?
I also tried the open source driver for TBS, https://github.com/ljalves/linux_media/wiki/Installating. It yields about the EXPORT_SYMBOL(dvb_usercopy) thing. After fixing that I ran into a bunch of other symbol issues when starting ffdecsawrapper. And I am not sure of if the source must be updated with the Mutex patch. The code in dvbdev.c is also very different compared to the TBS driver version.

[bas-t]

@Erik-NA Just to rule out the mostly bogus closed source drivers from official tbs site, you could try the open source version from Luis Alves. That should work. But it still leaves you with the mythbuntu issues. However, you choose to run mythbuntu, so deal with it.

[bas-t]

Proper procedure is here:
http://www.lursen.org/wiki/V4l_and_ffdecsawrapper#v4l.2C_Luis_Alves_.28opensource_TBS.29_edition

But start with a clean kernel.
You need firmware:
https://github.com/ljalves/linux_media/wiki/CX24117-firmware

[bas-t]

@Erik-NA
"After fixing that I ran into a bunch of other symbol issues when starting ffdecsawrapper"

I've been able to reproduce this just now. I did not yet investigate the cause, but I will.

[Erik-NA]

Cannot thank you enough! My family is not happy currently...either am I.

[Erik-NA]

Tested again with TBS drivers and ffdecsawrapper master branch. MythTv does not start, however:
Using ffdecsawrapper: "scan -a4 -s0 -o zap /usr/share/dvb/dvb-s/Thor-1.0W" does not output any channels
Using dvbcard without ffdecsawrapper: "scan -a0 -s0 -o zap /usr/share/dvb/dvb-s/Thor-1.0W" outputs a lot of channels

[bas-t]

Upstream changes in the v4l media tree bring quite a few problems. From the looks of it, I've to completely revise the dvbloopback module to address these issues. But I don't use FFdecsawrapper myself anymore, so somone else will have to do that.

However, you can try to build your driver in-tree. I coded support for it for a guy named Wessel, it is not tested yet. But I guess it will work. The configure script is written for Debian, so it should work for Ubuntu.

Do (as root):

git clone https://github.com/bas-t/saa716x-intree.git -b wessel && cd saa716x-intree
./configure --vanilla=3.19

This builds a patched vanilla 3.19 kernel, with a couple of TBS driver modules in the kernel tree. TBS 6984 is supported. It also installs any missing build deps.
When done, power off your machine completely for a minute or so and boot your machine with the new kernel. Go to your ffdecsawrapper dir and just run ./configure.

Hope it works for you.

[tnystuen]

I have some comments to this. They may or may not be relevant.

I have a TBS6680 adapter. I am running Debian Wheezy, and I am compiling my own kernel from www.kernel.org.

At the moment, I think my only option for the kernel modules is using http://www.tbsdtv.com/download/document/common/linux-tbs-drivers_150130.tar.bz2

I first tested with kernel 3.14.35. Patched the TBS source with the v4l.patch from http://www.lursen.org/wiki/V4l_and_ffdecsawrapper#v4l

When compiling ffdecsawrapper (from master) everything seems OK, but mythtvbackup seems to lock up. Mythfrontend cannot contact the backend. I am unable to stop mythbackend without using 'kill -9'.

By trying different commits, I found that fcf186c is the last commit that works (some tips for anyone trying this: git checkout fcf186c and then ./configure --update=no).

11c4899 gives a compile error, 43120a0 compiles OK, but does not work.

I also tested with kernel 3.19.1. To compile the TBS source I had to use this patch:

sed -i "s/f_dentry/f_path\.dentry/g" linux/drivers/media/rc/lirc_dev.c

See: https://bitbucket.org/CrazyCat/linux-tbs-drivers/issue/25/build-error-with-kernel-319-error-struct

I still had to use commit fcf186c to get it working. I also tested the stable branch, without luck.

Hope this can be of some help to someone.