Linking to http://bugs.acpica.org/show_bug.cgi?id=1372

So, if I understand well I have a 5 errors total, three of which seems to be similar. I’ve seen you’ve renamed the title of this bug and linked to another one, but I’m not sure whether it applies to all of the errors. Can you confirm that or should I open a new issue for some of them?

The first error:
[    0.980457] ACPI Error: Field [CAP1] at 96 exceeds Buffer [NULL] size 64 (bits) (20160930/dsopcode-236)
[    0.980463] ACPI Error: Method parse/execution failed [\_SB._OSC] (Node ffff88089ece3a78), AE_AML_BUFFER_LIMIT (20160930/psparse-543)

The group of three errors:
[   16.064416] ACPI Error: Needed [Buffer/String/Package], found [Integer] ffff880899840ee8 (20160930/exresop-594)
[   16.064420] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20160930/dswexec-461)
[   16.064423] ACPI Error: Method parse/execution failed [\_SB.WMIV.WVPO] (Node ffff88089eca6050), AE_AML_OPERAND_TYPE (20160930/psparse-543)
[   16.064428] ACPI Error: Method parse/execution failed [\_SB.WMIV.WMPV] (Node ffff88089eca66e0), AE_AML_OPERAND_TYPE (20160930/psparse-543)

[   16.065578] ACPI Error: Needed [Buffer/String/Package], found [Integer] ffff8808998405a0 (20160930/exresop-594)
[   16.065580] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20160930/dswexec-461)
[   16.065583] ACPI Error: Method parse/execution failed [\_SB.WMIV.WVPO] (Node ffff88089eca6050), AE_AML_OPERAND_TYPE (20160930/psparse-543)
[   16.065737] ACPI Error: Method parse/execution failed [\_SB.WMIV.WMPV] (Node ffff88089eca66e0), AE_AML_OPERAND_TYPE (20160930/psparse-543)

[   16.069308] ACPI Error: Needed [Buffer/String/Package], found [Integer] ffff880899840000 (20160930/exresop-594)
[   16.069311] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20160930/dswexec-461)
[   16.069315] ACPI Error: Method parse/execution failed [\_SB.WMIV.WVPO] (Node ffff88089eca6050), AE_AML_OPERAND_TYPE (20160930/psparse-543)
[   16.069484] ACPI Error: Method parse/execution failed [\_SB.WMIV.WMPV] (Node ffff88089eca66e0), AE_AML_OPERAND_TYPE (20160930/psparse-543)

The last one:
[   16.074170] ACPI Error: Attempt to CreateField of length zero (20160930/dsopcode-168)
[   16.074201] ACPI Error: Method parse/execution failed [\_SB.WMIV.WVPI] (Node ffff88089eca6fc8), AE_AML_OPERAND_VALUE (20160930/psparse-543)
[   16.074244] ACPI Error: Method parse/execution failed [\_SB.WMIV.WMPV] (Node ffff88089eca66e0), AE_AML_OPERAND_VALUE (20160930/psparse-543)

For this:
The first error:
[    0.980457] ACPI Error: Field [CAP1] at 96 exceeds Buffer [NULL] size 64 (bits) (20160930/dsopcode-236)
[    0.980463] ACPI Error: Method parse/execution failed [\_SB._OSC] (Node ffff88089ece3a78), AE_AML_BUFFER_LIMIT (20160930/psparse-543)

You should visit the ACPICA bug:
http://bugs.acpica.org/show_bug.cgi?id=1372

For the operand type issue, you can monitor this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=194671

Thanks
Lv

[    0.982293] ACPI Error: Field [CAP1] at 96 exceeds Buffer [NULL] size 64 (bits) (20160831/dsopcode-236)

This one appears to be a valid problem with the caller of the _OSC method (somewhere in the kernel).

I was able to reproduce it here easily with the DSDT provided and acpiexec:

- ex _SB._OSC (01) 00 02 (01, 02, 03, 04, 05, 06, 07, 08)
Evaluating \_SB._OSC ACPI Error: Field [CAP1] at 96 exceeds Buffer [NULL] size 64 (bits) (20170303/dsopcode-360)
[AcpiExec] Exception AE_AML_BUFFER_LIMIT during execution of method [_OSC] Opcode [CreateDWordField] @13 [_OSC] @0000F #008A:  CreateDWordField (Arg3, 0x08, CAP1)


