Re: Kernel panic in ACPICA on HP Spectre X360 (Meteor Lake 155H) laptop

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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@linux.intel.com> 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