* [GIT PULL] SOCFPGA DTS updates for 3.17
@ 2014-07-15 4:06 dinguyen at altera.com
2014-07-15 4:41 ` Olof Johansson
2014-07-15 7:29 ` Jaehoon Chung
0 siblings, 2 replies; 27+ messages in thread
From: dinguyen at altera.com @ 2014-07-15 4:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin and Olof,
Please consider pulling in these 2 patches for v3.17. 1 is just a defconfig
update and the other is a simple DTS fix.
Thanks,
Dinh
The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1:
Linux 3.16-rc4 (2014-07-06 12:37:51 -0700)
are available in the git repository at:
git://git.rocketboards.org/linux-socfpga-next.git tags/socfpga_updates_for_3.17
for you to fetch changes up to 7a0385c71fcec129d79ef219eebfcfce16d20417:
ARM: socfpga: Add missing #reset-cells to socfpga device tree (2014-07-14 22:39:00 -0500)
----------------------------------------------------------------
defconfig and DTS updates for v3.17
----------------------------------------------------------------
Vince Bridgers (2):
ARM: socfpga: Update socfpga_defconfig
ARM: socfpga: Add missing #reset-cells to socfpga device tree
arch/arm/boot/dts/socfpga.dtsi | 1 +
arch/arm/configs/socfpga_defconfig | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+)
^ permalink raw reply [flat|nested] 27+ messages in thread* [GIT PULL] SOCFPGA DTS updates for 3.17 2014-07-15 4:06 [GIT PULL] SOCFPGA DTS updates for 3.17 dinguyen at altera.com @ 2014-07-15 4:41 ` Olof Johansson 2014-07-15 7:29 ` Jaehoon Chung 1 sibling, 0 replies; 27+ messages in thread From: Olof Johansson @ 2014-07-15 4:41 UTC (permalink / raw) To: linux-arm-kernel Hi, On Mon, Jul 14, 2014 at 9:06 PM, <dinguyen@altera.com> wrote: > Hi Arnd, Kevin and Olof, > > Please consider pulling in these 2 patches for v3.17. 1 is just a defconfig > update and the other is a simple DTS fix. They're for different topics here (one goes into next/defconfig, the other in next/dt). It's silly to ask you to make one pull request per patch though, so I just cherry-picked them into the two branches. In other words: Patches have been applied, but I didn't merge the branch. Thanks! -Olof ^ permalink raw reply [flat|nested] 27+ messages in thread
* [GIT PULL] SOCFPGA DTS updates for 3.17 2014-07-15 4:06 [GIT PULL] SOCFPGA DTS updates for 3.17 dinguyen at altera.com 2014-07-15 4:41 ` Olof Johansson @ 2014-07-15 7:29 ` Jaehoon Chung 2014-07-15 15:01 ` Dinh Nguyen 2014-08-14 18:47 ` socfpga mmc (was Re: [GIT PULL] SOCFPGA DTS updates for 3.17) Pavel Machek 1 sibling, 2 replies; 27+ messages in thread From: Jaehoon Chung @ 2014-07-15 7:29 UTC (permalink / raw) To: linux-arm-kernel Hi Dinh. Could you check this patch? https://patchwork.kernel.org/patch/4529891/ Best Regards, Jaehoon Chung On 07/15/2014 01:06 PM, dinguyen at altera.com wrote: > Hi Arnd, Kevin and Olof, > > Please consider pulling in these 2 patches for v3.17. 1 is just a defconfig > update and the other is a simple DTS fix. > > Thanks, > Dinh > > The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1: > > Linux 3.16-rc4 (2014-07-06 12:37:51 -0700) > > are available in the git repository at: > > git://git.rocketboards.org/linux-socfpga-next.git tags/socfpga_updates_for_3.17 > > for you to fetch changes up to 7a0385c71fcec129d79ef219eebfcfce16d20417: > > ARM: socfpga: Add missing #reset-cells to socfpga device tree (2014-07-14 22:39:00 -0500) > > ---------------------------------------------------------------- > defconfig and DTS updates for v3.17 > > ---------------------------------------------------------------- > Vince Bridgers (2): > ARM: socfpga: Update socfpga_defconfig > ARM: socfpga: Add missing #reset-cells to socfpga device tree > > arch/arm/boot/dts/socfpga.dtsi | 1 + > arch/arm/configs/socfpga_defconfig | 35 +++++++++++++++++++++++++++++++++++ > 2 files changed, 36 insertions(+) > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [GIT PULL] SOCFPGA DTS updates for 3.17 2014-07-15 7:29 ` Jaehoon Chung @ 2014-07-15 15:01 ` Dinh Nguyen 2014-07-16 1:34 ` Jaehoon Chung 2014-08-14 18:47 ` socfpga mmc (was Re: [GIT PULL] SOCFPGA DTS updates for 3.17) Pavel Machek 1 sibling, 1 reply; 27+ messages in thread From: Dinh Nguyen @ 2014-07-15 15:01 UTC (permalink / raw) To: linux-arm-kernel Hi Jaehoon, On 07/15/2014 02:29 AM, Jaehoon Chung wrote: > Hi Dinh. > > Could you check this patch? > https://patchwork.kernel.org/patch/4529891/ > Sorry that I missed this. I just applied it. Will test and send out an updated pull-request. Dinh ^ permalink raw reply [flat|nested] 27+ messages in thread
* [GIT PULL] SOCFPGA DTS updates for 3.17 2014-07-15 15:01 ` Dinh Nguyen @ 2014-07-16 1:34 ` Jaehoon Chung 2014-07-16 21:05 ` Dinh Nguyen 0 siblings, 1 reply; 27+ messages in thread From: Jaehoon Chung @ 2014-07-16 1:34 UTC (permalink / raw) To: linux-arm-kernel CC'd Chris/Ulf. If you are ok, this patch will apply mmc tree.(3.16-rc5) To prevent conflict, we want to get your opinion. Best Regards, Jaehoon Chung On 07/16/2014 12:01 AM, Dinh Nguyen wrote: > Hi Jaehoon, > > On 07/15/2014 02:29 AM, Jaehoon Chung wrote: >> Hi Dinh. >> >> Could you check this patch? >> https://patchwork.kernel.org/patch/4529891/ >> > > Sorry that I missed this. I just applied it. Will test and send out an updated pull-request. > > Dinh > ^ permalink raw reply [flat|nested] 27+ messages in thread
* [GIT PULL] SOCFPGA DTS updates for 3.17 2014-07-16 1:34 ` Jaehoon Chung @ 2014-07-16 21:05 ` Dinh Nguyen 0 siblings, 0 replies; 27+ messages in thread From: Dinh Nguyen @ 2014-07-16 21:05 UTC (permalink / raw) To: linux-arm-kernel On Wed, 2014-07-16 at 10:34 +0900, Jaehoon Chung wrote: > CC'd Chris/Ulf. > > If you are ok, this patch will apply mmc tree.(3.16-rc5) > To prevent conflict, we want to get your opinion. > Oh okay...The patch looks fine to me. Dinh > Best Regards, > Jaehoon Chung > > On 07/16/2014 12:01 AM, Dinh Nguyen wrote: > > Hi Jaehoon, > > > > On 07/15/2014 02:29 AM, Jaehoon Chung wrote: > >> Hi Dinh. > >> > >> Could you check this patch? > >> https://patchwork.kernel.org/patch/4529891/ > >> > > > > Sorry that I missed this. I just applied it. Will test and send out an updated pull-request. > > > > Dinh > > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* socfpga mmc (was Re: [GIT PULL] SOCFPGA DTS updates for 3.17) 2014-07-15 7:29 ` Jaehoon Chung 2014-07-15 15:01 ` Dinh Nguyen @ 2014-08-14 18:47 ` Pavel Machek 2014-08-14 20:56 ` Dinh Nguyen 1 sibling, 1 reply; 27+ messages in thread From: Pavel Machek @ 2014-08-14 18:47 UTC (permalink / raw) To: linux-arm-kernel Hi! I tried booting kernel based on ba36899, and got: mmc0: new SDHC card at address b368 mmcblk0: mmc0:b368 USD 7.45 GiB mmcblk0: p1 p2 p3 p4 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 7822336 mmcblk0 driver: mmcblk b301 102400 mmcblk0p1 00082434-01 b302 1048576 mmcblk0p2 00082434-02 b303 1024 mmcblk0p3 00082434-03 b304 6086656 mmcblk0p4 00082434-04 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-11208-gef74117-dirty #2 IIRC it worked ok in 3.16 in similar config. It may be stupid mistake, but if you know what I did wrong, I'd like to know... (-6 is ENXIO, so -- how can the device be there and not be there at the same time?) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* socfpga mmc (was Re: [GIT PULL] SOCFPGA DTS updates for 3.17) 2014-08-14 18:47 ` socfpga mmc (was Re: [GIT PULL] SOCFPGA DTS updates for 3.17) Pavel Machek @ 2014-08-14 20:56 ` Dinh Nguyen 2014-08-14 21:02 ` Pavel Machek 0 siblings, 1 reply; 27+ messages in thread From: Dinh Nguyen @ 2014-08-14 20:56 UTC (permalink / raw) To: linux-arm-kernel On 8/14/14, 1:47 PM, Pavel Machek wrote: > Hi! > > I tried booting kernel based on ba36899, and got: > > mmc0: new SDHC card at address b368 > mmcblk0: mmc0:b368 USD 7.45 GiB > mmcblk0: p1 p2 p3 p4 > 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 7822336 mmcblk0 driver: mmcblk > b301 102400 mmcblk0p1 00082434-01 > b302 1048576 mmcblk0p2 00082434-02 > b303 1024 mmcblk0p3 00082434-03 > b304 6086656 mmcblk0p4 00082434-04 > Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(0,0) > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-11208-gef74117-dirty > #2 Hmm...today's tip-top(899552d6) and ba36899 booted just fine for me. I noticed something, you must have commits on top of your ba36899? Mine shows 3.16.0-11149-gba36899. But just a thought, should one really be developing and debugging with commits in a merge window? Dinh > > IIRC it worked ok in 3.16 in similar config. It may be stupid mistake, > but if you know what I did wrong, I'd like to know... (-6 is ENXIO, so > -- how can the device be there and not be there at the same time?) > > Pavel > ^ permalink raw reply [flat|nested] 27+ messages in thread
* socfpga mmc (was Re: [GIT PULL] SOCFPGA DTS updates for 3.17) 2014-08-14 20:56 ` Dinh Nguyen @ 2014-08-14 21:02 ` Pavel Machek 2014-08-14 21:25 ` Dinh Nguyen 2014-08-26 11:47 ` 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails Pavel Machek 0 siblings, 2 replies; 27+ messages in thread From: Pavel Machek @ 2014-08-14 21:02 UTC (permalink / raw) To: linux-arm-kernel On Thu 2014-08-14 15:56:02, Dinh Nguyen wrote: > > > On 8/14/14, 1:47 PM, Pavel Machek wrote: > > Hi! > > > > I tried booting kernel based on ba36899, and got: > > > > mmc0: new SDHC card at address b368 > > mmcblk0: mmc0:b368 USD 7.45 GiB > > mmcblk0: p1 p2 p3 p4 > > 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 7822336 mmcblk0 driver: mmcblk > > b301 102400 mmcblk0p1 00082434-01 > > b302 1048576 mmcblk0p2 00082434-02 > > b303 1024 mmcblk0p3 00082434-03 > > b304 6086656 mmcblk0p4 00082434-04 > > Kernel panic - not syncing: VFS: Unable to mount root fs on > > unknown-block(0,0) > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-11208-gef74117-dirty > > #2 > > Hmm...today's tip-top(899552d6) and ba36899 booted just fine for me. I > noticed something, you must have commits on top of your ba36899? Mine > shows 3.16.0-11149-gba36899. Ok, thanks for info. I went back to 3.16, and it worked in same config, and went to 3.17, and it broke. > But just a thought, should one really be developing and debugging with > commits in a merge window? Well, some people test -next :-). I must admit it was initially a mistake, but it is usually good to catch bugs ASAP. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* socfpga mmc (was Re: [GIT PULL] SOCFPGA DTS updates for 3.17) 2014-08-14 21:02 ` Pavel Machek @ 2014-08-14 21:25 ` Dinh Nguyen 2014-08-26 11:47 ` 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails Pavel Machek 1 sibling, 0 replies; 27+ messages in thread From: Dinh Nguyen @ 2014-08-14 21:25 UTC (permalink / raw) To: linux-arm-kernel On 8/14/14, 4:02 PM, Pavel Machek wrote: > On Thu 2014-08-14 15:56:02, Dinh Nguyen wrote: >> >> >> On 8/14/14, 1:47 PM, Pavel Machek wrote: >>> Hi! >>> >>> I tried booting kernel based on ba36899, and got: >>> >>> mmc0: new SDHC card at address b368 >>> mmcblk0: mmc0:b368 USD 7.45 GiB >>> mmcblk0: p1 p2 p3 p4 >>> 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 7822336 mmcblk0 driver: mmcblk >>> b301 102400 mmcblk0p1 00082434-01 >>> b302 1048576 mmcblk0p2 00082434-02 >>> b303 1024 mmcblk0p3 00082434-03 >>> b304 6086656 mmcblk0p4 00082434-04 >>> Kernel panic - not syncing: VFS: Unable to mount root fs on >>> unknown-block(0,0) >>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-11208-gef74117-dirty >>> #2 >> >> Hmm...today's tip-top(899552d6) and ba36899 booted just fine for me. I >> noticed something, you must have commits on top of your ba36899? Mine >> shows 3.16.0-11149-gba36899. > > Ok, thanks for info. I went back to 3.16, and it worked in same > config, and went to 3.17, and it broke. > >> But just a thought, should one really be developing and debugging with >> commits in a merge window? > > Well, some people test -next :-). I must admit it was initially a > mistake, but it is usually good to catch bugs ASAP. > I see. Just booted linux-next and it booted fine and was able to mount /dev/mmcblk0p2 as the RFS. Dinh ^ permalink raw reply [flat|nested] 27+ messages in thread
* 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails 2014-08-14 21:02 ` Pavel Machek 2014-08-14 21:25 ` Dinh Nguyen @ 2014-08-26 11:47 ` Pavel Machek 2014-08-26 21:00 ` Dinh Nguyen 1 sibling, 1 reply; 27+ messages in thread From: Pavel Machek @ 2014-08-26 11:47 UTC (permalink / raw) To: Dinh Nguyen Cc: Jaehoon Chung, dinguyen, khilman, olof, arnd, arm, linux-arm-kernel, kernel list, akpm Hi! > > > mmc0: new SDHC card at address b368 > > > mmcblk0: mmc0:b368 USD 7.45 GiB > > > mmcblk0: p1 p2 p3 p4 > > > 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 7822336 mmcblk0 driver: mmcblk > > > b301 102400 mmcblk0p1 00082434-01 > > > b302 1048576 mmcblk0p2 00082434-02 > > > b303 1024 mmcblk0p3 00082434-03 > > > b304 6086656 mmcblk0p4 00082434-04 > > > Kernel panic - not syncing: VFS: Unable to mount root fs on > > > unknown-block(0,0) > > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-11208-gef74117-dirty > > > #2 > > > > Hmm...today's tip-top(899552d6) and ba36899 booted just fine for me. I > > noticed something, you must have commits on top of your ba36899? Mine > > shows 3.16.0-11149-gba36899. > > Ok, thanks for info. I went back to 3.16, and it worked in same > config, and went to 3.17, and it broke. The problem is still there in 3.17-rc2. 3.16 does not have the problem. Messages are still similar: mmc0: new high speed SDHC card at address b368 mmcblk0: mmc0:b368 USD 7.45 GiB mmcblk0: p1 p2 p3 p4 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 7822336 mmcblk0 driver: mmcblk b301 102400 mmcblk0p1 00082434-01 b302 1048576 mmcblk0p2 00082434-02 b303 1024 mmcblk0p3 00082434-03 b304 6086656 mmcblk0p4 00082434-04 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc2-00368-gec0400b-dirty #83 What is going on there? Clearly partition table was parsed and partitions are available; does the mention of unknown-block(0,0) mean that kernel failed to parse the command line? I replaced "root=/dev/mmcblk0p2" with "root=b302" and have a booting system. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails 2014-08-26 11:47 ` 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails Pavel Machek @ 2014-08-26 21:00 ` Dinh Nguyen 0 siblings, 0 replies; 27+ messages in thread From: Dinh Nguyen @ 2014-08-26 21:00 UTC (permalink / raw) To: linux-arm-kernel On Tue, Aug 26, 2014 at 6:47 AM, Pavel Machek <pavel@denx.de> wrote: > Hi! > >> > > mmc0: new SDHC card at address b368 >> > > mmcblk0: mmc0:b368 USD 7.45 GiB >> > > mmcblk0: p1 p2 p3 p4 >> > > 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 7822336 mmcblk0 driver: mmcblk >> > > b301 102400 mmcblk0p1 00082434-01 >> > > b302 1048576 mmcblk0p2 00082434-02 >> > > b303 1024 mmcblk0p3 00082434-03 >> > > b304 6086656 mmcblk0p4 00082434-04 >> > > Kernel panic - not syncing: VFS: Unable to mount root fs on >> > > unknown-block(0,0) >> > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-11208-gef74117-dirty >> > > #2 >> > >> > Hmm...today's tip-top(899552d6) and ba36899 booted just fine for me. I >> > noticed something, you must have commits on top of your ba36899? Mine >> > shows 3.16.0-11149-gba36899. >> >> Ok, thanks for info. I went back to 3.16, and it worked in same >> config, and went to 3.17, and it broke. > > The problem is still there in 3.17-rc2. 3.16 does not have the > problem. Messages are still similar: > > mmc0: new high speed SDHC card at address b368 > mmcblk0: mmc0:b368 USD 7.45 GiB > mmcblk0: p1 p2 p3 p4 > 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 7822336 mmcblk0 driver: mmcblk > b301 102400 mmcblk0p1 00082434-01 > b302 1048576 mmcblk0p2 00082434-02 > b303 1024 mmcblk0p3 00082434-03 > b304 6086656 mmcblk0p4 00082434-04 > Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 3.17.0-rc2-00368-gec0400b-dirty #83 > > > What is going on there? Clearly partition table was parsed and > partitions are available; does the mention of unknown-block(0,0) mean > that kernel failed to parse the command line? > > I replaced "root=/dev/mmcblk0p2" with "root=b302" and have a booting > system. Can you do a bisect? 3.17-rc2 booted fine for me today: EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode VFS: Mounted root (ext3 filesystem) on device 179:2. Freeing unused kernel memory: 252K (c052d000 - c056c000) random: nonblocking pool is initialized Poky 8.0 (Yocto Project 1.3 Reference Distro) 1.3 socfpga_cyclone5 ttyS0 socfpga_cyclone5 login: root root at socfpga_cyclone5:~# uname -a Linux socfpga_cyclone5 3.17.0-rc2-00006-gdd7ad78 #1 SMP Tue Aug 26 15:51:56 CDT 2014 armv7l GNU/Linux Dinh ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails @ 2014-08-26 21:00 ` Dinh Nguyen 0 siblings, 0 replies; 27+ messages in thread From: Dinh Nguyen @ 2014-08-26 21:00 UTC (permalink / raw) To: Pavel Machek Cc: Jaehoon Chung, Dinh Nguyen, Kevin Hilman, Olof Johansson, Arnd Bergmann, arm, linux-arm-kernel@lists.infradead.org, kernel list, akpm On Tue, Aug 26, 2014 at 6:47 AM, Pavel Machek <pavel@denx.de> wrote: > Hi! > >> > > mmc0: new SDHC card at address b368 >> > > mmcblk0: mmc0:b368 USD 7.45 GiB >> > > mmcblk0: p1 p2 p3 p4 >> > > 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 7822336 mmcblk0 driver: mmcblk >> > > b301 102400 mmcblk0p1 00082434-01 >> > > b302 1048576 mmcblk0p2 00082434-02 >> > > b303 1024 mmcblk0p3 00082434-03 >> > > b304 6086656 mmcblk0p4 00082434-04 >> > > Kernel panic - not syncing: VFS: Unable to mount root fs on >> > > unknown-block(0,0) >> > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-11208-gef74117-dirty >> > > #2 >> > >> > Hmm...today's tip-top(899552d6) and ba36899 booted just fine for me. I >> > noticed something, you must have commits on top of your ba36899? Mine >> > shows 3.16.0-11149-gba36899. >> >> Ok, thanks for info. I went back to 3.16, and it worked in same >> config, and went to 3.17, and it broke. > > The problem is still there in 3.17-rc2. 3.16 does not have the > problem. Messages are still similar: > > mmc0: new high speed SDHC card at address b368 > mmcblk0: mmc0:b368 USD 7.45 GiB > mmcblk0: p1 p2 p3 p4 > 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 7822336 mmcblk0 driver: mmcblk > b301 102400 mmcblk0p1 00082434-01 > b302 1048576 mmcblk0p2 00082434-02 > b303 1024 mmcblk0p3 00082434-03 > b304 6086656 mmcblk0p4 00082434-04 > Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 3.17.0-rc2-00368-gec0400b-dirty #83 > > > What is going on there? Clearly partition table was parsed and > partitions are available; does the mention of unknown-block(0,0) mean > that kernel failed to parse the command line? > > I replaced "root=/dev/mmcblk0p2" with "root=b302" and have a booting > system. Can you do a bisect? 3.17-rc2 booted fine for me today: EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode VFS: Mounted root (ext3 filesystem) on device 179:2. Freeing unused kernel memory: 252K (c052d000 - c056c000) random: nonblocking pool is initialized Poky 8.0 (Yocto Project 1.3 Reference Distro) 1.3 socfpga_cyclone5 ttyS0 socfpga_cyclone5 login: root root@socfpga_cyclone5:~# uname -a Linux socfpga_cyclone5 3.17.0-rc2-00006-gdd7ad78 #1 SMP Tue Aug 26 15:51:56 CDT 2014 armv7l GNU/Linux Dinh ^ permalink raw reply [flat|nested] 27+ messages in thread
* 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails 2014-08-26 21:00 ` Dinh Nguyen @ 2014-09-09 11:49 ` Pavel Machek -1 siblings, 0 replies; 27+ messages in thread From: Pavel Machek @ 2014-09-09 11:49 UTC (permalink / raw) To: linux-arm-kernel Hi! > > The problem is still there in 3.17-rc2. 3.16 does not have the > > problem. Messages are still similar: > > > > mmc0: new high speed SDHC card at address b368 > > mmcblk0: mmc0:b368 USD 7.45 GiB > > mmcblk0: p1 p2 p3 p4 > > 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 7822336 mmcblk0 driver: mmcblk > > b301 102400 mmcblk0p1 00082434-01 > > b302 1048576 mmcblk0p2 00082434-02 > > b303 1024 mmcblk0p3 00082434-03 > > b304 6086656 mmcblk0p4 00082434-04 > > Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted > > 3.17.0-rc2-00368-gec0400b-dirty #83 > > > > > > What is going on there? Clearly partition table was parsed and > > partitions are available; does the mention of unknown-block(0,0) mean > > that kernel failed to parse the command line? > > > > I replaced "root=/dev/mmcblk0p2" with "root=b302" and have a booting > > system. > > > Can you do a bisect? 3.17-rc2 booted fine for me today: > > EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode > VFS: Mounted root (ext3 filesystem) on device 179:2. > Freeing unused kernel memory: 252K (c052d000 - c056c000) > random: nonblocking pool is initialized Bisect would be hard... and I believe the problem is somewhere in block layer now -- not socfpga-specific. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails @ 2014-09-09 11:49 ` Pavel Machek 0 siblings, 0 replies; 27+ messages in thread From: Pavel Machek @ 2014-09-09 11:49 UTC (permalink / raw) To: Dinh Nguyen Cc: Jaehoon Chung, Dinh Nguyen, Kevin Hilman, Olof Johansson, Arnd Bergmann, arm, linux-arm-kernel@lists.infradead.org, kernel list, akpm Hi! > > The problem is still there in 3.17-rc2. 3.16 does not have the > > problem. Messages are still similar: > > > > mmc0: new high speed SDHC card at address b368 > > mmcblk0: mmc0:b368 USD 7.45 GiB > > mmcblk0: p1 p2 p3 p4 > > 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 7822336 mmcblk0 driver: mmcblk > > b301 102400 mmcblk0p1 00082434-01 > > b302 1048576 mmcblk0p2 00082434-02 > > b303 1024 mmcblk0p3 00082434-03 > > b304 6086656 mmcblk0p4 00082434-04 > > Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted > > 3.17.0-rc2-00368-gec0400b-dirty #83 > > > > > > What is going on there? Clearly partition table was parsed and > > partitions are available; does the mention of unknown-block(0,0) mean > > that kernel failed to parse the command line? > > > > I replaced "root=/dev/mmcblk0p2" with "root=b302" and have a booting > > system. > > > Can you do a bisect? 3.17-rc2 booted fine for me today: > > EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode > VFS: Mounted root (ext3 filesystem) on device 179:2. > Freeing unused kernel memory: 252K (c052d000 - c056c000) > random: nonblocking pool is initialized Bisect would be hard... and I believe the problem is somewhere in block layer now -- not socfpga-specific. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails 2014-09-09 11:49 ` Pavel Machek @ 2014-09-17 13:20 ` Russell King - ARM Linux -1 siblings, 0 replies; 27+ messages in thread From: Russell King - ARM Linux @ 2014-09-17 13:20 UTC (permalink / raw) To: linux-arm-kernel On Tue, Sep 09, 2014 at 01:49:41PM +0200, Pavel Machek wrote: > Hi! > > > > The problem is still there in 3.17-rc2. 3.16 does not have the > > > problem. Messages are still similar: > > > > > > mmc0: new high speed SDHC card at address b368 > > > mmcblk0: mmc0:b368 USD 7.45 GiB > > > mmcblk0: p1 p2 p3 p4 > > > 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 7822336 mmcblk0 driver: mmcblk > > > b301 102400 mmcblk0p1 00082434-01 > > > b302 1048576 mmcblk0p2 00082434-02 > > > b303 1024 mmcblk0p3 00082434-03 > > > b304 6086656 mmcblk0p4 00082434-04 > > > Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted > > > 3.17.0-rc2-00368-gec0400b-dirty #83 > > > > > > > > > What is going on there? Clearly partition table was parsed and > > > partitions are available; does the mention of unknown-block(0,0) mean > > > that kernel failed to parse the command line? > > > > > > I replaced "root=/dev/mmcblk0p2" with "root=b302" and have a booting > > > system. > > > > > > Can you do a bisect? 3.17-rc2 booted fine for me today: > > > > EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode > > VFS: Mounted root (ext3 filesystem) on device 179:2. > > Freeing unused kernel memory: 252K (c052d000 - c056c000) > > random: nonblocking pool is initialized > > 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? -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails @ 2014-09-17 13:20 ` Russell King - ARM Linux 0 siblings, 0 replies; 27+ messages in thread From: Russell King - ARM Linux @ 2014-09-17 13:20 UTC (permalink / raw) To: Pavel Machek, Paul Gortmaker, Andrew Morton, Linus Torvalds Cc: Dinh Nguyen, Jaehoon Chung, Dinh Nguyen, Kevin Hilman, Olof Johansson, Arnd Bergmann, arm, linux-arm-kernel@lists.infradead.org, kernel list, akpm On Tue, Sep 09, 2014 at 01:49:41PM +0200, Pavel Machek wrote: > Hi! > > > > The problem is still there in 3.17-rc2. 3.16 does not have the > > > problem. Messages are still similar: > > > > > > mmc0: new high speed SDHC card at address b368 > > > mmcblk0: mmc0:b368 USD 7.45 GiB > > > mmcblk0: p1 p2 p3 p4 > > > 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 7822336 mmcblk0 driver: mmcblk > > > b301 102400 mmcblk0p1 00082434-01 > > > b302 1048576 mmcblk0p2 00082434-02 > > > b303 1024 mmcblk0p3 00082434-03 > > > b304 6086656 mmcblk0p4 00082434-04 > > > Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) > > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted > > > 3.17.0-rc2-00368-gec0400b-dirty #83 > > > > > > > > > What is going on there? Clearly partition table was parsed and > > > partitions are available; does the mention of unknown-block(0,0) mean > > > that kernel failed to parse the command line? > > > > > > I replaced "root=/dev/mmcblk0p2" with "root=b302" and have a booting > > > system. > > > > > > Can you do a bisect? 3.17-rc2 booted fine for me today: > > > > EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode > > VFS: Mounted root (ext3 filesystem) on device 179:2. > > Freeing unused kernel memory: 252K (c052d000 - c056c000) > > random: nonblocking pool is initialized > > 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? -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 27+ messages in thread
* 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails 2014-09-17 13:20 ` Russell King - ARM Linux @ 2014-09-17 13:47 ` Russell King - ARM Linux -1 siblings, 0 replies; 27+ messages in thread From: Russell King - ARM Linux @ 2014-09-17 13:47 UTC (permalink / raw) To: linux-arm-kernel 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 <rmk+kernel@arm.linux.org.uk> 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 <rmk+kernel@arm.linux.org.uk> --- 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 */ -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails @ 2014-09-17 13:47 ` Russell King - ARM Linux 0 siblings, 0 replies; 27+ messages in thread From: Russell King - ARM Linux @ 2014-09-17 13:47 UTC (permalink / raw) To: Pavel Machek, Paul Gortmaker, Andrew Morton, Linus Torvalds Cc: Dinh Nguyen, Jaehoon Chung, Dinh Nguyen, Kevin Hilman, Olof Johansson, Arnd Bergmann, arm, linux-arm-kernel@lists.infradead.org, kernel list 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 <rmk+kernel@arm.linux.org.uk> 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 <rmk+kernel@arm.linux.org.uk> --- 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 */ -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply related [flat|nested] 27+ messages in thread
* 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails 2014-09-17 13:20 ` Russell King - ARM Linux @ 2014-09-17 14:25 ` Paul Gortmaker -1 siblings, 0 replies; 27+ messages in thread From: Paul Gortmaker @ 2014-09-17 14:25 UTC (permalink / raw) To: linux-arm-kernel [Re: 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails] On 17/09/2014 (Wed 14:20) Russell King - ARM Linux wrote: [...] > 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: [...] > > > 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? After discussing it more on irc, it seems like moving the delay/wait handling after md_run_setup [i.e. to the original location of delay vs. the original location of wait] is probably best. But, given as the original commit log indicated -- there may be a risk of other corner cases subtly being broken by such a change, it is probably best if we just revert the original now, and then try again in the alternate location in the next dev cycle. I'll send a revert shortly. Thanks for diagnosing this. Paul. -- > > -- > FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up > according to speedtest.net. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails @ 2014-09-17 14:25 ` Paul Gortmaker 0 siblings, 0 replies; 27+ messages in thread From: Paul Gortmaker @ 2014-09-17 14:25 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pavel Machek, Andrew Morton, Linus Torvalds, Dinh Nguyen, Jaehoon Chung, Dinh Nguyen, Kevin Hilman, Olof Johansson, Arnd Bergmann, arm, linux-arm-kernel@lists.infradead.org, kernel list [Re: 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails] On 17/09/2014 (Wed 14:20) Russell King - ARM Linux wrote: [...] > 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: [...] > > > 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? After discussing it more on irc, it seems like moving the delay/wait handling after md_run_setup [i.e. to the original location of delay vs. the original location of wait] is probably best. But, given as the original commit log indicated -- there may be a risk of other corner cases subtly being broken by such a change, it is probably best if we just revert the original now, and then try again in the alternate location in the next dev cycle. I'll send a revert shortly. Thanks for diagnosing this. Paul. -- > > -- > FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up > according to speedtest.net. ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH] Revert "init: make rootdelay=N consistent with rootwait behaviour" 2014-09-17 14:25 ` Paul Gortmaker @ 2014-09-17 14:57 ` Paul Gortmaker -1 siblings, 0 replies; 27+ messages in thread From: Paul Gortmaker @ 2014-09-17 14:57 UTC (permalink / raw) To: linux-arm-kernel This reverts commit 4dfe694f616e00e6fd83e5bbcd7a3c4d7113493d. In that, we did: Here we move the rootdelay code to be right beside the rootwait code, so that their behaviour is consistent. ...which is fine, but in hindsight, perhaps moving the rootwait to be beside the rootdelay would have been better. We also indicated: It should be noted that in doing so, the actions based on the saved_root_name[0] and initrd_load() were previously put on hold by rootdelay=N and now currently will not be delayed. However, I think consistent behaviour is more important than matching historical behaviour of delaying the above two operations. But Pavel reported an instance where an ARM target with root on MMC was failing to mount root, and Russell diagnosed it to the fact that the call to set ROOT_DEV within the saved_root_name[0] processing block mentioned above was no longer being delayed. Rather than moving both wait clauses to the original position of rootdelay and risking unearthing other possible corner case breakage at this point in time, we simply revert now and we can revisit trying the alternate/earlier location in another development cycle. Cc: Pavel Machek <pavel@denx.de> Cc: Russell King <linux@arm.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> diff --git a/init/do_mounts.c b/init/do_mounts.c index b6237c31b0e2..82f22885c87e 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -539,6 +539,12 @@ void __init prepare_namespace(void) { int is_floppy; + if (root_delay) { + printk(KERN_INFO "Waiting %d sec before mounting root device...\n", + root_delay); + ssleep(root_delay); + } + /* * wait for the known devices to complete their probing * @@ -565,12 +571,6 @@ void __init prepare_namespace(void) if (initrd_load()) goto out; - if (root_delay) { - pr_info("Waiting %d sec before mounting root device...\n", - root_delay); - ssleep(root_delay); - } - /* wait for any asynchronous scanning to complete */ if ((ROOT_DEV == 0) && root_wait) { printk(KERN_INFO "Waiting for root device %s...\n", -- 1.9.2 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH] Revert "init: make rootdelay=N consistent with rootwait behaviour" @ 2014-09-17 14:57 ` Paul Gortmaker 0 siblings, 0 replies; 27+ messages in thread From: Paul Gortmaker @ 2014-09-17 14:57 UTC (permalink / raw) To: Russell King Cc: Dinh Nguyen, Jaehoon Chung, Dinh Nguyen, Kevin Hilman, Olof Johansson, Arnd Bergmann, arm, linux-arm-kernel, linux-kernel, Paul Gortmaker, Pavel Machek, Andrew Morton, Linus Torvalds This reverts commit 4dfe694f616e00e6fd83e5bbcd7a3c4d7113493d. In that, we did: Here we move the rootdelay code to be right beside the rootwait code, so that their behaviour is consistent. ...which is fine, but in hindsight, perhaps moving the rootwait to be beside the rootdelay would have been better. We also indicated: It should be noted that in doing so, the actions based on the saved_root_name[0] and initrd_load() were previously put on hold by rootdelay=N and now currently will not be delayed. However, I think consistent behaviour is more important than matching historical behaviour of delaying the above two operations. But Pavel reported an instance where an ARM target with root on MMC was failing to mount root, and Russell diagnosed it to the fact that the call to set ROOT_DEV within the saved_root_name[0] processing block mentioned above was no longer being delayed. Rather than moving both wait clauses to the original position of rootdelay and risking unearthing other possible corner case breakage at this point in time, we simply revert now and we can revisit trying the alternate/earlier location in another development cycle. Cc: Pavel Machek <pavel@denx.de> Cc: Russell King <linux@arm.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> diff --git a/init/do_mounts.c b/init/do_mounts.c index b6237c31b0e2..82f22885c87e 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -539,6 +539,12 @@ void __init prepare_namespace(void) { int is_floppy; + if (root_delay) { + printk(KERN_INFO "Waiting %d sec before mounting root device...\n", + root_delay); + ssleep(root_delay); + } + /* * wait for the known devices to complete their probing * @@ -565,12 +571,6 @@ void __init prepare_namespace(void) if (initrd_load()) goto out; - if (root_delay) { - pr_info("Waiting %d sec before mounting root device...\n", - root_delay); - ssleep(root_delay); - } - /* wait for any asynchronous scanning to complete */ if ((ROOT_DEV == 0) && root_wait) { printk(KERN_INFO "Waiting for root device %s...\n", -- 1.9.2 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH] Revert "init: make rootdelay=N consistent with rootwait behaviour" 2014-09-17 14:57 ` Paul Gortmaker @ 2014-09-18 13:17 ` Pavel Machek -1 siblings, 0 replies; 27+ messages in thread From: Pavel Machek @ 2014-09-18 13:17 UTC (permalink / raw) To: linux-arm-kernel On Wed 2014-09-17 10:57:45, Paul Gortmaker wrote: > This reverts commit 4dfe694f616e00e6fd83e5bbcd7a3c4d7113493d. This solves my problems, thanks. Tested-by: Pavel Machek <pavel@denx.de> Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Revert "init: make rootdelay=N consistent with rootwait behaviour" @ 2014-09-18 13:17 ` Pavel Machek 0 siblings, 0 replies; 27+ messages in thread From: Pavel Machek @ 2014-09-18 13:17 UTC (permalink / raw) To: Paul Gortmaker Cc: Russell King, Dinh Nguyen, Jaehoon Chung, Dinh Nguyen, Kevin Hilman, Olof Johansson, Arnd Bergmann, arm, linux-arm-kernel, linux-kernel, Andrew Morton, Linus Torvalds On Wed 2014-09-17 10:57:45, Paul Gortmaker wrote: > This reverts commit 4dfe694f616e00e6fd83e5bbcd7a3c4d7113493d. This solves my problems, thanks. Tested-by: Pavel Machek <pavel@denx.de> Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* rootdelay regression is back in 4.0? was Re: [PATCH] Revert "init: make rootdelay=N consistent with rootwait behaviour" 2014-09-18 13:17 ` Pavel Machek @ 2015-04-09 9:42 ` Pavel Machek -1 siblings, 0 replies; 27+ messages in thread From: Pavel Machek @ 2015-04-09 9:42 UTC (permalink / raw) To: linux-arm-kernel On Thu 2014-09-18 15:17:16, Pavel Machek wrote: > On Wed 2014-09-17 10:57:45, Paul Gortmaker wrote: > > This reverts commit 4dfe694f616e00e6fd83e5bbcd7a3c4d7113493d. > > This solves my problems, thanks. Weird. It seems this regression is back in 4.0-rc7? root=0xb302 works, root=/dev/mmcblk0p2 does not. socfpga board. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* rootdelay regression is back in 4.0? was Re: [PATCH] Revert "init: make rootdelay=N consistent with rootwait behaviour" @ 2015-04-09 9:42 ` Pavel Machek 0 siblings, 0 replies; 27+ messages in thread From: Pavel Machek @ 2015-04-09 9:42 UTC (permalink / raw) To: Paul Gortmaker Cc: Russell King, Dinh Nguyen, Jaehoon Chung, Dinh Nguyen, Kevin Hilman, Olof Johansson, Arnd Bergmann, arm, linux-arm-kernel, linux-kernel, Andrew Morton, Linus Torvalds On Thu 2014-09-18 15:17:16, Pavel Machek wrote: > On Wed 2014-09-17 10:57:45, Paul Gortmaker wrote: > > This reverts commit 4dfe694f616e00e6fd83e5bbcd7a3c4d7113493d. > > This solves my problems, thanks. Weird. It seems this regression is back in 4.0-rc7? root=0xb302 works, root=/dev/mmcblk0p2 does not. socfpga board. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2015-04-09 9:42 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-07-15 4:06 [GIT PULL] SOCFPGA DTS updates for 3.17 dinguyen at altera.com 2014-07-15 4:41 ` Olof Johansson 2014-07-15 7:29 ` Jaehoon Chung 2014-07-15 15:01 ` Dinh Nguyen 2014-07-16 1:34 ` Jaehoon Chung 2014-07-16 21:05 ` Dinh Nguyen 2014-08-14 18:47 ` socfpga mmc (was Re: [GIT PULL] SOCFPGA DTS updates for 3.17) Pavel Machek 2014-08-14 20:56 ` Dinh Nguyen 2014-08-14 21:02 ` Pavel Machek 2014-08-14 21:25 ` Dinh Nguyen 2014-08-26 11:47 ` 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails Pavel Machek 2014-08-26 21:00 ` Dinh Nguyen 2014-08-26 21:00 ` Dinh Nguyen 2014-09-09 11:49 ` Pavel Machek 2014-09-09 11:49 ` Pavel Machek 2014-09-17 13:20 ` Russell King - ARM Linux 2014-09-17 13:20 ` Russell King - ARM Linux 2014-09-17 13:47 ` Russell King - ARM Linux 2014-09-17 13:47 ` Russell King - ARM Linux 2014-09-17 14:25 ` Paul Gortmaker 2014-09-17 14:25 ` Paul Gortmaker 2014-09-17 14:57 ` [PATCH] Revert "init: make rootdelay=N consistent with rootwait behaviour" Paul Gortmaker 2014-09-17 14:57 ` Paul Gortmaker 2014-09-18 13:17 ` Pavel Machek 2014-09-18 13:17 ` Pavel Machek 2015-04-09 9:42 ` rootdelay regression is back in 4.0? was " Pavel Machek 2015-04-09 9:42 ` Pavel Machek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.