not working on NUC7i5BNH

[jlcox1970]

Hi, not sure on the difference with this model as opposed to other NUC7i5BN series NUC's but I have been unable to make this work. I have set both of the BIOS settings to 'software control' for the leds and I have checked that the GUID and it exists once I install the WMI module

As I not a kernel program by any stretch I was wondering if you could make a version with a higher debug as all I get is the following when I cat the nuc_led file in proc Power LED state could not be determined: WMI call failed

Ring LED state could not be determined: WMI call failed

Thanks Jason

[milesp20]

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.

[jlcox1970]

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

[milesp20]

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).

[jlcox1970]

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.

[milesp20]

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?

[jlcox1970]

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

[milesp20]

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.

[jlcox1970]

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

Thanks for you help

[milesp20]

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