Hello. Renaming the IC03 variable to the closest unused IC08 in the DSDT overlay indeed fixes the crash. Renaming/removing the device (as it looks like its only purpose is to trigger Windows update to install some HP software) might be a cleaner way but I'm not sure how to do this with overlays as this device is declared in one of SSDT tables under the widely used _SB_.PC00. For me personally this is good enough, but I'm not sure if it's a good solution for a general case. HP's attitude is unfortunate to say the least as the bug is so clear and the fix is so simple. We've only bought a trial batch of ten units, we'll return the ones that are still packed and go with some other vendor from now on. Thank you! On Fri, Mar 1, 2024 at 10:42 AM Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > Hi again, > > On Fri, Feb 16, 2024 at 04:46:10PM +0200, Mika Westerberg wrote: > > Hi, > > > > On Fri, Feb 16, 2024 at 05:36:21PM +0300, aigilea wrote: > > > 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? > > > > I understood HP did this fix to their BIOS but it might take some time > > to get the confirmation and the BIOS version (working on this). > > Unfortunately it turns out that HP only applied this fix for their Omen > Transcent system and apparently there is not going to be updates on any > other system that has this issue if it is not shipping with Linux :( > > So we probably need to figure out an alternative. The root cause is that > the HP BIOS accidentally a device and a variable with the same name IC03 > and that gets resolved to the device instead of the variable in the > _PS3() method where it calls Add(IC03, 1, 1). > > This was fixed by renaming the device into something else but I'm not > entirely sure how this could be fixed in the kernel side or ACPICA.
