I've the same problem with OpenElec and Kodibuntu !
I'm now running Kodi under Windows 8.1 ... but I really want to run it under Linux.
Same issue on NUC5i3RYH with RYBDWi35.86A bios and OpenElec 5.02 (linux kernel 3.17.8). CIR not working on Broadwell NUC. Remote is MCE compatible and worked fine on a Haswell NUC.
[ 2.605159] nuvoton-cir 00:01: IR PNP Port not valid! [ 2.605931] nuvoton-cir 00:01: disabled
I am experiencing the exact same problem as korsbaek. NUC5i3RYK with ry0137.bio with OpenElec. I have also tried the Haswell workaround without any luck.
[ 9.286400] nuvoton-cir 00:01: [io 0x03e0-0x03e7]
[ 9.286595] nuvoton-cir 00:01: [irq 10]
[ 9.286601] nuvoton-cir 00:01: [io 0x03f0-0x03f7]
[ 9.287147] nuvoton-cir 00:01: activated
[ 9.287150] nuvoton-cir 00:01: IR PNP Port not valid!
[ 9.287285] nuvoton-cir 00:01: disabled
we currently suggest our users (some hundreds already) to just return their new NUC boxes and buy something else more linux friendly. With your last generation NUC we had to disassemble the DSTD tables to actually proof intel that they have an error in their bios programming - do we really need to do this again this time?
Thank you very much also for your hint, that a media center distribution with nearly half a million users is not on your supported platform list. We will make that public via twitter - so that in the future no one reminds you on faulty bios implementations and customers you don't want to have (cause OpenELEC Linux users) will stop going on your nerves with software you don't like to support.
Intel please fix this issue. This is the single reason I bought the NUC for.
As per previous replies, please work with OpenElec again to fix this bug. Right now it's pointing to BIOS issues similar to what was discussed here (where the CIR was assigned only one IRQ that conflicted with other devices in the ACPI DSDT tables): Re: Haswell NUC CIR receiver (ACPI issue?). It's looking like it will affect almost all linux distributions so please don't alienate your users!
I think it is a bit unfortunate that if Intel is not willing to fix this issue, because there are a lot of people buy these NUCs for use as a media center. They have the perfect size and the right combination of hardware for this application, but if the hardware doesn't then it is no good.
PLEASE Intel fix this issue so we can continue to buy these lovely small boxes!
Intel is working on a new bios release which will fix several CIR related issues reported on D34010WYB, D54250WYB, DN2820FYB, NUC5i3RYB, NUC5i5RYB. Please see thread below for details.
Probing with other experts inside of Intel, I was hearing the following:
This particular issue appears to be because the version of the Linux kernel (v3.9) that OpenELEC builds with is very old (29th April 2013) and doesn't include the folllowing kernel commit,
Author: Antti Seppälä <firstname.lastname@example.org>
Date: Sun Feb 16 07:16:02 2014 -0300
[media] nuvoton-cir: Activate PNP device when probing
On certain motherboards (mainly Intel NUC series) bios keeps the
Nuvoton CIR device disabled at boot.
This patch adds a call to kernel PNP layer to activate the device if it
is not already activated. This will improve the chances of the PNP probe
actually succeeding on Intel NUC platforms.
Signed-off-by: Antti Seppälä <email@example.com>
Cc: Jarod Wilson <firstname.lastname@example.org>
Signed-off-by: Mauro Carvalho Chehab <email@example.com>
Our suspicion is that if you run a distro that uses a more recent kernel (anything newer than June 2014) like Ubuntu, Fedora or OpenSUSE, you won't experience this issue.
can someone confirm?
Intel is currently working with OpenELEC to try to find a fix for this issue.
I have no idea which OpenELEC version you tested.
OpenELEC 5.0 which is the current version is shipped with kernel 3.17.8.
OpenELEC 4.2 which was the last version was shipped with kernel 3.16.3
OpenELEC 4.0 which is more than a year old was shipped with kernel 3.14.3
Most of those kernels, including the 4.0 kernel version is much more current that e.g. the Ubuntu 14.04 LTS edition.
Belinda, as previously mentioned, the issue is still present on
Linux kernel 3.17.8 (newer than June 2014) on OpenElec 5.02.