bas-t / ffdecsawrapper

FFdecsa empowered softcam for MythTV
GNU General Public License v3.0
17 stars 9 forks source link

hdhomerun driver screws dvbloopback module #41

Closed tschork closed 9 years ago

tschork commented 9 years ago

Hello,

I don't know if this is the correct place to ask, but I cannot get ffdecsawrapper to run on my machine. I am trying to put it between my hdhomerun and mythtv, but it freezes as soon as a process tries to access the loopback device.

I have tested it with me-tv, and it works if I restrict the app on the "physical" device, but not on the loopback. If I keep the app running accessing the loopback, I see this in the syslog around 2 minutes later:

Apr 22 23:30:31 myth-vm kernel: [13920.116212] INFO: task ffdecsawrapper:9445 blocked for more than 120 seconds. Apr 22 23:30:31 myth-vm kernel: [13920.116223] Tainted: G OE 3.16.0-34-generic #47~14.04.1-Ubuntu Apr 22 23:30:31 myth-vm kernel: [13920.116226] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Apr 22 23:30:31 myth-vm kernel: [13920.116231] ffdecsawrapper D ffff880123c130c0 0 9445 1 0x00000000 Apr 22 23:30:31 myth-vm kernel: [13920.116239] ffff8800b638bb90 0000000000000086 ffff8800b63f28c0 ffff8800b638bfd8 Apr 22 23:30:31 myth-vm kernel: [13920.116246] 00000000000130c0 00000000000130c0 ffffffff81c1a480 ffffffffc06eb080 Apr 22 23:30:31 myth-vm kernel: [13920.116252] ffffffffc06eb084 ffff8800b63f28c0 00000000ffffffff ffffffffc06eb088 Apr 22 23:30:31 myth-vm kernel: [13920.116258] Call Trace: Apr 22 23:30:31 myth-vm kernel: [13920.116276] [] schedule_preempt_disabled+0x29/0x70 Apr 22 23:30:31 myth-vm kernel: [13920.116284] [] __mutex_lock_slowpath+0xd5/0x1d0 Apr 22 23:30:31 myth-vm kernel: [13920.116291] [] mutex_lock+0x1f/0x2f Apr 22 23:30:31 myth-vm kernel: [13920.116304] [] dvb_device_open+0x22/0xf0 [dvb_core] Apr 22 23:30:31 myth-vm kernel: [13920.116312] [] chrdev_open+0x9f/0x1d0 Apr 22 23:30:31 myth-vm kernel: [13920.116319] [] do_dentry_open+0x1ff/0x350 Apr 22 23:30:31 myth-vm kernel: [13920.116324] [] ? cdev_put+0x30/0x30 Apr 22 23:30:31 myth-vm kernel: [13920.116330] [] vfs_open+0x49/0x50 Apr 22 23:30:31 myth-vm kernel: [13920.116337] [] do_last+0x564/0x1240 Apr 22 23:30:31 myth-vm kernel: [13920.116344] [] ? link_path_walk+0x71/0x8a0 Apr 22 23:30:31 myth-vm kernel: [13920.116352] [] ? apparmor_file_alloc_security+0x5b/0x180 Apr 22 23:30:31 myth-vm kernel: [13920.116358] [] path_openat+0xbb/0x670 Apr 22 23:30:31 myth-vm kernel: [13920.116364] [] ? wake_futex+0x66/0x90 Apr 22 23:30:31 myth-vm kernel: [13920.116370] [] ? futex_wake_op+0x312/0x530 Apr 22 23:30:31 myth-vm kernel: [13920.116376] [] do_filp_open+0x3a/0x90 Apr 22 23:30:31 myth-vm kernel: [13920.116383] [] ? __alloc_fd+0xa7/0x130 Apr 22 23:30:31 myth-vm kernel: [13920.116390] [] do_sys_open+0x129/0x280 Apr 22 23:30:31 myth-vm kernel: [13920.116397] [] SyS_open+0x1e/0x20 Apr 22 23:30:31 myth-vm kernel: [13920.116403] [] system_call_fastpath+0x1a/0x1f

The ffdecsawrapper log don't say much:

