Posts by jahutchi

    What do I have to do to apply it to my RPI myself?

    A few choices:

    1) Compile & install your own kernel from the raspbian sources, with my patch applied: Kernel building - Raspberry Pi Documentation

    2) My patch found it's way into media_tree just a couple of days ago: media_tree.git - Upstream media tree for Remote Controllers, V4L and DVB so you could to build and install the drivers yourself from media_tree to run within your existing kernel:,_build_and_install_v4l-dvb_device_drivers

    3) (If both above options are too scary), then wait until the patch filters it's way down to mainstream raspbian kernel.

    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.

    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.

    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.

    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:

    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:

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

    jahutchi you need to read the error messages you've helpfully shared. If your DNS is not being updated, then running a resolve script will fix this for you.

    On LibreELEC the /etc directory is on a squashfs read-only file system.

    Any advice on where the scripts need to go to resolve this issue on a LibreELEC system?

    In the meantime I adjusted my network settings to use the Google Dns as this works both on and off the VPN. However, I would prefer to use the DNS of my ISP and VPN provider.

    I recently seem to have the same DNS issues that others have reported recently. I'm using PIA and have been successfully for the past couple of years. This problem has developed recently though not exactly sure when, and I have automatic updates enabled.

    Basically, after connecting to PIA I lose the ability to perform DNS lookups since my DNS settings are still set to that of my ISP rather than the PIA DNS servers.

    Here are the logfile entries from openvpn.log when I connect:

    I can see the DNS servers in the PUSH reply, but these do not take effect since nslookups are still using my ISPs DNS, and eventually timeout:

    # nslookup

    After reading this thread I tried activating the "Potential DNS Fix" in the advanced settings but this gave the error:

    A DNS fix was not possible. Refer to the Kodi log... which looks like this:

    11:03:37.389 T:140547394086656  NOTICE: VPN Mgr : ( Creating a new APPEND.txt for Private Internet Access to try and fix DNS issues
    11:03:37.399 T:140547394086656   ERROR: VPN Mgr : ( To attempt a DNS fix, you need to install update-resolv-conf script in /etc/openvpn
    11:03:37.400 T:140547394086656   ERROR: VPN Mgr : ( Alternatively for systemd enabled installations, install update-systemd-resolved in /etc/openvpn/scripts
    11:03:37.400 T:140547394086656   ERROR: VPN Mgr : ( After installation of one of the scripts, apply the DNS fix again.

    I'm running LibreELEC 8.2.5.

    Any help with resolving this would be greatly received and I'll be happy to run further tests to help debug where it's going wrong.

    For the time being, as a workaround, I think I will adjust my LE network settings to point at the google DNS servers.

    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.