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@xxxxxxxxxx> wrote:
On Fri, 30 Oct 2020 at 23:04, Vicente Bergas <vicencb@xxxxxxxxx> 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
