Problems with DVBSky / TechnoTrend USB DVB-S2 tuners since LE8

I didn't check dmesg. It failed like it always did with newer kernels - it works for a while but a brief signal disruption randomly triggers the failure. I'm now back to kernel 4.8.16 for everyday use.

Quote from smp

I didn't check dmesg. It failed like it always did with newer kernels - it works for a while but a brief signal disruption randomly triggers the failure. I'm now back to kernel 4.8.16 for everyday use.

Fair enough - I suspect we would have seen a bunch of timeout (-110) errors as previously, but without much indication of exactly why the device has started to timeout.

Just spent a fair amount of time ploughing through the debug traces on bugzilla, and cross-checking some commits that happened during the 4.10 kernel developments.

This one looks suspect since the attach logic in dvbsky.c appears to attempt to modify fe->ops

Does the attached patch to revert this change for the m88ds3103 driver have any effect ?

Unfortunately, I do not currently have an environment upon which to beta test this myself.

Quote from jahutchi

Does the attached patch to revert this change for the m88ds3103 driver have any effect ?

No, same issue.

Subscribing to see if this gets resolved (hope it will).

on my pc-installation (ubuntu mate 18.10) i installed kernel 4.19.2 and it solved the problems. after hours of watching TV i am almost blind, but now i can say that kernel works with the installed firmware of DVBSky S960 DVB S/S2 USB.

so we have to wait until the developers will include this kernel to LibreELEC ...

This is very good news. I'm on 16.04 LTS kernel, and all my DVBSky devices work fine (but I use mostly pcie).

Quote from gurabli

This is very good news. I'm on 16.04 LTS kernel, and all my DVBSky devices work fine (but I use mostly pcie).

yes, also 18.04 LTS made no problems, since 18.10 with kernel 4.18 we had this problems. but with 4.19.2 (4.19.0 and 4.19.1 are not working) all seems to be ok ...

Quote from harpmaster

yes, also 18.04 LTS made no problems, since 18.10 with kernel 4.18 we had this problems. but with 4.19.2 (4.19.0 and 4.19.1 are not working) all seems to be ok ...

I keep my home servet on 16.04 since it is working perfectly, no need for any upgrade. So I don't know 18.04, but I saw the kernel version and than I postponed the test and migration.

On LE I have family members with Rpi all in one solutions, there I wait for this update.

Kernel 4.19.2 did not solve the problem described in the original post, I can still easily reproduce it. In 4.19.2/4.20-rc2 they reverted commit 7d95fb74 that made DVBsky devices non-functional since kernel 4.18 but that issue is completely unrelated.

Quote from smp

Kernel 4.19.2 did not solve the problem described in the original post, I can still easily reproduce it. In 4.19.2/4.20-rc2 they reverted commit 7d95fb74 that made DVBsky devices non-functional since kernel 4.18 but that issue is completely unrelated.

thanks for the information! so we have to wait ....

First post in forum, suscribing to this post

hi guys,

you should give the new alpha release LibreELEC (Leia) v8.90.008 ALPHA a try. my DVBSky S960 DVB S/S2 USB with vdr-backend is now working with astra 19.2° channels on my Raspberry Pi v3.

many thanks to the LibreELEC-team!

I found a workaround for the mutex issue. It seem to be impossible to revert commit 9d659ae14b545c4296e812c70493bfdc999b5c1c in kernel 4.19, so here's a solution:

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 3f8a351..5878d8f 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -59,7 +59,7 @@ EXPORT_SYMBOL(__mutex_init);
  * Bit2 indicates handoff has been done and we're waiting for pickup.
  */
 #define MUTEX_FLAG_WAITERS    0x01
-#define MUTEX_FLAG_HANDOFF    0x02
+#define MUTEX_FLAG_HANDOFF    0x00
 #define MUTEX_FLAG_PICKUP    0x04
 
 #define MUTEX_FLAGS        0x07

After applying this patch the random tuner failures are gone. Tested with DVBSky S960, kernel 4.19.7.

smp In light of the kernel mutex handoff changes I do wonder whether it'd be wise to adjust the i2c mutex lock in dvbsky.c to be non-interruptible. I can see this is the way it's done in several other of the dvb-usb-v2 drivers (though not all)

I have no idea whether this will make things better or worse, but just thought it may be worth a shot if you have time to test it (find attached).

This builds on my previous patch to use a single mutex for all r/w ops, but also adjusts the i2c mutex lock to be non-interruptible.

Note: I had to give the attachment a .txt extension in order for it to upload.

Other than this I'm all out of ideas.

@jahutchi I get this build error

CC [M]  drivers/media/usb/dvb-usb-v2/dvbsky.o
drivers/media/usb/dvb-usb-v2/dvbsky.c: In function 'dvbsky_i2c_xfer':
drivers/media/usb/dvb-usb-v2/dvbsky.c:117:27: error: expected ';' before 'if'
mutex_lock(&d->i2c_mutex)
^
;
drivers/media/usb/dvb-usb-v2/dvbsky.c:119:2:
if (num > 2) {
~~
drivers/media/usb/dvb-usb-v2/dvbsky.c:115:15: warning: unused variable 'obuf' [-Wunused-variable]
u8 ibuf[64], obuf[64];
^~~~
drivers/media/usb/dvb-usb-v2/dvbsky.c:115:5: warning: unused variable 'ibuf' [-Wunused-variable]
u8 ibuf[64], obuf[64];
^~~~
make[5]: *** [scripts/Makefile.build:304: drivers/media/usb/dvb-usb-v2/dvbsky.o] Error 1
make[4]: *** [scripts/Makefile.build:544: drivers/media/usb/dvb-usb-v2] Error 2
make[3]: *** [scripts/Makefile.build:544: drivers/media/usb] Error 2
make[2]: *** [scripts/Makefile.build:544: drivers/media] Error 2
make[2]: *** Waiting for unfinished jobs....

Missing semi-colon - embarrassing school-boy error

Trying again....

Well, it didn't pass the antenna cable "hot unplug" test that I do to accelerate the tuner failure.