_DSM is device specific.
In ACPI spec, it is:

9.1.1 _DSM (Device Specific Method)
This optional object is a control method that enables devices to provide device specific control functions that are consumed by the device driver.
Arguments: (4)
Arg0 – A Buffer containing a UUID
Arg1 – An Integer containing the Revision ID
Arg2 – An Integer containing the Function Index
Arg3 – A Package that contains function-specific arguments

This is quite like a BIOS bug according to the information above.

But it seems ACPICA requires _DSM to be 4 arguments:
    {{"_DSM",   METHOD_4ARGS (ACPI_TYPE_BUFFER, ACPI_TYPE_INTEGER, ACPI_TYPE_INTEGER, ACPI_TYPE_PACKAGE),
                METHOD_RETURNS (ACPI_RTYPE_ALL)}}, /* Must return a value, but it can be of any type */
And the error message indicates that ACPICA requires 3 arguments.

So I need to ask:
1. Which kernel are you using?
2. Please upload the acpidump and full dmesg boot log here.

Thanks
Lv

This is with 4.9.  I didn't notice these errors in 4.8 but I can't guarantee that without installing it again.  I will upload the logs this evening.

Created attachment 249931 [details]
dmesg output

Created attachment 249941 [details]
adpidump output

(In reply to Adam Pigg from comment #2)
> This is with 4.9.  I didn't notice these errors in 4.8 but I can't guarantee
> that without installing it again.  I will upload the logs this evening.

My fault.
It's _DSW, not _DSM.
There should be 3 arguments for it:
Arguments: (3)
Arg0 – An Integer that contains the device wake capability control
0 – Disable the device’s wake capabilities
1 – Enable the device’s wake capabilities
Arg1 – An Integer that contains the target system state (0-4)
Arg2 – An Integer that contains the target device state
0 – The device will remain in state D0
1 – The device will be placed in either state D0 or D1
2 – The device will be placed in either state D0, D1, or D2
3 – The device will be placed in either state D0, D1, D2, or D3
Return Value:
None

And decompiled ASL shows:
	Line 8882:                 Method (_DSW, 1, NotSerialized)  // _DSW: Device Sleep Wake
	Line 8882:                 Method (_DSW, 1, NotSerialized)  // _DSW: Device Sleep Wake
	Line 9461:                 Method (_DSW, 1, NotSerialized)  // _DSW: Device Sleep Wake
	Line 9461:                 Method (_DSW, 1, NotSerialized)  // _DSW: Device Sleep Wake

So this is really a BIOS problem.
I suggest you to contact vendor to correct it.

Thanks and best regards
Lv

Im not exactly confident about getting a fix from HP, on the grounds im sure they will only support Win10.  Ive posted on the support forum here http://h30434.www3.hp.com/t5/Notebook-Software-and-How-To-Questions/HP-star-wars-an000na-faulty-BIOS-uefi-ACPI-implementation/td-p/5922133.

Is there any possible work-arounds that can be done in the kernel?  In the past ive had workarounds created for a buggy Toshiba acpi.

The laptop suffers from bug https://bugzilla.kernel.org/show_bug.cgi?id=108801 where it doesnt correctly sleep (sometimes reboots when going to sleep) could this be related?

Yes, we can provide workaround.
But it is better to have some proofs about Windows behavior.
For example,
You need to get amli working for your Windows.
And capture the amli log to prove that 1 argument _DSW(s) are correctly evaluated by Windows AML interpreter.

Otherwise, skipping sanity checks would be used by malicious software to create security holes via Linux ACPI support.

Thanks
Lv

As you wishes.
Re-open it and wait for amli proofs.

Thanks
Lv

Hi

Can you give any guidance on getting the AMLI log?

I have got windows running, with WinDbg, and enabled kernel debugging by turning off secure boot.

I can get the amli commands up, but they don't work, eg:

lkd> !amli dl
AMLI_DBGERR: failed to to get the address of ACPI!gDebugger

lkd> !amli set traceon
AMLI_DBGERR: failed to to get the address of ACPI!gDebugger 0
AMLI_DBGERR: failed to to get the address of ACPI!gdwfAMLIInit 0

Thanks

You need to install a checked build windows.
Otherwise AMLi is not available.
See this page:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff551079(v=vs.85).aspx

At least you need to obtain the checked build acpi.sys to replace your platform one.

Then in AMLi session, you need to find a way to trigger _DSW execution and save the _DSW execution log from AMLi window.
The log could explain the way Windows executes the _DSW (converts wrong argument or not) and then we can add similar support in Linux.

(In reply to Lv Zheng from comment #10)
> You need to install a checked build windows.
> Otherwise AMLi is not available.
> See this page:
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff551079(v=vs.85).
> aspx
> 
> At least you need to obtain the checked build acpi.sys to replace your
> platform one.

If you have DDK experiences, comparing to the "free build" which are installed on your normal Windows clones, "checked build" of kernel modules means linking against the core kernel modules that have debugging symbols/logs enabled. And such checked build core modules surely can therefore contain special debugging facilities that are not released in the "free build".

That looks like it will be a fun undertaking!

In the mean time, i found references to another hp model with the same issue.

http://h30434.www3.hp.com/t5/Notebook-Boot-and-Lockup/Cannot-power-on-more-than-once-without-removing-battery/td-p/5664659

Also, i wondered, would the symantics of a single argument not be the same as the obsoleted _PSW method that DSW replaces?

ping...

> Also, i wondered, would the symantics of a single argument not be the same as
> the obsoleted _PSW method that DSW replaces?

I can only find the following from the spec, which doesn't say Arg1 & 2 are optional:

Compatibility Note: The _PSW method is deprecated in ACPI 3.0. The _DSW method should be used instead. OSPM will only use the _PSW method if OSPM does not support _DSW or if the _DSW method is not present.

Changing ACPICA to adopt this should be very easy.
However is there any progress of validated Windows behaviors?

Thanks
Lv

No progress on windows behaviour.  TBH, i think its out of my skill range, ive no experience in windows driver development/debugging, i stick to desktop and mobile apps! :)

What i meant about the arguments, is that DSW obsoletes PSW, and the first argument of each is the same (enable/disable wake capability).  So, in the case where an invalid implementation of DSW like mine only expects one argument, is it safe to assume the implementation should jst do the same as a call to PSW?

There is no such exception in predefined methods over so many years.
And there are no spec statements mentioning an optional arguments of the predefined control methods.

So I'm not sure if ACPICA can be changed without knowing Windows behavior.
Let's close this bug as documented.
You can re-open it if you had more useful information.

Ok, there don't seem to be any side effects (what does acpica do in this situation?) Since kernel 4.10 I've had no issues sleeping/resuming, before that it would routinely reboot after resuming, but its worked 100% for weeks now.