* ENOENT creating /dev/root on MTD RAM partition
@ 2007-04-02 6:41 John Williams
2007-04-02 12:52 ` Olaf Hering
0 siblings, 1 reply; 4+ messages in thread
From: John Williams @ 2007-04-02 6:41 UTC (permalink / raw)
To: linux-kernel
Hello,
I'm working on the 2.6 kernel port for MicroBlaze (embedded, NOMMU)
arch. Like some other nommu archs, we typically mount root on an MTD RAM
partition (either CRAMFS or ROMFS).
All of this is working fine on 2.6.19 plus SnapGear 2.6.19-uc0-bigpatch
NOMMU patchset.
However, since coming forward to 2.6.20 (plus equiv. SnapGear patchset)
mount_root is failing.
Details follow, but basically create_dev(/dev/root, ROOT_DEV) is
returning -ENOENT. ROOT_DEV points to a valid MTD RAM partition, with a
valid ROMFS (or CRAMFS, doesn't matter which) image. I've dumped the
memory, the image is good.
Googling the various archives finds one or two past references to
create_dev or do_mount_root returning -ENOENT on MTD RAM partitions, but
I found no followups or solutions posted.
From my bootlog:
uclinux[mtd]: RAM probe address=0x22182cc8 size=0x21d000
Creating 1 MTD partitions on "RAM":
0x00000000-0x0021d000 : "ROMfs"
mtd: Giving out device 5 to ROMfs
uclinux[mtd]: set ROMfs to be root filesystem index=5
...
((my debug output in namei.c))
hello from __link_path_walk(/dev/root)
__link_path_walk says -ENOENT
next:0x23ff4694
next.dentry:0x23e12d08
...
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(31,5)
<0>Rebooting in 120 seconds..Machine restart...
I traced down into fs/namei.c - it's a fragment in
__link_path_walk("/dev/root"):
line 892:
/* This does the actual lookups.. */
err = do_lookup(nd, &this, &next);
if (err)
break;
err = -ENOENT;
inode = next.dentry->d_inode;
if (!inode) {
---> we are hitting this error path
goto out_dput;
}
So, it seems that do_lookup is returning a dentry with no inode.
I've tried this with both ROMFS and CRAMFS types, with the same result.
If it was a random memory corruption event I'd expect to see
different failure modes for the two filesystem types.
Any comments or suggestions on a possible cause or approach to track it
down would be greatly appreciated.
Thanks,
John
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ENOENT creating /dev/root on MTD RAM partition
2007-04-02 6:41 ENOENT creating /dev/root on MTD RAM partition John Williams
@ 2007-04-02 12:52 ` Olaf Hering
2007-04-03 2:15 ` John Williams
0 siblings, 1 reply; 4+ messages in thread
From: Olaf Hering @ 2007-04-02 12:52 UTC (permalink / raw)
To: John Williams; +Cc: linux-kernel
On Mon, Apr 02, John Williams wrote:
> Any comments or suggestions on a possible cause or approach to track it
> down would be greatly appreciated.
Just a guess:
Check if '/dev' exists. I think it is now possible to not add the built-in
cpio archive with the mandatory /dev, /dev/console and /root entries.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ENOENT creating /dev/root on MTD RAM partition
2007-04-02 12:52 ` Olaf Hering
@ 2007-04-03 2:15 ` John Williams
0 siblings, 0 replies; 4+ messages in thread
From: John Williams @ 2007-04-03 2:15 UTC (permalink / raw)
To: Olaf Hering; +Cc: linux-kernel
Olaf Hering wrote:
> On Mon, Apr 02, John Williams wrote:
>
>>Any comments or suggestions on a possible cause or approach to track it
>>down would be greatly appreciated.
>
> Just a guess:
> Check if '/dev' exists. I think it is now possible to not add the built-in
> cpio archive with the mandatory /dev, /dev/console and /root entries.
Thanks Olaf - you got me on the right track. Turned out to be an arch
link script error whereby the "rootfs" initcalls were not placed in the
initcall table - thus the init ramfs wasn't yet mounted, and /dev wasn't
there.
Cheers,
John
^ permalink raw reply [flat|nested] 4+ messages in thread
* ENOENT creating /dev/root on MTD RAM partition
@ 2007-04-02 1:09 John Williams
0 siblings, 0 replies; 4+ messages in thread
From: John Williams @ 2007-04-02 1:09 UTC (permalink / raw)
To: linux-mtd, uClinux development list
Hello,
I'm working on the 2.6 kernel for MicroBlaze (embedded, NOMMU) arch.
Like some other nommu archs, we typically mount root on an MTD RAM
partition (either CRAMFS or ROMFS).
All of this is working fine on 2.6.19 plus SnapGear 2.6.19-uc0-bigpatch
NOMMU patchset.
However, since coming forward to 2.6.20 (plus equiv. SnapGear patchset)
mount_root is failing.
Details follow, but basically create_dev(/dev/root, ROOT_DEV) is
returning -ENOENT. ROOT_DEV points to a valid MTD RAM partition, with a
valid ROMFS (or CRAMFS, doesn't matter which) image. I've dumped the
memory, the image is good.
Googling the various archives finds one or two past references to
create_dev or do_mount_root returning -ENOENT on MTD RAM partitions, but
I found no followups or solutions posted.
From my bootlog:
uclinux[mtd]: RAM probe address=0x22182cc8 size=0x21d000
Creating 1 MTD partitions on "RAM":
0x00000000-0x0021d000 : "ROMfs"
mtd: Giving out device 5 to ROMfs
uclinux[mtd]: set ROMfs to be root filesystem index=5
...
((my debug output in namei.c))
hello from __link_walk_path(/dev/root)
__link_walk_path says -ENOENT
next:0x23ff4694
next.dentry:0x23e12d08
...
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(31,5)
<0>Rebooting in 120 seconds..Machine restart...
I traced down into fs/namei.c - it's a fragment in
__link_path_walk("/dev/root"):
line 892:
/* This does the actual lookups.. */
err = do_lookup(nd, &this, &next);
if (err)
break;
err = -ENOENT;
inode = next.dentry->d_inode;
if (!inode) {
---> we are hitting this error path
goto out_dput;
}
So, it seems that do_lookup is returning a dentry with no inode.
I've tried this with both ROMFS and CRAMFS types, with the same result.
If it was a random memory corruption event I'd expect to see
different failure modes for the two filesystem types.
Any comments or suggestions on a possible cause or approach to track it
down would be greatly appreciated.
Thanks,
John
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-04-03 2:15 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-02 6:41 ENOENT creating /dev/root on MTD RAM partition John Williams
2007-04-02 12:52 ` Olaf Hering
2007-04-03 2:15 ` John Williams
-- strict thread matches above, loose matches on Subject: below --
2007-04-02 1:09 John Williams
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.