This error is generated from last operator in this snippet of ASL code:

    Scope (_SB)
    {
        Name (OSCI, Zero)
        Name (OSCO, Zero)
        Name (OSCP, Zero)
        Method (_OSC, 4, Serialized)  // _OSC: Operating System Capabilities
        {
            CreateDWordField (Arg3, Zero, STS0)
            CreateDWordField (Arg3, 0x04, CAP0)
            CreateDWordField (Arg3, 0x08, CAP1)

The bottom line is that this _OSC method expects an input buffer (in Arg3) of 12 bytes, but the kernel is passing a buffer of only 8 bytes.

So, this report should be re-categorized, it is not an ACPICA issue.

As far as the WVPO and WMPV errors: As I recall, this is a known bug in the AML code, and is a duplicate of another report.

(In reply to Robert Moore from comment #4)
> …
> So, this report should be re-categorized, it is not an ACPICA issue.

OK, are there any supplemental debugging steps I should follow to help here?

> As far as the WVPO and WMPV errors: As I recall, this is a known bug in the
> AML code, and is a duplicate of another report.

Hum, the bug linked by Lv Zheng (https://bugzilla.kernel.org/show_bug.cgi?id=194671) is closed as firmware bug. Is that what a bug in AML code means? Or where you referencing another issue? There is also this one, HP laptop again: https://bugzilla.kernel.org/show_bug.cgi?id=194833. BIOS bug again, so I guess this is it.

This seems to be a widespread issue with recent HP laptop. I’ve found also https://bugzilla.kernel.org/show_bug.cgi?id=192151 (reporting something different, but same things present in the log) and a lot of others around the web, among which some reported to HP forums:

– https://h30434.www3.hp.com/t5/Desktop-Boot-and-Lockup/ACPI-error/td-p/5942489
– http://h30434.www3.hp.com/t5/Notebook-Operating-System-and-Recovery/acpi-error-with-linux/m-p/6021489/highlight/true#M477957

So I guess this part should be reported to HP, but how so? Do you have any specific contact over there?

Summary of what I understand: the first error should be tracked here, the last one is for ACPICA, and the remaining three in the middle are for HP.

OK no I misunderstood the last one, it’s HP too right?

> The bottom line is that this _OSC method expects an input buffer (in Arg3) of
> 12 bytes, but the kernel is passing a buffer of only 8 bytes.

OK, leaving this bug opened for this issue.
It then needs a a full dmesg to investigate.
Please upload the dmesg output.

Thanks
Lv

> So I guess this part should be reported to HP, but how so? Do you have any
> specific contact over there?

> Summary of what I understand: the first error should be tracked here, the
> last one is for ACPICA, and the remaining three in the middle are for HP.

Anyway WMI support is platform specific.
Even it is not a BIOS bug, it is a bug in platform specific drivers.
They are ACPI users, we don't support ACPI users that need platform specific knowledge.

So probably you should file such bugs to "platform specific/hardware" category to find right supporters.

(In reply to Lv Zheng from comment #8)
> > So I guess this part should be reported to HP, but how so? Do you have any
> > specific contact over there?
> 
> > Summary of what I understand: the first error should be tracked here, the
> > last one is for ACPICA, and the remaining three in the middle are for HP.
> 
> Anyway WMI support is platform specific.
> Even it is not a BIOS bug, it is a bug in platform specific drivers.
> They are ACPI users, we don't support ACPI users that need platform specific
> knowledge.
> 
> So probably you should file such bugs to "platform specific/hardware"
> category to find right supporters.

Opened https://bugzilla.kernel.org/show_bug.cgi?id=195237 as a follow-up for those WMI issues.

So this one is only about the _OSC caller error now.

Please upload the dmesg output.
Let's locate the culprit driver with full dmesg and kernel boot parameter "initcall_debug".

Thanks

Created attachment 256901 [details]
dmesg with initcall_debug

Here you go!

I’ve noticed something doing this, that might be unrelated but I wanted to ask anyway. At the beginning, there is this gap in time:
[    0.928004] ACPI : EC: EC started
[    0.928004] ACPI : EC: interrupt blocked
[    4.102854] ACPI: \_SB_.PCI0.LPCB.EC0_: Used as first EC
[    4.102856] ACPI: \_SB_.PCI0.LPCB.EC0_: GPE=0x6e, EC_CMD/EC_SC=0x66, EC_DATA=0x62
[    4.102857] ACPI: \_SB_.PCI0.LPCB.EC0_: Used as boot DSDT EC to handle transactions

Around 3.2s, over the 12s total boot time. And then, a bit after:
[    4.179430] ACPI : EC: interrupt unblocked
[    4.179435] ACPI : EC: event unblocked
[    4.179443] ACPI: \_SB_.PCI0.LPCB.EC0_: GPE=0x6e, EC_CMD/EC_SC=0x66, EC_DATA=0x62
[    4.179444] ACPI: \_SB_.PCI0.LPCB.EC0_: Used as boot DSDT EC to handle transactions and events
[    4.179487] initcall acpi_init+0x0/0x351 returned 0 after 3193359 usecs

And this duration indicated here is roughly those 3.2s. By looking around, I found a reference of people with an even greater gap (but without blocked message):

[ 0.738769] ACPI : EC: EC started
[ 10.459247] ACPI: \_SB_.PCI0.LPCB.EC0_: Used as first EC
[ 10.459248] ACPI: \_SB_.PCI0.LPCB.EC0_: GPE=0x6e, EC_CMD/EC_SC=0x66, EC_DATA=0x62
[ 10.459249] ACPI: \_SB_.PCI0.LPCB.EC0_: Used as boot DSDT EC to handle transactions

Here: https://h30434.www3.hp.com/t5/Notebook-Operating-System-and-Recovery/acpi-error-with-linux/td-p/6021489
But then I found https://bugzilla.kernel.org/show_bug.cgi?id=191561 which suggest that this has been partially fixed and the 3s delay is likely a perf issue, while the “blocked“ message was added by this same patch…

Should I open a new issue for this?

Hi,

According to the log below, this looks a BIOS issue:

[    0.923186] ACPI: Dynamic OEM Table Load:
[    0.923219] ACPI: SSDT 0xFFFF88089B0D6000 0005DC (v02 PmRef  Cpu0Ist  00003000 INTL 20121018)
[    0.923375] ACPI: \_PR_.CPU0: _OSC native thermal LVT Acked
[    0.923801] ACPI Error: Field [CAP1] at 96 exceeds Buffer [NULL] size 64 (bits) (20170119/dsopcode-236)
[    0.923807] ACPI Error: Method parse/execution failed [\_SB._OSC] (Node ffff88089ecdf208), AE_AML_BUFFER_LIMIT (20170119/psparse-543)

When dynamically load SSDT(PmRef/Cpu0Ist), the problem occurs.
You can upload "acpidump -a 0xFFFF88089B0D6000" result here for further validation.

For comment 11:
[    0.928004] ACPI : EC: interrupt blocked
[    4.179430] ACPI : EC: interrupt unblocked
This actually is the result of the perf tuning.
Without this, you should see greater delay.
No need to open another bug for perf tuning.

If you mean multiple _REG executions, you can upload a boot message with the following boot parameter:
acpi.trace_state=method acpi.trace_method_name=_SB.PCI0.LPCB.EC0._REG
You need to compile kernel with CONFIG_ACPI_DEBUG enabled.

Thanks
Lv

Trying to run `acpidump -a 0xFFFF88089B0D6000` leads to a killed task right away, and this appears in dmesg:
```
[48203.497399] acpidump: Corrupted page table at address 7fe03ac31000
[48203.504759] PGD 6e1166067 
[48203.504760] PUD 3fd970067 
[48203.509911] PMD 298e2f067 
[48203.514848] PTE ffff88089b0d6225

[48203.529023] Bad pagetable: 000d [#6] PREEMPT SMP
[48203.533200] Modules linked in: fuse sd_mod uas usb_storage ctr ccm mousedev hp_wmi sparse_keymap joydev mxm_wmi iTCO_wdt iTCO_vendor_support i2c_designware_platform i2c_designware_core intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm irqbypass intel_cstate intel_rapl_perf snd_hda_codec_conexant snd_hda_codec_generic input_leds psmouse arc4 iwlmvm nls_iso8859_1 nls_cp437 vfat mac80211 fat snd_hda_intel snd_hda_codec e1000e snd_hda_core ptp snd_hwdep pps_core snd_pcm snd_timer i2c_i801 snd soundcore iwlwifi rtsx_pci_ms cfg80211 memstick rfkill idma64 shpchp processor_thermal_device intel_soc_dts_iosf intel_pch_thermal intel_lpss_pci tpm_infineon i2c_hid thermal hid battery int3400_thermal acpi_thermal_rel int3403_thermal int340x_thermal_zone wmi hp_accel lis3lv02d input_polldev intel_lpss_acpi
[48203.542298]  led_class intel_lpss evdev ac tpm_tis mac_hid hp_wireless tpm_tis_core acpi_pad tpm sch_fq_codel coretemp msr bbswitch(O) ip_tables x_tables btrfs xor raid6_pq algif_skcipher af_alg dm_crypt dm_mod rtsx_pci_sdmmc mmc_core serio_raw atkbd libps2 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd ahci libahci xhci_pci nvme libata xhci_hcd nvme_core rtsx_pci scsi_mod usbcore usb_common i8042 serio i915 video button intel_gtt i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm crc32c_intel
[48203.551802] CPU: 7 PID: 26883 Comm: acpidump Tainted: G      D    O    4.11.3-1-ARCH #1
[48203.556401] Hardware name: HP HP ZBook Studio G3/80D4, BIOS N82 Ver. 01.16 04/14/2017
[48203.556402] task: ffff88031aeb6580 task.stack: ffffc900054f8000
[48203.556404] RIP: 0033:0x4016a6
[48203.556405] RSP: 002b:00007ffc7d43d3b0 EFLAGS: 00010202
[48203.556406] RAX: 00007fe03ac31000 RBX: 00007fe03ac31000 RCX: 0000000000000008
[48203.556407] RDX: 0000000000000001 RSI: 00007fe03ac31000 RDI: 0000000000405b84
[48203.556408] RBP: 0000000000000000 R08: 0000000000000003 R09: ffff88089b0d6000
[48203.556410] R10: 000000000000069b R11: 0000000000000246 R12: ffff88089b0d6000
[48203.556411] R13: 00007ffc7d43d420 R14: 0000000000000000 R15: 0000000000000000
[48203.556412] FS:  00007fe03ac0a4c0(0000) GS:ffff8808bf5c0000(0000) knlGS:0000000000000000
[48203.556413] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[48203.556414] CR2: 00007fe03ac31000 CR3: 00000003b2778000 CR4: 00000000003406e0
[48203.556415] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[48203.556415] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[48203.556416] RIP: 0x4016a6 RSP: 00007ffc7d43d3b0
[48203.591795] ---[ end trace 2ea3804fd8ee666b ]---
[48203.591890] x86/PAT: acpidump:26883 freeing invalid memtype [mem 0x8089b0d6000-0x8089b0d6fff]
```

My bad, possibly I gave you virtual address.
However this issue is not related to the loaded bug.
I noticed that it relates to drivers/acpi/acpi_processor.c.
As:

[    0.923375] ACPI: \_PR_.CPU0: _OSC native thermal LVT Acked
[    0.923801] ACPI Error: Field [CAP1] at 96 exceeds Buffer [NULL] size 64 (bits) (20170119/dsopcode-236)

It's called in acpi_hwp_native_thermal_lvt_osc().

Let me re-assign it to power/processor.

Thanks
Lv

Lv, this is not how the code runts

[    0.923375] ACPI: \_PR_.CPU0: _OSC native thermal LVT Acked

You're right that this is done in ACPI processor driver. But \_PR.CPU0._OSC is evaluated successfully!

[    0.980457] ACPI Error: Field [CAP1] at 96 exceeds Buffer [NULL] size 64 (bits) (20160930/dsopcode-236)
[    0.980463] ACPI Error: Method parse/execution failed [\_SB._OSC] (Node ffff88089ece3a78), AE_AML_BUFFER_LIMIT (20160930/psparse-543)

the error actually happens when evaluating \_SB._OSC, I'm not sure but likely in
acpi_bus_osc_support(), and please keeps on debugging this issue.

Created attachment 257341 [details]
Debugging patch to locate culprit

Hi,

Then please apply this debugging patch, recompile and boot the kernel.
Upload dmesg output here.

Thanks
Lv

Ping...

I'll close the bug, as no response.
If you want to continue, please re-open it.

Sorry for the huge delay… I suppose this is what you need:

[    0.317976] ACPI Error: Field [CAP1] at bit offset/length 64/32 exceeds size of target Buffer (64 bits) (20180105/dsopcode-235)
[    0.317976] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.16.3-1-ARCH #1
[    0.317976] Hardware name: HP HP ZBook Studio G3/80D4, BIOS N82 Ver. 01.14 09/07/2016
[    0.317976] Call Trace:
[    0.317976]  dump_stack+0x5c/0x85
[    0.317976]  acpi_ds_init_buffer_field+0x222/0x2af
[    0.317976]  acpi_ds_eval_buffer_field_operands+0x14b/0x176
[    0.317976]  acpi_ds_exec_end_op+0x383/0x6b7
[    0.317976]  acpi_ps_parse_loop+0x929/0x9d6
[    0.317976]  ? kmem_cache_alloc+0x19f/0x1b0
[    0.317976]  acpi_ps_parse_aml+0x1a2/0x4af
[    0.317976]  acpi_ps_execute_method+0x1ef/0x2ab
[    0.317976]  acpi_ns_evaluate+0x2e4/0x41d
[    0.317976]  acpi_evaluate_object+0x21a/0x3dd
[    0.317976]  ? acpi_ns_get_node_unlocked+0x1b1/0x1dc
[    0.317976]  ? set_debug_rodata+0x11/0x11
[    0.317976]  acpi_run_osc+0x131/0x290
[    0.317976]  ? up+0x12/0x60
[    0.317976]  ? acpi_os_signal_semaphore+0x41/0x80
[    0.317976]  ? acpi_ns_get_node+0xa3/0xae
[    0.317976]  ? set_debug_rodata+0x11/0x11
[    0.317976]  ? set_debug_rodata+0x11/0x11
[    0.317976]  ? acpi_sleep_proc_init+0x24/0x24
[    0.317976]  ? acpi_init+0x189/0x365
[    0.317976]  acpi_init+0x189/0x365
[    0.317976]  do_one_initcall+0x4e/0x190
[    0.317976]  kernel_init_freeable+0x171/0x1f3
[    0.317976]  ? rest_init+0xd0/0xd0
[    0.317976]  kernel_init+0xa/0x100
[    0.317976]  ret_from_fork+0x35/0x40
[    0.317976] ACPI Error: Method parse/execution failed \_SB._OSC, AE_AML_BUFFER_LIMIT (20180105/psparse-550)


Note that I will be upgrading the BIOS of this laptop sometime next week in case that matters.

The BIOS update could change these errors. Let's for this BIOS update. If there are still errors, please attach the new dmesg. Also, It would be wonderful if you could do this with 4.17rc1 or later because we've made some changes to the interpreter behavior starting with this kernel version.

Hi,

Just to keep you updated, I experienced a failure of my backup system, which will take me time to resetup and check. And I cannot take the risk of upgrading the BIOS in this state, because the last time I did upgrade to this BIOS version on this laptop, the motherboard had to be subsequently replaced…

I’ll keep you posted when everything will be in order and that I would have been able to upgrade my BIOS and test using the new kernel.

Ok. I'll close this issue for now. Please feel free to reopen once you're ready.

Created attachment 276693 [details]
dmesg output, 4.17.2

So, I’m back on track.

I’ve attached the new dmesg output, using kernel 4.17.2. I did not have initcall_debug on, please tell me if you want a new one with it.

Thanks for this report. What's going on here is that the WVPO control method is doing this inside the WVPO method:

FRTC = DerefOf (Arg1 [Zero])

This would work if Arg1 is a package or a buffer. However, Arg1 is an integer at runtime so this results in the runtime error that you see in the dmesg (copied below)

[   13.912977] ACPI Error: Needed [Buffer/String/Package], found [Integer] 00000000468c1e6d (20180313/exresop-560)
[   13.913048] ACPI Error: AE_AML_OPERAND_TYPE, While resolving operands for [Index] (20180313/dswexec-427)
[   13.913100] ACPI Error: Method parse/execution failed \_SB.WMIV.WVPO, AE_AML_OPERAND_TYPE (20180313/psparse-516)

I would try updating your firmware or contacting your firmware vendor or HP for a fix. This is an issue in the ACPI firmware for your machine rather than linux ACPI or ACPICA. Closing.

I’m not sure if I’m misunderstanding something, but I think you lost track of what this issue is about. We have already determined that WMIV errors are on the manufacturer side, this issue is about:
[    0.287172] ACPI Error: Method parse/execution failed \_SB._OSC, AE_AML_BUFFER_LIMIT (20180313/psparse-516)

Which is happening way earlier and for which I’ve added the debug dump as requested per #c17.

If I’m wrong and your last comment is really about this error, then feel free to close again.

Created attachment 277341 [details]
change buffer length from 8 to 12

Hi, sorry to take so long to get back to you. Could you try this patch? It should get rid of the _OSC error and complies with the ACPI spec.

(In reply to Erik Schmauss from comment #26)
> Created attachment 277341 [details]
> change buffer length from 8 to 12
> 
> Hi, sorry to take so long to get back to you. Could you try this patch? It
> should get rid of the _OSC error and complies with the ACPI spec.

Apologies. I read the ACPI specification wrong. It turns out that this is a bug in the firmware. You need to contact HP to fix this.

Here's what's going on: \_SB._OSC requests a buffer of size 12. However, this function should only be expecting a buffer of size 8 in the 4th parameter (arg3) of \_SB._OSC. The easy fix is to remove the 2 lines creating/using CAP1. I think they got this confused with \_SB.PCI0._OSC called with a UUID of 33DB4D5B-1FF7-401C-9657-7441C03DD766. \_SB.PCI0._OSC with the above UUID expects arg3 to be of size 12. I'm going to close this as it's a bug in the firmware.