From: Sulung Chang <sulung@terasign.com>
To: 'Stephen Bardsley' <sbardsley@rlwinc.com>
Cc: "'linux-mtd@lists.infradead.org'" <linux-mtd@lists.infradead.org>
Subject: RE: bad block recovery
Date: Sat, 6 Apr 2002 12:05:35 +0700 [thread overview]
Message-ID: <01C1DD63.67C132A0@SENLIANG> (raw)
Sorry to bother you all,
Stephen seems like I've the same problem that you have , I'm already tried using nftl_format , and about the verifying things
I've get rid of it, but I got a new ERROR Message :
" Invalid ioctl 80404d01 ( MEMGETINFO = 80204d01)
ioctl ( MEMGETINFO): Invalid argument "
I'm using DoC Millenium 8MB with M-Sys PCI Eval Board, kernel 2.4.5
The BIOS and kernel can't detect DoCMillenium on boot, before I'm using erase_all or nftl_format ( I forget ) , it detects Ok.
I'm appreciate your help, thanks.
Sulung
-----Original Message-----
From: Stephen Bardsley [SMTP:sbardsley@rlwinc.com]
Sent: Monday, March 18, 2002 10:51 PM
To: David Woodhouse
Cc: linux-mtd@lists.infradead.org
Subject: RE: bad block recovery
> sbardsley@rlwinc.com said:
> > I took a quick look at the code and see that meminfo.erasesize is
> > used to scale various values. I don't see why 8Kb is a limit. I have
> > found that my chip's erase size to be 16Kb; is there any way for me to
> > use nftl_format? If necessary, I don't mind modifying the code, but I
> > don't want to screw it up. Any hints?
>
> You _ought_ to be able to just remove that check, if you first verify that
> we'll do the right thing through the rest of the code rather than using a
> hardcoded 8KiB. I put the check in just because I'd never tested the larger
> erase size.
I don't know a great deal about this stuff, but the code seems to want to do
the "right thing". So I removed the 8Kb check, and ntfl_format is running as
I write this; so far so good.
BTW -- It might be good to add a note to the FAQ regarding nftl_format and
driver debug options. Debugging causes the format to crawl. On my hardware
it is the difference between 20 minutes (without debug) and 4 hours (with debug)
(estimated times).
Thanks again.
Steve
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next reply other threads:[~2002-04-06 5:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-06 5:05 Sulung Chang [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-03-18 12:54 bad block recovery Stephen Bardsley
2002-03-18 13:02 ` David Woodhouse
2002-03-18 13:31 ` Stephen Bardsley
2002-03-18 13:52 ` David Woodhouse
2002-03-18 15:51 ` Stephen Bardsley
2002-03-18 16:09 ` Stephen Bardsley
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=01C1DD63.67C132A0@SENLIANG \
--to=sulung@terasign.com \
--cc=linux-mtd@lists.infradead.org \
--cc=sbardsley@rlwinc.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.