Apr 22 23:20:32.405 CAM(core.load): * Conax (pri -10) Apr 22 23:20:32.405 CAM(core.load): * Cardclient (pri -15) Apr 22 23:20:32.414 THREAD: SC housekeeper thread started (pid=9436, tid=140573548549888) Apr 22 23:20:33.417 frontend: Starting thread on /dev/dvb/adapter4/frontend1 The thread scheduling parameters indicate: policy = 0 priority = 0 Apr 22 23:20:33.417 demux: Starting thread on /dev/dvb/adapter4/demux1 The thread scheduling parameters indicate: policy = 0 priority = 0 Apr 22 23:20:33.417 dvr: Starting thread on /dev/dvb/adapter4/dvr1 The thread scheduling parameters indicate: policy = 0 priority = 0 Apr 22 23:20:34.433 frontend: Starting thread on /dev/dvb/adapter5/frontend1 The thread scheduling parameters indicate: policy = 0 priority = 0 Apr 22 23:20:34.434 dvr: Starting thread on /dev/dvb/adapter5/dvr1 The thread scheduling parameters indicate: policy = 0 priority = 0 Apr 22 23:20:34.436 demux: Starting thread on /dev/dvb/adapter5/demux1 The thread scheduling parameters indicate: policy = 0 priority = 0 Apr 22 23:20:35.452 frontend: Starting thread on /dev/dvb/adapter6/frontend1 The thread scheduling parameters indicate: policy = 0 priority = 0 Apr 22 23:20:35.452 dvr: Starting thread on /dev/dvb/adapter6/dvr1 The thread scheduling parameters indicate: policy = 0 priority = 0 Apr 22 23:20:35.452 demux: Starting thread on /dev/dvb/adapter6/demux1 The thread scheduling parameters indicate: policy = 0 priority = 0 Apr 22 23:20:36.467 frontend: Starting thread on /dev/dvb/adapter7/frontend1 The thread scheduling parameters indicate: policy = 0 priority = 0 Apr 22 23:20:36.468 demux: Starting thread on /dev/dvb/adapter7/demux1 The thread scheduling parameters indicate: policy = 0 priority = 0 Apr 22 23:20:36.468 dvr: Starting thread on /dev/dvb/adapter7/dvr1 The thread scheduling parameters indicate: policy = 0 priority = 0 Apr 22 23:20:36.468 : Listening on port 5456

I am currently trying to run this on a mythbuntu up to date (kernel 3.16.0.34) and tried too a kernel 3.13.0.49 (as I saw the 3.13 kernel branch referenced in the doc). please feel free to redirect me to another place if needed. I have tried to look for a direct contact, but didn't found any.

Thanks.

bas-t commented 9 years ago

what is a myth-vm kernel?

bas-t commented 9 years ago

If it means you are running in a virtual machine: those are not supported in any way.

bas-t commented 9 years ago

Anyhow, if you want support for this issue, I need to know how you compiled the hdhomerun driver into your regular (non-vm) up-to-date 3.16.0.34 kernel. And how you compiled the dvbloopback module into it afterwards. Usually, that's where it goes wrong. Your syslog indicates that you created a conflicting situation. Conflicting as in: the dvbloopback driver does not match the hdhomerun drivers symbols. Or something like that.

tschork commented 9 years ago

Hello,

Effectively, "myth-vm" is the hostname of the system, and I'm running it in a virtualbox vm. I will reproduce the steps on my physical system, and come back with how it went.

As far as I remember, the dvb device driver installation was a simple pair of make && make install in the folders of the kernel module and the userspace application, but I will confirm this.

Thanks anyhow.

bas-t commented 9 years ago

If you still have this issue on your physical system, I need to know exactly what you did. So each and every command, including downloading the hdhomerun drivers. If it's a long list, please use pastebin.

tschork commented 9 years ago

I have tried on my main machine, and still have the same behaviour. For the record, this system is a linux mint 17.1, up to date and running with a stock kernel 3.13.0.37

What I did: install pre-requisites packages (apt-get on dvb-tools, libv4l-dev, cmake, libhdhomerun-dev, mythtv) install me-tv (for testing)

Fetch dvbHdHomerun sources git clone https://github.com/h0tw1r3/dvbhdhomerun.git

Build dvbHomerun kernel module cd /usr/src/dvbhdhomerun/kernel/ make make install depmod -a

Build dvbHomerun userspace app cd /usr/src/dvbhdhomerun/userhdhomerun make make install ln -s /usr/local/bin/userhdhomerun /usr/bin

Created the config file in /etc/dvbhdhomerun

