From: Max Stirling <vicky.irobot@gmail.com>
To: Adams Richard-W36112 <rgadams@motorola.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: mtdblock mount issue
Date: Thu, 07 Feb 2008 11:46:53 +0530 [thread overview]
Message-ID: <47AAA255.4050009@gmail.com> (raw)
In-Reply-To: <A2EC06CB0E393B4C8EB220B286B7083E058EFCAC@ct11exm60.ds.mot.com>
Adams Richard-W36112 wrote:
>> -----Original Message-----
>> From: linux-mtd-bounces@lists.infradead.org
>> [mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of
>> Max Stirling
>> Sent: Monday, February 04, 2008 6:20 AM
>> To: linux-mtd@lists.infradead.org
>> Subject: mtdblock mount issue
>>
>> Hi,
>>
>> I am trying to mount a cramfs partition from flash. I have
>> the low level driver written and MTDBLOCK_RO module is enabled in MTD,
>>
>> My mount fails with invalid argument error.
>>
>> /mount: Mounting /dev/mtdblock on /home/crfs failed: Invalid argument/
>>
>> I am using a 512 byte NAND flash 16byte spare.
>>
>> I can find cramfs in /proc/filesytems and the mtdblock is
>> under /proc/devices.
>>
>> I had enabled a few debug statements in the mtdblock_ro and
>> the low level nand driver code. I find that the mount is
>> reading 32 pages after which it fails with invalid argument.
>> Below is the log.
>>
>> If you see the log below, the flow of code is
>>
>> cramfs_read ==> do_blktrans_request ==> mtdblock_readsect
>> ==> mt_read(my low level read function which returns success)
>>
>> I even dumped the hex of the data being read by my low level
>> driver module and found to match the cramfs image that I
>> wrote to the flash.
>>
>>
>> ######################*LOG*##########################
>>
>> /home # mkdir crfs
>> /home # cat /proc/devices | grep mtdblock
>> 31 mtdblock
>> /home # cat proc/filesystems | grep cramfs
>> cramfs
>> /home #
>> /home # mknod /dev/mtdblock b 31 0
>> /home # mount -t cramfs /dev/mtdblock /home/crfs
>> mount: /dev/mtdblock is write-protected, mounting read-only
>> cramfs_read
>> do_blktrans_request nsect:8 block:0
>> mtdblock_readsect
>> mt_read offset:0
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:512
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:1024
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:1536
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:2048
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:2560
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:3072
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:3584
>> mt_read status:0
>> do_blktrans_request nsect:8 block:0
>> mtdblock_readsect
>> mt_read offset:4096
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:4608
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:5120
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:5632
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:6144
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:6656
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:7168
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:7680
>> mt_read status:0
>> do_blktrans_request nsect:8 block:0
>> mtdblock_readsect
>> mt_read offset:8192
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:8704
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:9216
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:9728
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:10240
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:10752
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:11264
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:11776
>> mt_read status:0
>> do_blktrans_request nsect:8 block:0
>> mtdblock_readsect
>> mt_read offset:12288
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:12800
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:13312
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:13824
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:14336
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:14848
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:15360
>> mt_read status:0
>> mtdblock_readsect
>> mt_read offset:15872
>> mt_read status:0
>> cramfs_read
>> mount: Mounting /dev/mtdblock on /home/crfs failed: Invalid argument
>> /home #
>>
>> ########################################################
>>
>>
>> I hope I have provided the maximum information. Looking
>> forward for some
>> help.
>>
>>
>
> You need to mount the file system as read only. I believe I've seen this
> error when I've mounted a squashfs (also a read only file system)
> without specifying the read only option.
>
> Try this command:
> mount /dev/mtdblock /home/crfs -t cramfs -o ro
>
> Rick
>
Thanks mate. After some debugging I found that in cramfs_read function
it calls read_cache_page and the returned superblock magic is not
correct from cramfs_read.
I am not sure whatz gone wrong since in my low level driver code I
dumped the data that is being copied to the buffer that readsect from
block_ro passed and the magic was right there.
Have to dig into what might be causing this wrong data to be returned by
read_cache_page. One more thing that I noticed was that for every run
the magic in the page that read_cache_page returns is different !!!
I am using linux kernel 2.6.10, the latest kernel calls
read_mapping_page_async in cramfs_read. Not sure if this was a fix to
what I have been seeing or something wrong here.
--
Max Stirling
next prev parent reply other threads:[~2008-02-07 6:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-04 14:19 mtdblock mount issue Max Stirling
2008-02-06 16:20 ` Adams Richard-W36112
2008-02-07 6:16 ` Max Stirling [this message]
2008-02-07 16:28 ` Sergei Sharonov
2008-02-08 10:31 ` Max Stirling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47AAA255.4050009@gmail.com \
--to=vicky.irobot@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=rgadams@motorola.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.