Hi. Booting with "modprobe.blacklist=intel_lpss_pci" on the kernel command line indeed works around this panic. I will try to find out what hardware depends on this driver. Two years ago there was a similar issue with broken soundwire devices configuration in dsdt on tiger lake iteration of this laptop, it is not fixed by HP to this day. SOF guys in Intel ended up making a quirk for that case. So if the quirk (or some additional checks in parser?) path is not suitable for this issue I guess the most "proper" fix might be acpi overlay? Thanks! On Fri, Feb 16, 2024 at 3:02 PM Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > Hi, > > On Fri, Feb 16, 2024 at 10:33:00AM +0300, aigilea wrote: > > Hello. > > I've run into a problem with ACPI while trying to run any linux > > distribution on "HP Spectre x360 14 inch 2-in-1 Laptop PC 14-eu0000" with > > the latest BIOS "F.05 Rev.A" with kernel versions from 6.5 to 6.7. > > During the boot or shortly after kernel spits out a crash backtrace > > originating at "acpi_ps_get_arg" called from "acpi_ps_delete_parse_tree" > > or at "acpi_ps_delete_parse_tree" itself. > > It usually results in a panic and the system is halted but in some rare > > cases it continues to work for some random period of time so I was able to > > collect some debugging information. > > I'm attaching parts of the log I've got booting Arch 2024.01 liveusb with > > kernel 6.6.8 with the following command line: > > acpi.debug_layer=0x30 acpi.debug_level=0x880640 log_buf_len=256M > > dyndbg="file device_pm.c +p" > > Layer is ACPI_PARSER | ACPI_NAMESPACE, level is ACPI_LV_PARSE_TREES | > > ACPI_LV_EVALUATION | ACPI_LV_NAMES | ACPI_LV_EXEC | ACPI_LV_PARSE > > I wasn't able to boot more recent kernels to a working state to collect > > the log but they panic in the very same code. > > Log part with crash starts at "ACPI: \_SB_.PC00.I2C3: PM: Power state > > change: D0 -> D3cold" because I think this is what triggers the problem > > and the crash happens after what looks like a double call of > > "ps_delete_parse_tree" from "ps_pop_scope" with the same subtree_root arg > > which should result in use-after-free and a double free. > > We have seen similar and I think this should be fixed in the BIOS side > but I'm checking internally if this is the case or what was the > conclusion. > > Temporary workaround is to blacklist intel_lpss_pci driver (although you > may lose some of that functionality then but that's still better than > completely non-functional system).
