Created attachment 258805 [details]
Output of acpidump

I suppose you've uploaded an acpidump of "acpidump -c off" output as I can see tables that are failed to be loaded there.
If not, please refresh the acpidump with an "acpidump -c off" output.

Thanks in advance.

> This issues are at least present in kernel versions 4.10 till 4.14.0-r4.

Can you also help to confirm if it is a regression?
And let us know the latest good kernel.

Thanks
Lv

Created attachment 258817 [details]
acpidump -c off output

It appears I have 2 version of acpidump installed. (in /usr/sbin and /usr/bin) The first one used is an old version from pmtools package, 2011. This command also doesn't support "-c off".

Attached in the output from "acpidump -c off", from the iasl package.

(In reply to Lv Zheng from comment #3)
> > This issues are at least present in kernel versions 4.10 till 4.14.0-r4.
> 
> Can you also help to confirm if it is a regression?
> And let us know the latest good kernel.
> 
> Thanks
> Lv

I have available in Gentoo portage (sys-kernel/vanilla-sources): versions 4.4.91 and 4.9.54.

4.4.91 and before is not able to fully boot my system due to bug in NVMe, which has been solved somewhere in 4.5. I just tried compile and boot the 4.4 kernel to search for the same errors, but the dmesg log on the screen is flooded from the panic caused by NVMe.

Looking back in my mail archives, I had some other functionality issues up to and including 4.8. Let's say that 4.10 was the first version where things started to work a bit "normal". (I skipped 4.9 at the time)

I compiled and booted 4.9.54. It behaves the same as versions >=4.10.

If you want me to manually download intermediate versions, let me know. But I will need a bit more time to do all that.

I've booted 4.4.91 with busybox initramfs and inspected dmesg. Same table load errors exist. It ACPI error list is a bit longer on 4.4.91, but I couldn't mount my root device to dump it. But I guess it answers your question regarding regression.

The smbus error is also there, but it is complaining about IRQ 255: 22 instead of - 2147483648: 107

Looks like a known issue due to:

    If (LEqual (PCHV (), SPTH))
    {
        Scope (_SB.PCI0.XHC.RHUB)
        {
            Device (HS11)

Please try if the following commit can fix the problem:
https://patchwork.kernel.org/patch/9347349/

We'll about to make it landing to the upstream now.

Linking this bug to:
https://bugs.acpica.org/show_bug.cgi?id=963

Thanks
Lv

The proposed patch works for me. Great!

Verified fixes all below issues:
(In reply to Tim Mohlmann from comment #0)
> Created attachment 258803 [details]
> dmesg log
> 
> I have various issues wrt ACPI on my Clevo N350DW. This issues are at least
> present in kernel versions 4.10 till 4.14.0-r4.
> * Battery info missing
> * AC adapter status missing
> * Some hotkeys not working
> * ACPI errors in dmesg
> * IRQ errors for smBus device
> 

SO functionality is okay. However, dmesg is showing some new ACPI exceptions. I will attach the new dmesg. If that is a separate issue and you need new bug report, let me know.

Again, for me personally everything is fine like this. Many thanks for your help!

Created attachment 260285 [details]
dmesg log after patch

> dmesg is showing some new ACPI exceptions.

[    0.513702] ACPI Exception: Could not find/resolve named package element: LNKA (20170728/dspkginit-381)

It's just because a wrong message level.
Introduced by the following commit:
  Commit: a62a7117d91ca83d319566cbe16039f4e9f413c2
  Subject: ACPICA: Implement deferred resolution of reference package
           elements

The commit meant to fix compliance issue in dealing with in-package name strings.
ACPICA upstream originally false treated such incompliance as a forward reference support in Windows AML interpreter and tried to solve it by non-deferred object resolution.

But actually Windows never solves in-package name strings to object references, (and in fact there is no object reference object type defined by AML spec, this is internal to implementation), but leaves them as strings.

The commit is trying to add a deferred resolution for Linux so that fixing this problem won't affect Linux drivers that have already been dependent on the old behavior.

However the commit marked unresolved name strings (hence forward referenced) as exceptions.

This is a proof that it functions as old Linux drivers' expectation:
[    0.559190] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.559227] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *10 11 12 14 15)
[    0.559261] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.559294] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.559328] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.559361] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.559394] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.559428] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 *11 12 14 15)

So please ignore these exceptions.

However we can ask ACPICA upstream to change this message to be a debugging message, rather than an exception.

> If that is a separate issue and you need new bug report, let me know.

No need to file a new bug, it's not a blocking issue for Linux.
However you can help to raise this to the ACPICA bugzilla.

