linux-kernel - Re: Cannot boot with rootfs from eMMC if maxcpus=1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <db88991b-d7eb-4fc3-6c33-7ee3ba6671fc@infradead.org>
Date:   Sat, 18 Nov 2017 10:44:52 -0800
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Richard Schmitt <rschmitt@...epeach.com>,
        linux-kernel@...r.kernel.org
Subject: Re: Cannot boot with rootfs from eMMC if maxcpus=1

On 11/09/2017 08:14 AM, Richard Schmitt wrote:
> Using a 4.9 kernel, trying to boot a kernel using an eMMC based rootfs will result in a crash
> 
> The message preceeding the crash is:
> 
> [    3.285566] VFS: Cannot open root device "mmcblk0p9" or unknown-block(0,0): error -6
> [    3.293338] Please append a correct "root=" boot option; here are the available partitions:
> 
> Our kernel boot args can be seen in the boot log but for easy reference are:
> 
>  root=/dev/mmcblk0p9 earlycon clk_ignore_unused cpuidle.off=1 DEBUG_MODE=y siq_board_type=RP maxcpus=1
> 
> Note that we do specify root=/dev/mmcblk0p9.  If I simply remove maxcpus=1 from the kernel boot args, the system will boot up fine.
> 
> Seems like there might be a race in bringing up the eMMC partitions prior to mounting the rootfs but I don’t want to hypothesis any further.
> 
> Any ideas?

If you suspect a timing issue, an easy test would be to add to the kernel
boot/command line either:
  rootwait
or
  rootdelay=10
(in seconds) to see if that helps.


or send email to linux-arm-kernel@...ts.infradead.org ...

-- 
~Randy