From: Josh Green <josh@resonance.org>
To: Pete MacKay <linux@architechnical.net>
Cc: linux-mtd@lists.infradead.org
Subject: Re: JFFS2 file system slowly filling up for unknown reason ~20 seconds after mount
Date: Fri, 02 Mar 2007 18:07:47 +0000 [thread overview]
Message-ID: <1172858867.12314.9.camel@localhost> (raw)
In-Reply-To: <48818.69.30.123.186.1172794036.squirrel@www.architechnical.net>
On Thu, 2007-03-01 at 19:07 -0500, Pete MacKay wrote:
> I tried getting this part to work with 2.6.18 and saw similar behavior
> at one point, but we've since changed hardware to use OneNAND. One
> thought I have is to try padding the file system to use the full
> partition, so you'd add "--pad=0xa40000" to the mkfs.jffs2 command line,
> and make sure you're using a version of mtd-utils that correctly writes
> the OOB on that device (another problem we had). BTW, the mkfs.jffs2 we
> use has a bug where it doesn't parse the '-p' option properly but does
> with '--pad='. Good luck!
>
I tried the pad option before with stranger results (lots of error
output during mount). Thanks for the tips on the mtd-utils and the OOB
stuff, in fact I suspect that could very well be what I'm experiencing.
Something wrong with the way the OOB stuff is being written. I turned
on verbose errors for the MTD sub system and I get a load of these
messages after mounting, which continue until the partition indicates
that it is full (gee if that isn't suspicious I don't know what is).
There were also messages related to the garbage collector interspersed
with these when I turned up the verbosity of error reporting.
nand_write_oob: Attempt to write past end of page
nand_write_oob: Attempt to write past end of page
...
> P.S. If I had it to do all over again I'd have made maps of the factory
> marked bad blocks, as I had to 'nuke' the chip by marking them all good
> again (U-boot lets you do this with a conditional, but created the need
> for it in the first place by writing the cleanmarker in the wrong place
> in the OOB - namely the bad block marker!).
>
Fortunately with the device I have I don't believe there are any bad
blocks (at least there were none reported when I got it, although that
could also be a bad thing).
Thanks go as well to the others who responded. I'm well aware that this
kernel is outdated. Unfortunately its what we have to work with for
now. I'll be quite happy when this platform is supported in the main
kernel tree.
Best regards,
Josh Green
next parent reply other threads:[~2007-03-02 17:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <48818.69.30.123.186.1172794036.squirrel@www.architechnical.net>
2007-03-02 18:07 ` Josh Green [this message]
2007-03-01 18:41 JFFS2 file system slowly filling up for unknown reason ~20 seconds after mount Josh Green
2007-03-01 18:21 ` Artem Bityutskiy
2007-03-01 19:40 ` Vitaly Wool
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=1172858867.12314.9.camel@localhost \
--to=josh@resonance.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux@architechnical.net \
/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