[regression, bisected] no MMC on rk3399-gru-kevin with 5.10-rc1

[regression, bisected] no MMC on rk3399-gru-kevin with 5.10-rc1

[Vicente Bergas]

Hi,
commit 21b2cec61c04bd175f0860d9411a472d5a0e7ba1
mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4
broke booting rk3399-gru-kevin.

The kernel waits forever for the root device to appear on MMC.
Removing the line containing PROBE_PREFER_ASYNCHRONOUS in
drivers/mmc/host/dw_mmc-rockchip.c fixes the issue.

Regards,
  Vicente.


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [regression, bisected] no MMC on rk3399-gru-kevin with 5.10-rc1

[Ulf Hansson]

On Fri, 30 Oct 2020 at 23:04, Vicente Bergas <vicencb@gmail.com> wrote:
>
> Hi,
> commit 21b2cec61c04bd175f0860d9411a472d5a0e7ba1
> mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4
> broke booting rk3399-gru-kevin.
>
> The kernel waits forever for the root device to appear on MMC.

Waiting forever sounds weird to me.

> Removing the line containing PROBE_PREFER_ASYNCHRONOUS in
> drivers/mmc/host/dw_mmc-rockchip.c fixes the issue.

I am guessing when we enable async probe, we reveal some other
existing error. Or, perhaps the rootfs mount point become wrong?

Would it be possible to share a boot log (before/after) with some
driver probe debugging enabled?

Kind regards
Uffe

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [regression, bisected] no MMC on rk3399-gru-kevin with 5.10-rc1

[Doug Anderson]

Hi,

On Mon, Nov 2, 2020 at 7:02 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Fri, 30 Oct 2020 at 23:04, Vicente Bergas <vicencb@gmail.com> wrote:
> >
> > Hi,
> > commit 21b2cec61c04bd175f0860d9411a472d5a0e7ba1
> > mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4
> > broke booting rk3399-gru-kevin.
> >
> > The kernel waits forever for the root device to appear on MMC.
>
> Waiting forever sounds weird to me.
>
> > Removing the line containing PROBE_PREFER_ASYNCHRONOUS in
> > drivers/mmc/host/dw_mmc-rockchip.c fixes the issue.
>
> I am guessing when we enable async probe, we reveal some other
> existing error. Or, perhaps the rootfs mount point become wrong?
>
> Would it be possible to share a boot log (before/after) with some
> driver probe debugging enabled?

Are you sure you haven't just got your MMC block IDs shuffled now?
Perhaps a careful application of the newly-supported MMC aliases would
help fix things?  When we landed, Ulf pointed to:

[1]
https://patchwork.kernel.org/patch/11747669/
https://patchwork.kernel.org/patch/11747671/

The async probe can cause shuffling of block IDs which were previously
quite stable though never guaranteed (everyone always yelled loudly
"use UUIDs").

I will also note that I just put v5.10-rc1 on a rk3399-gru-kevin and
confirmed that it booted up OK.

-Doug



-Doug

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [regression, bisected] no MMC on rk3399-gru-kevin with 5.10-rc1

[Vicente Bergas]

Hi Uffe, Doug,

On Monday, November 2, 2020 4:38:38 PM CET, Doug Anderson wrote:
> Hi,
>
> On Mon, Nov 2, 2020 at 7:02 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> 
>> On Fri, 30 Oct 2020 at 23:04, Vicente Bergas <vicencb@gmail.com> wrote:
>>> 
>>> Hi,
>>> commit 21b2cec61c04bd175f0860d9411a472d5a0e7ba1
>>> mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4
>>> broke booting rk3399-gru-kevin.
>>> 
>>> The kernel waits forever for the root device to appear on MMC.
>> 
>> Waiting forever sounds weird to me.

The behaviour is expected because of the "rootwait" kernel parameter.

>>> Removing the line containing PROBE_PREFER_ASYNCHRONOUS in
>>> drivers/mmc/host/dw_mmc-rockchip.c fixes the issue.
>> 
>> I am guessing when we enable async probe, we reveal some other
>> existing error. Or, perhaps the rootfs mount point become wrong?
>> 
>> Would it be possible to share a boot log (before/after) with some
>> driver probe debugging enabled?
>
> Are you sure you haven't just got your MMC block IDs shuffled now?
> Perhaps a careful application of the newly-supported MMC aliases would
> help fix things?  When we landed, Ulf pointed to:
>
> [1]
> https://patchwork.kernel.org/patch/11747669/
> https://patchwork.kernel.org/patch/11747671/
>
> The async probe can cause shuffling of block IDs which were previously
> quite stable though never guaranteed (everyone always yelled loudly
> "use UUIDs").

I've got UUIDs everywhere (fstab and on other machines without root on MMC)
except in the "root" kernel parameter in rk3399-gru-kevin and, as you say,
the device path changed causing the issue.

So, false alarm, this is not a bug.
Still, those MMC aliases providing reliable device naming are really
welcome.

Regards,
  Vicente.

> I will also note that I just put v5.10-rc1 on a rk3399-gru-kevin and
> confirmed that it booted up OK.
>
> -Doug


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip