On Fri, Jan 15, 2021 at 3:52 PM Pierre-Louis Bossart
<pierre-louis.bossart@xxxxxxxxxxxxxxx> wrote:
>
>
> >> Yep, those 'hacks' solve the boot problem on my device. I tried multiple
> >> times and it's completely reproducible.
> >>
> >>> 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
> >
> > In addition to what Hans asked for, can you please build the kernel with the
> > debug patch below applied (instead of the Hans' debug patch), try to boot
> > the affected machine with it and see what is missing with respect to booting
> > the kernel with the two problematic commits reverted?
>
> Sorry, not following. Are you asking me to apply the patch below as well
> as revert the two problematic commits? Or just the patch below?
Just the patch below.
> the boot process is stuck without the reverts and I don't have a serial link to
> see what happens (closed form-factor).
The point is that the patch below may unstuck it, in which case it
should be possible to find out what is missing with respect to the
full successful boot.
> > Also please send me the outout of "dmesg | grep "Enumeration" from the debug
> > kernel if possible. >
> > ---
> > drivers/acpi/scan.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Index: linux-pm/drivers/acpi/scan.c
> > ===================================================================
> > --- linux-pm.orig/drivers/acpi/scan.c
> > +++ linux-pm/drivers/acpi/scan.c
> > @@ -1951,7 +1951,7 @@ static acpi_status acpi_bus_check_add(ac
> > u32 count = acpi_scan_check_dep(handle);
> > /* Bail out if the number of recorded dependencies is not 0. */
> > if (count > 0) {
> > - acpi_bus_scan_second_pass = true;
> > + acpi_handle_info(handle, "Enumeration skipped\n");
> > return AE_CTRL_DEPTH;
> > }
> > }
> >
> >
> >