rebooted the machine.

I then checked that I had /dev/dvb devices, and I did. I launched me-tv, scaned for channels, and it found a bunch. I tried via specyfing an adapter too, same result. I have a clear picture on unencrypted channels.

Then, I went to build ffdecsawrapper:

I fetched the sources, cd in the folder and ran ./configure Contrarily to my vm, it didn't asked me to patch my dvb-core module, so I haven't done anything about this.

Once the build finished, I have manually copied dvbloopback.ko to /lib/modules/3.13.0-37-generic/updates/, copied ffdecsawrapper to /usr/bin and created init.d script and config file as specified here: http://www.lursen.org/wiki/FFdecsawrapper_System_Configuration I ran depmod -a, and restarted the machine, to be on the safe side.

Now, I re-launched me-tv on the physical adapter, and it still runs without issue. But when I started it on the 1st loopbak device, it hangs, as in the vm, and I have a similar message in the syslog:

Apr 26 11:01:12 pc-mint kernel: [ 1818.962068] dvbloopback: registering 2 adapters Apr 26 11:01:12 pc-mint kernel: [ 1818.962202] DVB: registering new adapter (DVB-LOOPBACK) Apr 26 11:01:12 pc-mint kernel: [ 1818.967657] DVB: registering new adapter (DVB-LOOPBACK) Apr 26 11:04:55 pc-mint kernel: [ 2041.734979] INFO: task ffdecsawrapper:5771 blocked for more than 120 seconds. Apr 26 11:04:55 pc-mint kernel: [ 2041.734988] Tainted: P OX 3.13.0-37-generic #64-Ubuntu Apr 26 11:04:55 pc-mint kernel: [ 2041.734991] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Apr 26 11:04:55 pc-mint kernel: [ 2041.734995] ffdecsawrapper D ffff88043ec94480 0 5771 1 0x00000000 Apr 26 11:04:55 pc-mint kernel: [ 2041.735003] ffff880355b43bb0 0000000000000082 ffff880355b73000 ffff880355b43fd8 Apr 26 11:04:55 pc-mint kernel: [ 2041.735011] 0000000000014480 0000000000014480 ffff880355b73000 ffffffffa0f80060 Apr 26 11:04:55 pc-mint kernel: [ 2041.735018] ffffffffa0f80064 ffff880355b73000 00000000ffffffff ffffffffa0f80068 Apr 26 11:04:55 pc-mint kernel: [ 2041.735026] Call Trace: Apr 26 11:04:55 pc-mint kernel: [ 2041.735043] [] schedule_preempt_disabled+0x29/0x70 Apr 26 11:04:55 pc-mint kernel: [ 2041.735051] [] __mutex_lock_slowpath+0x135/0x1b0 Apr 26 11:04:55 pc-mint kernel: [ 2041.735059] [] mutex_lock+0x1f/0x2f Apr 26 11:04:55 pc-mint kernel: [ 2041.735071] [] dvb_device_open+0x22/0xf0 [dvb_core] Apr 26 11:04:55 pc-mint kernel: [ 2041.735078] [] chrdev_open+0x9f/0x1d0 Apr 26 11:04:55 pc-mint kernel: [ 2041.735084] [] do_dentry_open+0x233/0x2e0 Apr 26 11:04:55 pc-mint kernel: [ 2041.735090] [] ? cdev_put+0x30/0x30 Apr 26 11:04:55 pc-mint kernel: [ 2041.735095] [] vfs_open+0x49/0x50 Apr 26 11:04:55 pc-mint kernel: [ 2041.735102] [] do_last+0x554/0x1200 Apr 26 11:04:55 pc-mint kernel: [ 2041.735110] [] ? apparmor_file_alloc_security+0x5b/0x180 Apr 26 11:04:55 pc-mint kernel: [ 2041.735118] [] path_openat+0xbb/0x640 Apr 26 11:04:55 pc-mint kernel: [ 2041.735125] [] ? wake_up_state+0x10/0x20 Apr 26 11:04:55 pc-mint kernel: [ 2041.735132] [] ? wake_futex+0x66/0x90 Apr 26 11:04:55 pc-mint kernel: [ 2041.735139] [] do_filp_open+0x3a/0x90 Apr 26 11:04:55 pc-mint kernel: [ 2041.735147] [] ? __alloc_fd+0xa7/0x130 Apr 26 11:04:55 pc-mint kernel: [ 2041.735154] [] do_sys_open+0x129/0x280 Apr 26 11:04:55 pc-mint kernel: [ 2041.735160] [] SyS_open+0x1e/0x20 Apr 26 11:04:55 pc-mint kernel: [ 2041.735166] [] system_call_fastpath+0x1a/0x1f Apr 26 11:06:04 pc-mint kernel: [ 2110.105975] dvblb_fake_ioctl interrupted: 4

