not working on NUC7i5BNH about intel_nuc_led HOT 9 CLOSED

Give it a spin now - should hopefully give you a bit more information. Also worth double checking that you're running a reasonably current BIOS version.

from intel_nuc_led.

BIOS is the latest from Intel
no joy unfortunately with the new module
logs show

Nov 17 16:34:12 0000-0000-0000 kernel: nuc_led: Intel NUC LED control driver loaded
Nov 17 16:34:30 0000-0000-0000 kernel: ACPI Exception: AE_BAD_PARAMETER, wmi_evaluate_method (20170728/NUC_LED-203)
Nov 17 16:34:30 0000-0000-0000 kernel: nuc_led: Unable to set NUC LED state: WMI call failed

and dmidecode
BIOS Information
Vendor: Intel Corp.
Version: BNKBL357.86A.0047.2017.0518.1824
Release Date: 05/18/2017
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 8192 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 5.6
Firmware Revision: 8.2

from intel_nuc_led.

Seems like Intel may have changed the WMI call in BN0047 (and probably AY0041), though they haven't updated any documentation to suggest that.

If you run the following (you may need to install fwts first):
sudo fwts wmi -

Do you get something along these lines? Does the GUID match below?
\AMW0._WDG (1 of 2)
GUID: 8C5DA44C-CDC3-46B3-8619-4E26D34390B7
WMI Method:
Flags : 0x02 (Method)
Object ID : AA
Instance : 0x01
PASSED: Test 1, 8C5DA44C-CDC3-46B3-8619-4E26D34390B7 has associated method \AMW0.WMAA

If so, can you run the following:
sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
iasl -d dsdt.dat

All I would need from the resulting dsdt.dsl are 3 methods: WMAA (see results from fwts), and both GLED and SLED (they should be referenced by the WMAA method).

from intel_nuc_led.

fwts wmi - shows identical information

iasl -d dsdt.dat

Intel ACPI Component Architecture
ASL+ Optimizing Compiler version 20160527-64
Copyright (c) 2000 - 2016 Intel Corporation

Input file dsdt.dat, Length 0x28EEC (167660) bytes
ACPI: DSDT 0x0000000000000000 028EEC (v02 INTEL NUC7i5BN 0000002F INTL 20160422)
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed

Found 38 external control methods, reparsing with new information
Pass 1 parse of [DSDT]
ACPI Error: [BNUM] Namespace lookup failure, AE_ALREADY_EXISTS (20160527/dsfield-660)
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output: dsdt.dsl - 1288660 bytes

iASL Warning: There were 38 external control methods found during
disassembly, but only 30 were resolved (8 unresolved). Additional
ACPI tables may be required to properly disassemble the code. This
resulting disassembler output file may not compile because the
disassembler did not know how many arguments to assign to the
unresolved methods. Note: SSDTs can be dynamically loaded at
runtime and may or may not be available via the host OS.

from intel_nuc_led.

The WMI part being the same simplifies it - perhaps changes to the get/set methods for the LED.

Can you attach a file with the WMAA, GLED and SLED methods from the dsdt.dsl file? Look for lines starting with:
Method (WMAA
Method (SLED
Method (GLED

Indentation of the file should make it easy to see where the method starts and ends.

Also, which distribution and kernel are you running?

from intel_nuc_led.

Method (WMAA, 3, NotSerialized)
{
CLSB (INFO)
CreateDWordField (INFO, Zero, BUF0)
BUF0 = 0x44534943
If (Arg1 == One)
{
_SB.GLED (Arg2, INFO)
If (BUF0 == 0x44534943)
{
CLSB (INFO)
INF0 = 0xE2
}

            Local1 = INFO /* \AMW0.INFO */
            Return (Local1)
        }

        If (Arg1 == 0x02)
        {
            \_SB.SLED (Arg2, INFO)
            If (BUF0 == 0x44534943)
            {
                CLSB (INFO)
                INF0 = 0xE2
            }

            Local1 = INFO /* \AMW0.INFO */
            Return (Local1)
        }
    }
}

dsdt.dsl.txt

from intel_nuc_led.

Fortunately nothing changed there.

Can you modify nuc_led.c and change the wmi_evaluate_method calls to have a 0 instead of a 1 for the instance number (2nd argument) and try it again. I've tested locally on my NUC which is running an LTS build of Ubuntu and everything still looks good.

Reason being is that it looks like newer kernels (which I don't have) have been patched to fix a WMI instance numbering issue. It turns out the instance is a zero-indexed list, and instance 1 (which we want) would actually turn out to be item 0 in that list.

Let me know if that works.

from intel_nuc_led.

Bingo !!!
change the 2 of them and I can now read and set the leds

Thanks for you help

from intel_nuc_led.

Good to hear - I appreciate the assist with testing that out.

from intel_nuc_led.