DVB issue since LE switched to kernel 4.9.x

    Quote from smp

    We need someone who can reproduce the issue on a PC and a good linux skills. Otherwise this will never be fixed.

    Building images with downgraded kernel becoming less useful, especially for Rpi2/3.

    As far as I can tell, this problem only exists on RPi, not on "regular" Linux?

    I have several Virtual Machines with Linux (Debian 8 and Debian 9) and no such problems there.

    2 of those use exactly the same DVB-adapter as my RPi.

    Quote from gert

    As far as I can tell, this problem only exists on RPi, not on "regular" Linux?

    Incorrect. The problem occurs on my Generic x86_64 HTPC (Acer Revo 3700). I have the DVBSky S960. I am currently using the Generic v4.8 kernel builds supplied by smp earlier in this thread and this resolves the problem.

    It's probably dependant on hardware. Admittedly the Acer Revo 3700 is a little dated but with 4x 1.2GHz cores it should be upto the job. Whilst playing live TV my CPU is only around 20% utilised.

    Quote from jahutchi

    Incorrect. The problem occurs on my Generic x86_64 HTPC (Acer Revo 3700). I have the DVBSky S960. I am currently using the Generic v4.8 kernel builds supplied by smp earlier in this thread and this resolves the problem.

    That's fascinating, since I am using exactly the same DVB equipment: DVBSky S960.

    As far as I'm concerned:

    * RPI2 + DVBSky S960 -> no problems with 4.4 or 4.8, problems with 4.9

    * 2x Linux VM Debian 9 + DVBSky S960 -> -> no problems

    * 2x Linux VM Debian 9 + Terratec H7 -> no problems

    * 1x Linux VM Debian 8 + TBS5980 QBox -> no problems

    The kernel for Debian 9 =

    root@caladan:/home/gert# uname -a

    Linux caladan 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux


    and for Debian 8 =

    root@jed:/home/gert# uname -a

    Linux jed 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26) x86_64 GNU/Linux

    For both the DVBSky and the Terratec I have 2 of them. Each time that's 1 VM that has been upgraded from Debian 8 to 9, and 1 freshly installed with 9.

    I have never had any problems on any of my Virtual Machines.

    Quote from CvH

    what kernel does your host machine has ?

    The host is ESXi 6.5 for 2 of the VMs and ESXi6.0 u2 for the 3 others.

    Not sure if that uses a Linux kernel as a basis, and if so how I can see which one.

    EDIT: It uses vmkernel as a basis.

    Edited once, last by gert (September 13, 2017 at 3:20 PM).

    I decided to mess around with kernel 4.9.48 and replaced USB and PHY kernel driver sources with the sources from kernel 4.8.16 (I simply replaced drivers/usb and drivers/phy folders). I built an RPi2 image using that "modded" kernel. The issue is still there. So I guess it is not a USB issue and commit e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c (The big USB, and PHY, and extcon, patchsets for 4.9-rc1) have nothing to do with the issue.

    Any other ideas are welcome /shrug

    • Official Post
    Quote from smp

    Any other ideas are welcome /shrug

    ^ open two terminal windows: first window has the LE 8.2 branch cloned and second window has kernel sources cloned. Start the git bisect process on the kernel and use it to generate githashes you can use with the LE build system linux package. Create test images and test them, then mark the githashes good/bad until the bisect process identifies the problem commit. The way we patch things might require occasional fettling but the kernels are normally quite stable. NB: I would start with doing a test without the big RPi update patch; if things are not right without it you can drop that from builds. It is rebased with each kernel bump so it's the main item that will create problems for the bisect process.