(In reply to Lv Zheng from comment #11)
> > If that is a separate issue and you need new bug report, let me know.
> 
> No need to file a new bug, it's not a blocking issue for Linux.
> However you can help to raise this to the ACPICA bugzilla.

Okay, I will do so when I have time in the weekend.

(In reply to Lv Zheng from comment #7)
> Please try if the following commit can fix the problem:
> https://patchwork.kernel.org/patch/9347349/
> 
> We'll about to make it landing to the upstream now.

Just as a curiosity, which kernel version do you expect this change to be implemented?

I expect it to be merged in 1-2 release cycles.

Tim, I've been looking at your original error and it stated this:

[    0.006464] ACPI Error: [_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20170728/dswload-210)
[    0.006470] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20170728/psobject-252)

This is a bit concerning. It indicates that HS11 does not exist. From looking at the DSDT HS11 should be declared as a device. Device objects can be associated with many scope objects. The scope object is used to add different methods or named objects within the namespace of the device. I decided to grep your acpi tables for HS11 and found code that looked like this:

    If (LEqual (PCHV (), SPTH))
    {
        Scope (_SB.PCI0.XHC.RHUB)
        {
            Device (HS11)
            {
                ...
This code says if (LEqual (PCHV (), SPTH)) is true, then we add the HS11 device within the scope of _SB.PCI0.XHC.RHUB. It is very common to add devices conditionally so this is ok. However, at the bottom of the DSDT, I see something like this:
    Scope (_SB.PCI0.XHC.RHUB.HS11)
    {
         Device (CAM0)

This says that within the Scope of _SB.PCI0.XHC.RHUB.HS11, we create a device called CAM0. However, a scope object needs to be associated to some other named object. In this case, it should be associated with the HS11 device. The HS11 device was declared conditionally so there is a possibility that the HS11 or other devices declared within the _SB.PCI0.XHC.RHUB the was not added to the Namespace. We are looking at a few other issues right now but something tells me that this may be a firmware bug or something related to BIOS configuration.

Maybe very noob from my side: are the device abbreviations linkable to anything real? I mean, if I read your story from the bottom up, there is CAM0 (webcam?). In the XHC domain (=connected to USB?). Which then again is in the PCI0 domain (=PCI). Which is exactly the case in my laptop.

There is also a kill switch on the keyboard, that should interupt the webcam from BIOS. That could be the condition?

I remember reading something in the brochure of this system that it is a security / privacy feature. I never actually used the webcam, so I don't know if and how this works exactly.

If it makes sense to you, let me know and I can play around with the Killswitch and BIOS settings to see if anything changes.

Hi, Erik

That's a kind of commonly seen code in ASL.

If "If (LEqual (PCHV (), SPTH))" condition is not met, then "Scope (_SB.PCI0.XHC.RHUB.HS11)" beomes a fatal error with Windows interpreter.
So I guess it actually never fails.
Thus the table never fails on Windows, but on Linux, due to the wrong order of executing MLC, it fails as Linux requires the non-MLC ("Scope (_SB.PCI0.XHC.RHUB.HS11)") block to be interpreted before interpreting the MLC (the "If (LEqual (PCHV (), SPTH))") block.

All of these are seen to fail on windows -- with a blue-screen.

/* Blue-screens on windows
            If (1)
            {
                Device (DEVD) {}
            }
            Scope (DEVD)
            {
                Method (MTHD) {Return (0x1234)}
            }

/* Blue-screens on windows

            Name (INTD, 0)
            If (INTD)
            {
                Device (DEVD) {}
            }
            Scope (\_SB_.ABBU.DEVD)
            {
                Method (MTHD) {Return (0x1234)}
            }
*/

/* Blue-screens on windows
            Name (INTD, 1)
            If (INTD)
            {
                Device (DEVD) {}
            }
            Scope (\_SB_.ABBU.DEVD)
            {
                Method (MTHD) {Return (0x1234)}
            }
*/

by "blue-screen", I mean at table load time -- windows will not boot.

#17 could be an issue with the ABBU utility, however.

It looks like Windows *requires* a _HID under a device, else blue-screen.

For clarification, do all examples in comment #17 work if there is a _HID under the device?

To Bob

Can we do this with ABBU now?
I usually use qemu to confirm such table load time bahavior.
qemu allows to inject user tables and we can see Debug output on qemue console if it correctly link to the serial console using qemu serial console options.

Thanks
Lv

Hi!

I solved the problem by tweaking my bios with this link
http://s472165864.onlinehome.fr/anyware/index.php?dir=drivers/Clevo/N350DW/bios/

Everything is working !!

So bug closed as it can not be reproduced after BIOS upgrade.