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

  • 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
    1. 549bdd3 Revert "locking/mutex: Add lock handoff to avoid starvation"
    2. 3210f31 Revert "locking/mutex: Restructure wait loop"
    3. 418a170 Revert "locking/mutex: Simplify some ww_mutex code in __mutex_lock_common()"
    4. 0b1fb8f Revert "locking/mutex: Enable optimistic spinning of woken waiter"
    5. 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
    1. 2018-07-26 10:45:48.356 [ INFO] mpegts: 11778V in Freesat - tuning on Montage Technology M88DS3103 #0 : DVB-S #0
    2. 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
    1. [934966.146448] m88ds3103 1-0068: i2c wr failed=-110
    2. [934968.283100] usb 1-1: dvb_usb_v2: usb_bulk_msg() failed=-110
    3. [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 ().

  • 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 want to test with those mutex commits reverted - I tried to revert on kernel 4.14 but I have no idea how to do this. :-(

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

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

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