[regression, bisected] no MMC on rk3399-gru-kevin with 5.10-rc1
vicencb at gmail.com
Mon Nov 2 16:19:12 EST 2020
Hi Uffe, Doug,
On Monday, November 2, 2020 4:38:38 PM CET, Doug Anderson wrote:
> On Mon, Nov 2, 2020 at 7:02 AM Ulf Hansson <ulf.hansson at linaro.org> wrote:
>> On Fri, 30 Oct 2020 at 23:04, Vicente Bergas <vicencb at gmail.com> wrote:
>>> 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:
> 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
> I will also note that I just put v5.10-rc1 on a rk3399-gru-kevin and
> confirmed that it booted up OK.
More information about the Linux-rockchip