Re: ACPI scan regression -> Boot fail on Cherrytrail w/ 5.11-rc3

[Hans de Goede <hdegoede@redhat.com>]

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