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

1st Official Post

    Hi all,

    I'm wondering how many of you are seeing this. I've got a DVBSky S960 and a TechnoTrend S2-4650 DVB-S2 USB tuners (both use the dvb-usb-dvbsky driver) and both are failing in the same way. Basically, the tuner works for a while and then you start to see errors like this in the logs:

    2018-04-04 10:17:36.756 [ INFO] mpegts: 12149H in 4.8E - tuning on Montage Technology M88DS3103 : DVB-S #0
    2018-04-04 10:17:37.159 [ ERROR] diseqc: failed to send diseqc cmd (e=Connection timed out)

    2018-04-04 10:17:37.160 [ INFO] mpegts: 12265H in 4.8E - tuning on Montage Technology M88DS3103 : DVB-S #0

    2018-04-04 10:17:37.535 [ ERROR] diseqc: failed to send diseqc cmd (e=Connection timed out)

    And the tuner stops working completely. After a reboot things work ok for a while.

    The problem is introduced since kernel 4.10. I did a kernel bisect between 4.9 and 4.10. It seems the commit that

    breaks my tuner is the following one:


    9d659ae14b545c4296e812c70493bfdc999b5c1c is the first bad commit
    commit 9d659ae14b545c4296e812c70493bfdc999b5c1c
    Author: Peter Zijlstra <[email protected]>
    Date: Tue Aug 23 14:40:16 2016 +0200


    locking/mutex: Add lock handoff to avoid starvation

    This seems relatively harmless, and the mutex logic is used by countless of other drivers too. I've now confirmed that I can get a 4.10 kernel with working DVBSky S960 by reverting the following 4 patches from a vanilla 4.10 kernel:

    Code
    549bdd3 Revert "locking/mutex: Add lock handoff to avoid starvation"
3210f31 Revert "locking/mutex: Restructure wait loop"
418a170 Revert "locking/mutex: Simplify some ww_mutex code in __mutex_lock_common()"
0b1fb8f Revert "locking/mutex: Enable optimistic spinning of woken waiter"
c470abd Linux 4.10

    I haven't been able to find a cause for this bug. I have reported it in the kernel bug tracker (199323 – DVBSky USB TV tuners do not work since 4.10 due to mutex issues) and to the linux-media mailing list (Regression: DVBSky S960 USB tuner doesn't work in 4.10 or newer — Linux media). In any case the ugly consequence of the bug is that I cannot use LE8 and watch satellite TV reliably.

    I haven't seen the issue being reported that widely, hence this thread. I'd like to hear if anyone of you are seeing the same problem.

    Subscribing to this thread since ive been affected by this too. Im currently running 8.2.5 with a 4.9 kernel (4.9.88) and no problems whatsoever. I did have problems of this nature when using the kernel shipped with 8.2.5.

    I also have this problem if i leave the power management options (e.g. S3 suspend on usb), enabled in the BIOS; which was also problem for me in older kernels too.

    I hit this problem too a few weeks back after upgrading my kernel to 4.9.92, so i went back to 4.9.88 and all good since.

    Just to be clear, I'm personally running an x86_64 setup instead of RPi, but issues could be the same or not.

    jahutchi, you seem to be on x86 as well. Do you custom-build your setup with a specific 4.9 kernel?

    I recently tried upgrading to a later 4.9.x kernel (4.9.111), as I'd noticed this fix which seemed related:

    kernel/git/stable/linux.git - Linux kernel stable tree

    However, I've just hit the problem again (admittedly, it took a couple of weeks to surface)...

    I have the following errors in my tvheadend logfile:

    Code
    2018-07-26 10:45:48.356 [   INFO] mpegts: 11778V in Freesat - tuning on Montage Technology M88DS3103 #0 : DVB-S #0
2018-07-26 10:45:50.462 [  ERROR] diseqc: failed to set voltage (e=Resource temporarily unavailable)

    And the following messages repeating in dmesg:

    Code
    [934966.146448] m88ds3103 1-0068: i2c wr failed=-110
[934968.283100] usb 1-1: dvb_usb_v2: usb_bulk_msg() failed=-110
[934968.283107] usb 1-1: failed=-110

    Only thing I can do to get the darn thing working again is power cycle.

    I am therefore reverting back to kernel 4.9.88.

    Since my previous post, it's also worth noting that I've hit the problem (just once) on kernel v4.9.88. This was at a time when my machine was extremely sluggish because a process (tvheadend) ran out of control and chewed all my memory, causing excessive swapping.

    I downgraded tvheadend from 4.2.6 -> 4.2.5 where I don't see the memory leakage (reported here: timeshift buffer size problems - Tvheadend). So this could also be related to how busy the machine is at the point you perform the channel switch.

    Edited once, last by jahutchi (July 26, 2018 at 4:59 PM).

    After upgrading from kernel 4.9.80 to 4.14.61 on my RPi3 I noticed this:

    After the signal is lost (e.g. due to bad weather) and when it comes back - the tuner (DVBSky S960) does not lock the signal anymore. A reboot is required. I was able to reproduce this issue multiple times by blocking the signal from the LNB. Never had this issue with kernel 4.9.

    I just tested with kernel 4.18.0 - the issue seem to be fixed - I blocked the signal from LNB and when the signal came back - tuner was able to lock it.

    Nevermind, I did more testing and this issue randomly pops up with any kernel including 4.9.

    However, with kernel 4.18 I encountered another issue - VDR (or VNSI) does not seem to function - I don't get any picture.

    CvH or anyone - can you test if VDR/VNSI works on your hardware with kernel 4.18?

    Edited once, last by smp (August 16, 2018 at 1:52 AM).

    Sadly, that patch didn't fix the issue. I was able to quickly reproduce it by disconnecting the antenna cable for 10 minutes and trying to tune to a bunch of transponders (when the cable was disconnected). When I reconnected the cable the device was unable to lock the transponders anymore until a reboot.

    Quote from smp

    Sadly, that patch didn't fix the issue. I was able to quickly reproduce it by disconnecting the antenna cable for 10 minutes and trying to tune to a bunch of transponders (when the cable was disconnected). When I reconnected the cable the device was unable to lock the transponders anymore until a reboot.

    Do you get any errors in dmesg under these circumstances? Such as the -110 timeout errors seen by others.