public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox