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 <[email protected]> [230526 00:19]: > Hi Nick, > > On Thu, May 25, 2023 at 08:23:15AM +0900, Nick Hastings wrote: > > Hi, > > > > * Salvatore Bonaccorso <[email protected]> [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
