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.

  • 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.

    Files

  • 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).

  • 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 ...

  • 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.

  • 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 ....

  • 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:

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

    Edited once, last by smp ().

  • This might work for this tuner, but likely create a fallout over all other tuners :/ but maybe we get some solution at least. Anyone informed the ML yet?

  • 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.

    Edited once, last by jahutchi ().

  • @jahutchi I get this build error


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