[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1036530: linux-signed-amd64: Hard lock up of system



Hi Salvatore,

thanks for your help. However, I'm now not sure if I really have
identified the commit that causes my problems. I fear I may have made
one or more mistakes when setting "git bisect good". I had been under
the impression that the lock up would happen no more than a few tens of
minutes after booting, however it seems that sometimes it can take a few
hours to occur.

So, I'm running the git bisect again and will be more careful before
marking "git bisect good". It could take a few days.

Should this particular bug be closed?

Thanks,

Nick.


* Salvatore Bonaccorso <carnil@debian.org> [230526 00:19]:
> Hi Nick,
> 
> On Thu, May 25, 2023 at 08:23:15AM +0900, Nick Hastings wrote:
> > Hi,
> > 
> > * Salvatore Bonaccorso <carnil@debian.org> [230524 19:26]:
> > >
> > > Given you were able to bisect it so far, can you try to isolate the
> > > commit from the merge commit causing it?
> > 
> > I guess I can try. The commit message states:
> > 
> > Merge: c77f54a9bcec a1cf1fd62ae7 562163595a91 018d6711c26e 6cc401be1648
> > 
> > Is there a way extract out each of those?
> 
> Th way i usuually get all commits from a merge request is
> 
> git log --oneline $mergecommit^$mergecommit^2
> 
> though here we have three merge commits, merged with one merge commit
> on top, so you would go down the merges of the acpi-properties,
> acpi-tables, acpi-x86 and acpi-soc branches. Those are those:
> 
>     * acpi-properties:
>       ACPI: property: Silence missing-declarations warning in apple.c
> 
>     * acpi-tables:
>       ACPI: HMAT: Drop unused dev_fmt() and redundant 'HMAT' prefix
>       ACPI: tables: FPDT: Don't call acpi_os_map_memory() on invalid phys address
> 
>     * acpi-x86:
>       ACPI: x86: Add a quirk for Dell Inspiron 14 2-in-1 for StorageD3Enable
> 
>     * acpi-soc:
>       ACPI: LPSS: Deduplicate skipping device in acpi_lpss_create_device()
>       ACPI: LPSS: Replace loop with first entry retrieval
> 
> > > One remotely related might be "ACPI: x86: Add a quirk for Dell
> > > Inspiron 14 2-in-1 for StorageD3Enable".
> > 
> > Manually looking at the diff with
> > git diff e996c7e01892ac18ec0db447294d4f591c325efe~  e996c7e01892ac18ec0db447294d4f591c325efe 
> > I guess that means the following:
> > 
> > --- a/drivers/acpi/x86/utils.c
> > +++ b/drivers/acpi/x86/utils.c
> > @@ -207,9 +207,26 @@ static const struct x86_cpu_id storage_d3_cpu_ids[] = {
> >         {}
> >  };
> >  
> > +static const struct dmi_system_id force_storage_d3_dmi[] = {
> > +       {
> > +               /*
> > +                * _ADR is ambiguous between GPP1.DEV0 and GPP1.NVME
> > +                * but .NVME is needed to get StorageD3Enable node
> > +                * https://bugzilla.kernel.org/show_bug.cgi?id=216440
> > +                */
> > +               .matches = {
> > +                       DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> > +                       DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 14 7425 2-in-1"),
> > +               }
> > +       },
> > +       {}
> > +};
> > +
> >  bool force_storage_d3(void)
> >  {
> > -       return x86_match_cpu(storage_d3_cpu_ids);
> > +       const struct dmi_system_id *dmi_id = dmi_first_match(force_storage_d3_dmi);
> > +
> > +       return dmi_id || x86_match_cpu(storage_d3_cpu_ids);
> >  }
> 
> That probably won't work actually as the code has been refactored
> substantiantly after the commit. 
> 
> In the ideal case we could confirm the quirk change is the responsable
> commit, so we can make upstream aware.
> 
> Regards,
> Salvatore


Reply to: