Hi,
On 1/15/21 1:49 AM, Pierre-Louis Bossart wrote:
> Thanks Hans for your reply, much appreciated.
>
>> Pierre-Louis, can you see if the following hack helps? :
>>
>> --- a/drivers/acpi/scan.c
>> +++ b/drivers/acpi/scan.c
>> @@ -1939,7 +1939,6 @@ static acpi_status acpi_bus_check_add(acpi_handle handle, bool check_dep,
>> /* Bail out if the number of recorded dependencies is not 0. */
>> if (count > 0) {
>> acpi_bus_scan_second_pass = true;
>> - return AE_CTRL_DEPTH;
>> }
>> }
>> @@ -1948,8 +1947,7 @@ static acpi_status acpi_bus_check_add(acpi_handle handle, bool check_dep,
>> return AE_CTRL_DEPTH;
>> acpi_scan_init_hotplug(device);
>> - if (!check_dep)
>> - acpi_scan_dep_init(device);
>> + acpi_scan_dep_init(device);
>> out:
>> if (!*adev_p)
>
> Yep, those 'hacks' solve the boot problem on my device. I tried multiple times and it's completely reproducible.
Ok, so this confirms my earlier findings (with my personal 5.10 + cherry pick tree)
that the problem is not doing 2 scan "rounds" and thus calling e.g.
acpi_bus_attach twice. But the problem is rather with deferring the device-creation
of some devices to the second step.
>> And can you collect an acpidump from the device and either send it to me and Rafael
>> offlist, or upload it somewhere and send us a link ?
>
> will do
2 more questions, for me on the device where I can recreate this the problem only
happens intermittently. Since you did a successful bisect, I assume that when the
boot fails, it fails every boot, right? Do you have any special kernel debugging
options enabled, e.g. CONFIG_PAGE_POISONING, which might explain why for you it is
100% reproducable while for me it is intermittent ?
Also may I ask what the exact model is of the Zotac device you are seeing this on?
(the DMI strings are not helpful with this)
Regards,
Hans
