Posts by las1

    chewitt I've been attempting to do a bisect and you're correct, it's been very challenging especially with patches and gcc versions not liking certain kernel versions. Am I able to compile the vanilla kernel outside of the LE build environment and simply install it to an existing running LE instance?

    I'm having trouble determining the best workflow to complete the bisect and any guidance would be appreciated. I assume this is really the only way to fix this unless another LE developer has the same hardware and willing to test. I'm happy to do the leg work but I'm hours into the bisect screwing around with build errors.

    smp that's my conclusion as well and the changes seem pretty basic in that commit. My next step was to look at maybe using kgdb (after enabling in the kernel config) to try to find some additional info.

    I'm an experienced Linux user (20+ years) and have been using xbmc/Kodi since the begining but this falls outside with what I know and not sure that it will be helpful. From initial research, debugging an in-tree loadable kernel module is tough to say the least..

    My configs are vanilla and have been unchanged since LE7 and willing to test/try just about anything rather than refresh 5 skull canyon PCs; I'm sure someone out there is facing the same issue? :(

    Thanks for all the helpful responses from everyone so far.

    No luck reverting to the next commit: https://github.com/torvalds/linux…a91b5d0dd6c7871 Lots of conflicts/add/removes that I'm unsure how to proceed fixing.

    I'm guessing since this next commit (183e19) happened in the 4.20rc1 branch/tag and the commit you referenced (4345e2e) was the first in the 5.x branch/tag that reverting to this wouldn't make a lot of sense since it for sure happens between Linux Kernel 5.10.x and Linux Kernel 6.1.x.

    Is there anything else you think I could try reverting or any additional ways to debug the nuvoton module? I just don't know enough about how this kernel module would interact with other parts of the kernel. It may look like the rc-core driver may work in conjunction with the nuvoton driver but I'm not sure...

    chewitt That seems to have done the trick! I was going down the right path and looking at the same nuvoton-cir.c changes but wasn't sure how I could do the revert/patch in git--network engineer, not a developer so thanks for this!

    I just cloned the master Linux branch and didn't bother even checking out a branch closer to what LE11 is running. Ran the revert and patch and recompiled the image.

    I'll apply this to my other PCs and test for a few days. I could attempt to do a pull request for this but it may take a few attempts.. ;)

    Thanks!

    I've been troubleshooting an issue for months now and have gotten nowhere. I recently hoped that building a custom image with kernel debug symbols enabled would provide some insight to my issue. Since I don't have ever see a coredump or anything I'm guessing it was a pointless effort...

    Before opening an issue in git, I figured I should check if there is any additional information or things I could try to be able to include as much information in the report as possible.

    I have multiple 6th generation Intel Nucs with a nuvoton consumer infrared module (built-in) that has functioned for many years on LE7/8/9/10 without any issue. After an upgrade to either LE11/12/13 (basically kernel 6.x+) I see that for whatever reason my remote stops working--randomly. The issue ususally occurs if quickly after boot I start scrolling through my PVR/TV menu. Using ir-keytable -t after I notice no input is being recognized and to look for button presses, nothing shows up.

    To fix this I can simply unload and reload the kernel module (nuvoton_cir) and everything works as normal including ir-keytable populating properly. Generally after performing this it will work until it's restarted--but not always. Kodi debug logs show absolutely no issue/change when the problem occurs. dmesg output also isn't of much use:

    The issue did happen right at the second RX FIFO message. The next message (417.036419) is me unloading/reloading the kernel module. What's strange is if I sit and jam a bunch of input buttons I see this message, even though it doesn't freeze. Looking through source code, it looks like this is just an informative message maybe?

    Lircd is not setup/configured/running and this is with a new default install of LE11/12/13.


    This happens with both the legacy and generic image (as expected). Any ideas? It's driving me crazy.

    OK clearly I'm missing something. Getting the same error.

    I took your three patches and put them in the same directory of my LE source directory, rebuilt the docker image using: docker build --pull -t libreelec tools/docker/jammy, ran: docker run --rm --log-driver none -v `pwd`:/build -w /build -it -e PROJECT=Generic -e BUILDER_NAME=username -e BUILDER_VERSION=11.0.6.username -e DEBUG=yes -e VALGRIND=yes -e ARCH=x86_64 libreelec ./scripts/build kodi and receive the same error. Would I have to edit the docker file to use openjdk-17-jre-headless instead of the default-jre-headless?

    Checking to make sure I'm not doing something stupid. I've build LibreElec countless times. I'm debugging an issue inbetween LE10 and LE11 and needing to build a version with kernel debug symbols enabled. I'm following the documentation here: https://github.com/LibreELEC/Libr….0/tools/docker

    I'm downloading the libreelec-11.0 branch and checking out the 11.0.6 tag (latest commit).

    I get all the way through the build and it errors out with:

    I'm using the focal docker image but have tried the buster Debian image too. I get the same build error if building not in a docker container. I installed libcrossguid-dev thinking it may help, it does not. Any ideas? LE12 builds fine.


    Any ideas?