please attach the acpidump output.

Created attachment 293881 [details]
Output of `acpidump`

It’s still happening with system firmware 1.10.1 and Linux 5.16.7.

Hmm, below is the dump of the BTPR power resource.
                PowerResource (BTPR, 0x00, 0x0000)
                {
                    Method (_STA, 0, NotSerialized)  // _STA: Status
                    {
                        If ((\_SB.GBTR () == One))
                        {
                            Return (One)
                        }
                        Else
                        {
                            Return (Zero)
                        }
                    }

                    Method (_ON, 0, Serialized)  // _ON_: Power On
                    {
                        \_SB.BTRK (One)
                    }

                    Method (_OFF, 0, Serialized)  // _OFF: Power Off
                    {
                        \_SB.BTRK (Zero)
                    }
                }

Both GBTR and BTRK methods only contain some memory accesses.
Can not explain why it takes such a long time.

Zhang, thank you for looking into this.

Does Intel have access to such a device, or arrange some access to reproduce the issue?

What ACPI debug settings would I need to see timing data for the GBTR and BTRK calls?

There is a way to dump the method executing start and end time via acpi.debug_layer/acpi.debug_level command, but that would introduce tons of unrelated messages.

Let me check with @Todd first to see if we can leverage bootgraph tool.

> Let me check with @Todd first to see if we can leverage bootgraph tool.

That is using ftrace to my knowledge. If you tell me the function to trace, I can do that, the next time the user can give me access to the device, which is not very convenient as that is the work system.

you can try acpi_add_power_resource() first.

For the record, this is still problem with the latest firmware 1.23.0:

```
[    0.000000] Linux version 6.1.0-5-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15)
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.1.0-5-amd64 root=UUID=c9342a55-b747-4442-b2f4-bc03eb7a51cf ro quiet noisapnp log_buf_len=2M cryptomgr.notests btusb.enable_autosuspend=y random.trust_cpu=on drm
.debug=0xe log_buf_len=8M
[…]
[    0.000000] SMBIOS 3.2.1 present.
[    0.000000] DMI: Dell Inc. Precision 3540/0M14W7, BIOS 1.23.0 12/19/2022
[    0.000000] tsc: Detected 2100.000 MHz processor
[    0.000000] tsc: Detected 2099.944 MHz TSC
[…]
[    0.277538] PCI: Using E820 reservations for host bridge windows
[    0.277951] ACPI: Enabled 11 GPEs in block 00 to 7F
[    0.281658] ACPI: PM: Power Resource [PXP]
[    0.282945] ACPI: PM: Power Resource [PC05]
[    0.698385] ACPI: PM: Power Resource [BTPR]
[    0.699202] ACPI: PM: Power Resource [USBC]
[    0.699339] ACPI: PM: Power Resource [PAUD]
[    0.701282] ACPI: PM: Power Resource [V0PR]
[    0.701376] ACPI: PM: Power Resource [V1PR]
[    0.701465] ACPI: PM: Power Resource [V2PR]
[    0.704851] ACPI: PM: Power Resource [WRST]
[    0.713813] ACPI: PM: Power Resource [PIN]
[    0.714078] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7e])
[…]
[    0.844385] microcode: sig=0x806ec, pf=0x80, revision=0xf0
[    0.844579] microcode: Microcode Update Driver: v2.2.
[…]
```