From patchwork Wed Sep 17 13:47:06 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Russell King - ARM Linux X-Patchwork-Id: 4924561 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id AF8B0BEEA5 for ; Wed, 17 Sep 2014 13:49:59 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4B1D820138 for ; Wed, 17 Sep 2014 13:49:58 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4775A20121 for ; Wed, 17 Sep 2014 13:49:53 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XUFaO-0004sh-GA; Wed, 17 Sep 2014 13:47:56 +0000 Received: from pandora.arm.linux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1XUFaK-0004XE-Qq for linux-arm-kernel@lists.infradead.org; Wed, 17 Sep 2014 13:47:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arm.linux.org.uk; s=pandora-2014; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=vhvN+Osf4hI1AW0YvFUrkzZKiqxKkEgEej4mJt/8QG8=; b=iWKyTFbBDjlSfBrzQ/coNrsJt8YMzQVRUNvp0WVmE45zX4XhzFradTckiaaqfeTj49spd6LWUGAmA3nmRi5WUw3IJXkc6vx46Ncy7wML2jNh+sIUw1CXD9oUyUzoNyQTiQL/tJ5/zbLLWQMJGZ4G7O6OasKnzz3OqsktWPt8c3U=; Received: from n2100.arm.linux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:4f86]:36789) by pandora.arm.linux.org.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XUFZf-0005vj-5t; Wed, 17 Sep 2014 14:47:11 +0100 Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.76) (envelope-from ) id 1XUFZb-0001Ah-3w; Wed, 17 Sep 2014 14:47:07 +0100 Date: Wed, 17 Sep 2014 14:47:06 +0100 From: Russell King - ARM Linux To: Pavel Machek , Paul Gortmaker , Andrew Morton , Linus Torvalds Subject: Re: 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails Message-ID: <20140917134706.GT12361@n2100.arm.linux.org.uk> References: <1405397216-909-1-git-send-email-dinguyen@altera.com> <53C4D874.2040206@samsung.com> <20140814184710.GA11558@amd.pavel.ucw.cz> <53ED2262.50604@gmail.com> <20140814210252.GB26857@amd.pavel.ucw.cz> <20140826114707.GA16372@amd> <20140909114941.GE15404@amd> <20140917132002.GS12361@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140917132002.GS12361@n2100.arm.linux.org.uk> User-Agent: Mutt/1.5.19 (2009-01-05) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140917_064753_280353_9BF26825 X-CRM114-Status: GOOD ( 36.98 ) X-Spam-Score: -0.8 (/) Cc: Kevin Hilman , Dinh Nguyen , Arnd Bergmann , kernel list , Jaehoon Chung , arm@kernel.org, "linux-arm-kernel@lists.infradead.org" , Olof Johansson , Dinh Nguyen X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Sep 17, 2014 at 02:20:02PM +0100, Russell King - ARM Linux wrote: > On Tue, Sep 09, 2014 at 01:49:41PM +0200, Pavel Machek wrote: > > Bisect would be hard... and I believe the problem is somewhere in > > block layer now -- not socfpga-specific. > > [Adding those on the commit mentioned below to this thread.] > > I just updated my nightly build system from -rc3 to -rc5, and I'm seeing > this on the LDP3430 platform (but not the SDP4430) despite both using > MMC rootfs. > > On SD4430, I see: > > Kernel command line: root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2 debug > ... > mmc0: new high speed SD card at address 0002 > mmcblk0: mmc0:0002 00000 971 MiB > mmcblk0: p1 p2 > leds_pwm pwmleds: unable to request PWM for omap4:green:chrg: -517 > platform pwmleds: Driver leds_pwm requests probe deferral > Waiting 2 sec before mounting root device... > mmc1: new high speed MMC card at address 0001 > mmcblk1: mmc1:0001 SEM08G 7.39 GiB > mmcblk1boot0: mmc1:0001 SEM08G partition 1 1.00 MiB > mmcblk1boot1: mmc1:0001 SEM08G partition 2 1.00 MiB > mmcblk1: unknown partition table > mmcblk1boot1: unknown partition table > mmcblk1boot0: unknown partition table > leds_pwm pwmleds: unable to request PWM for omap4:green:chrg: -517 > platform pwmleds: Driver leds_pwm requests probe deferral > kjournald starting. Commit interval 5 seconds > EXT3-fs (mmcblk0p2): warning: maximal mount count reached, running e2fsck is recommended > EXT3-fs (mmcblk0p2): using internal journal > EXT3-fs (mmcblk0p2): recovery complete > EXT3-fs (mmcblk0p2): mounted filesystem with writeback data mode > VFS: Mounted root (ext3 filesystem) on device 179:2. > > However, on LDP3430: > > Kernel command line: console=ttyO2,115200n8 noinitrd vmalloc=1G mem=128M root=/dev/mmcblk0p2 rw ip=none rootdelay=2 video=omap24xxfb:rotation=270 > ... > mmc0: host does not support reading read-only switch. assuming write-enable. > Waiting 2 sec before mounting root device... > mmc0: new high speed SD card at address 0002 > mmcblk0: mmc0:0002 00000 971 MiB > mmcblk0: p1 p2 > VFS: Cannot open root device "mmcblk0p2" or unknown-block(0,0): error -6 > Please append a correct "root=" boot option; here are the available partitions: > b300 994816 mmcblk0 driver: mmcblk > b301 72261 mmcblk0p1 0b4c6c45-01 > b302 915705 mmcblk0p2 0b4c6c45-02 > Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > > I think the problem may be 4dfe694f616e00e6fd83e5bbcd7a3c4d7113493d > ("init: make rootdelay=N consistent with rootwait behaviour") which > was merged during the recent window. This moved the delay after the > saved_root_name[] handling. As we can see in the SDP4430 case, the > order was: > > - mmcblk0p2 detected > - delay message > - rootfs failure > > and everything worked. However, in the LDP3430 case: > > - delay message > - mmcblk0p2 detected > - rootfs failure > > and it failed. If we look at the code as it stands today: > > if (saved_root_name[0]) { > root_device_name = saved_root_name; > if (!strncmp(root_device_name, "mtd", 3) || > !strncmp(root_device_name, "ubi", 3)) { > mount_block_root(root_device_name, root_mountflags); > goto out; > } > ROOT_DEV = name_to_dev_t(root_device_name); > if (strncmp(root_device_name, "/dev/", 5) == 0) > root_device_name += 5; > } > > This tries to look up the root device name and translate to a dev_t. > We know that "mmcblk0p2" doesn't exist at this point, so ROOT_DEV is > zero here. > > if (initrd_load()) > goto out; > > if (root_delay) { > pr_info("Waiting %d sec before mounting root device...\n", > root_delay); > ssleep(root_delay); > } > > Here's our delay. > > /* wait for any asynchronous scanning to complete */ > if ((ROOT_DEV == 0) && root_wait) { > printk(KERN_INFO "Waiting for root device %s...\n", > saved_root_name); > while (driver_probe_done() != 0 || > (ROOT_DEV = name_to_dev_t(saved_root_name)) == 0) > msleep(100); > async_synchronize_full(); > } > > If ROOT_DEV was still zero, and root_wait was set (it isn't) we'd then > try to re-evaluate ROOT_DEV. ROOT_DEV must be set to mount the rootfs, > and we can see from the above failure messages that it was still zero. > That works out, because this code would never be run with root_wait=false. > > The reason it used to work is because the delay came _before_ the first > "if" above, so causing the first ROOT_DEV lookup to succeed. > > I think it may be better to move the root_delay handling either immediately > after md_run_setup(), or we need to re-lookup ROOT_DEV after the delay. > Paul, any thoughts? Having discussed this with Paul on irc, I came up with this patch which solves the problem for me. One thing remaining from this is a question about whether we should wait for a rootfs which we already have discovered (iow, ROOT_DEV != 0). That's a separate issue which I do not intend to address. 8<==== From: Russell King Subject: [PATCH] Fix rootdelay wait causing rootfs mount failure Using rootdelay in recent kernels causes the rootfs to fail if the device being waited for appears during the wait. The problem is that ROOT_DEV is not re-looked up after the wait expires, meaning that ROOT_DEV is zero. This leads to failures such as: mmc0: host does not support reading read-only switch. assuming write-enable. Waiting 2 sec before mounting root device... mmc0: new high speed SD card at address 0002 mmcblk0: mmc0:0002 00000 971 MiB mmcblk0: p1 p2 VFS: Cannot open root device "mmcblk0p2" or unknown-block(0,0): error -6 Please append a correct "root=" boot option; here are the available partitions: b300 994816 mmcblk0 driver: mmcblk b301 72261 mmcblk0p1 0b4c6c45-01 b302 915705 mmcblk0p2 0b4c6c45-02 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Fix this by re-looking up the ROOT_DEV after the delay wait. Fixes: 4dfe694f616e ("init: make rootdelay=N consistent with rootwait behaviour") Signed-off-by: Russell King --- init/do_mounts.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/init/do_mounts.c b/init/do_mounts.c index b6237c31b0e2..1353f607b374 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -569,6 +569,8 @@ void __init prepare_namespace(void) pr_info("Waiting %d sec before mounting root device...\n", root_delay); ssleep(root_delay); + /* Re-evaluate the root name to get the dev_t */ + ROOT_DEV = name_to_dev_t(saved_root_name); } /* wait for any asynchronous scanning to complete */