On Fri, Mar 01, 2024 at 05:38:00PM +0300, aigilea wrote: > 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. I hope PR department of HP has a chance to read this...^^^ > On Fri, Mar 1, 2024 at 10:42 AM Mika Westerberg > <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > On Fri, Feb 16, 2024 at 04:46:10PM +0200, Mika Westerberg wrote: > > > On Fri, Feb 16, 2024 at 05:36:21PM +0300, aigilea wrote: > > > > 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. -- With Best Regards, Andy Shevchenko
