TV adapter drivers missing from 11.0.4?

    This is what came out:



    It talks about NVidia, which doesn't have much to do with this I suppose, but it seemingly affects these TV tuners in TVHeadend.

    So... now what :)

    Edited 3 times, last by Rataplan626 (February 20, 2024 at 3:54 PM).

    Sounds good. So when Raspbian incorporates that into their builds, it will one day 'automatically' end up in LE? Is that how things work? Now I have this build system up and running, can I build an 11.0.6 with this patch incorporated?

    Quote from Rataplan626

    I'm really sorry for my compile noobness, but how do I check?

    "git show <hash>" should output the patch content if the upstream kernel hashes have been merged correctly into the downstream Raspberry Pi kernel source that we use with RPi images. If they haven't, that will error and you'll have to search (grep) the commit log to find the commit message and confirm the patch is present.

    Sorry for the late reply, life hit me hard the last couple of weeks. Getting everything back on track now. This weekend I updated to LE12 on a test SD-card, and it still doesn't work. My build-vm is still on 11 though.


    git seems to report that patch is present:

    and some more after that.

    So that patch seems to be incorporated.

    Anyone? How could I continue from here reporting this bug in the kernel? Would it make sense to try a linux box with a newer kernel and see if it works again? Would I be right to assume if that would work, at some point it would work in LE again when they incorporate newer kernels as well?

    Yeah I'm hitting this. Mighty irritating. Previously I just loaded an old kernel and be done with it, but it's getting harder and harder to stay on such an older kernel.

    I'll try to debug somewhere this month. Haven't done a bisect with kernels yet, that'll be interesting. Anyone got an idea how to bisect this efficiently? VM in a VM with USB passthrough? It would really suck to do this manually.

    I did it on the real hardware but a vm could work I guess. It didn't even take as much time as I expected, but yes it's a bit of a hassle. I did it twice and came on the same patch both times. I wonder if you end up on the same erroneous patch.

    Dear lord, the bisecting is rather arcane, only to be made worse by debian/ubuntu's irritating default to just friggin' rebuild the WHOLE thing after each iteration.

    But, you came up with the 'modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules' one right?

    That's a red herring I guess. The problem is definitely with this one:

    c30411266fd67ea3c02a05c157231654d5a3bdc9 media: anysee: fix null-ptr-deref in anysee_master_xfer

    I'm no kernel developer, but the commit message states this is to fix a nullptr deref of msg[i].buf. If that's the intended behaviour, then why not check explicitly for msg.buff == NULL?

    Well, I reverted the patch and introduced my proposed NULL check, so:

    Lo and behold, it works again. Not sure if my NULL check is equivalently safe as the author of the patch intended. I'll try to get this upstreamed.

    Maybe this is a Anysee e30 *combo* edge case we're running into? Maybe the msg.len is actually 2 for other variants of the E30 and 1 for the combo?

    No idea how the device and the driver work with regards to initialization. Come to think, my only other linux kernel contribution was 15 years ago or something, I had to supply a patch for the E30C to get it working after suspend to ram.

    I was just typing a reply when your last update popped up. Weird how I came up with another patch that borked it twice. Still, for the time being, how would I build the kernel for now without the borked patch, or with yout update? I can find my way in Linux, but I'm not into kernel building apart from al the builds I made during this bisecting. By the way, on my laptop the initial LE build took like 45 minutes, but with the changed kernel only a few minutes.

    Code
    git remote add chewitt https://github.com/chewitt/LibreELEC.tv.git
git fetch chewitt dvb-fix
git checkout -b dvb-fix
git reset --hard chewitt/dvb-fix
PROJECT=RPi DEVICE=RPi4 ARCH=aarch64 make release

    I pushed the required kernel change to https://github.com/chewitt/LibreELEC.tv/commits/dvb-fix so the above ^ commands will fetch the commits from the dvb-fix branch in my repo, checkout a new branch, reset the state of that branch to match my dvb-fix branch, and then build an LE12 nightly image.

    If you can confirm it's fixed with that patch I'll push the change to LE12/master branches.

    I can't get it to build, during the build it can't find that specific version of fakeroot:

    --2024-06-10 17:29:26-- http://sources.libreelec.tv/mirror/fakeroo…oot-1.34.tar.gz
    Resolving sources.libreelec.tv (sources.libreelec.tv)... 65.109.172.87
    Connecting to sources.libreelec.tv (sources.libreelec.tv)|65.109.172.87|:80... connected.
    HTTP request sent, awaiting response... 404 Not Found
    2024-06-10 17:29:26 ERROR 404: Not Found.

    Doesn't matter if I take 12.0.0 or the latest nightly.


    I'm currently finding out how I can add sources to the building mechanism, as I found multiple repositories with that version in.

    Edited once, last by Rataplan626 (June 10, 2024 at 4:44 PM).

    Option #1 is to change the source URL that we download from in the package.mk.

    Option #2 is to manually download and place in your sources folder, then create the filename.sha256 checksum and filename.url for the package and the buildsystem will process them as if it had downloaded them.

    Option #3 is to ask nicely and someone on staff can usually upload it to our mirror (which I've done now).