bas-t commented 9 years ago

A couple of issues detected:

I have a possible solution: I added hdhomerun driver to the v4l tree and the dvbloopback driver too.

So you can try: remove the installed dvbloopback driver

git clone git://github.com/bas-t/media_build.git -b hdhomerun

git clone --depth=1 git://github.com/bas-t/media_tree.git -b hdhomerun && cd media_build

make dir DIR=../media_tree

make distclean

make allyesconfig

make && make install

This will compile and install both dvbloopback and hdhomerun drivers (and lots more) into /lib/modules/uname -r/updates/media/

I don't think you have to recompile ffdecsawrapper, but if you do, make sure you do it with --module=no

Likewise, you should not install the hdhomerun kernel module anymore as you did before.

Hope this helps.

bas-t commented 9 years ago

Hi, I changed the title of your ticket so it describes what the actual issue is.

tschork commented 9 years ago

thanks, trying this now.

tschork commented 9 years ago

ok, first report... On my physical machine, it crashes when inserting the dvb_hhhomerun module: http://pastebin.com/p04aF2Hz On my virtual machine, everything is smooth, and no crashes, but when I try to lock to a channel with the loopback device, the ffdecsa log says this: Apr 26 13:52:42.669 : Listening on port 5456 Apr 26 13:52:51.921 CSA: Got command(4): I idx: 0 pid: 0 Apr 26 13:52:51.922 CSA: Got command(4): I idx: 0 pid: 0 Apr 26 13:52:51.976 CHANNEL: Tuning frontend Apr 26 13:52:51.977 CSA: Got command(4): I idx: 0 pid: 0 Apr 26 13:52:52.302 CSA: Got command(5): I idx: 0 pid: 0 Apr 26 13:52:52.303 CSA: Got command(5): I idx: 0 pid: 0 Apr 26 13:52:52.318 CSA: Got command(6): I idx: 0 pid: 0 Apr 26 13:52:52.319 CSA: Got command(6): I idx: 0 pid: 0 Apr 26 13:52:52.331 CSA: Got command(7): I idx: 0 pid: 0 Apr 26 13:52:52.332 CSA: Got command(7): I idx: 0 pid: 0 Apr 26 13:52:56.655 CSA: Got command(4): I idx: 0 pid: 0 Apr 26 13:52:57.624 CSA: Got command(5): I idx: 0 pid: 0 Apr 26 13:52:57.624 CSA: Got command(6): I idx: 0 pid: 0 Apr 26 13:52:57.625 CSA: Got command(7): I idx: 0 pid: 0 Apr 26 13:53:19.661 CHANNEL: Tuning frontend Apr 26 13:53:19.662 CSA: Got command(4): I idx: 0 pid: 0 Apr 26 13:53:34.861 CHANNEL: Tuning frontend

and nothing happens. The hdhomerun driver log is silent, nothing is written at all...

Thank you a lot to your help until now. Especially on a Sunday. I wasn't expecting an answer that quickly. I will try to go further during the week, but I have to leave my computer now. I probably will install mythbuntu on the NUC that runs win8 / mediaportal for now as it is way too unstable to be really used anyhow. I have the feeling that the mint kernel might be a bit different than a ubuntu kernel, even if they are a derivative. Again, thanks a lot.

bas-t commented 9 years ago

I'm not so happy with ubuntu kernels in general, but the 3.13 version imo sucks bigtime. I'm quite sure that the dvbloopback module is in perfect order the way you compiled it now. So what's left: investigate how the hdhomerun userspace prog relates to the hdhomerun kernel module. And also, during compilation of the hdhomerun kernel module, it spits quite a few warnigs etc. Though it compiles in the end, it might be worth looking into, there is room for improvement.

If you know anything about it, I invite you to elaborate on the relation between the hdhomerun kernel module and it's userspace prog. And of course, being a network device, how do the module/prog translate to the dvb layer and vice versa