bad block recovery

bad block recovery

[Stephen Bardsley]

Greetings:

I have a DOC 2000 and cannot format it using the DOS dformat
tool supplied by M-Systems.  My ultimate goal is to boot a linux
kernel from the chip, and use the chip as a disk.

The only reason I have come up with for no being able to format
is that the bad block list is gone.  I have come to this conclusion
after reading then M-Systems FAQ, and some of this lists archives.
Is there anyway to recover the bad block list?  I do not have a backup
of it.

My understanding is that the chip is now "unreliable", which I can
live with for now.  Does unreliable mean I can still use the chip
if I can somehow format it?

The bottom line is that I want to use the chip if at all possible,
even if it is unreliable.  I would appreciate any input on the subject.
Thanks.

Steve
_____________________
Stephen Bardsley
RLW Inc.
Malta, NY 

Re: bad block recovery

[David Woodhouse]

sbardsley@rlwinc.com said:
>  My understanding is that the chip is now "unreliable", which I can
> live with for now.  Does unreliable mean I can still use the chip if I
> can somehow format it?

Yes. Blocks can go bad during normal operation, and we have to be able to 
deal with that case _anyway_. My nftl_format program can be made to do some 
primitive tests on each erase block, and mark the completely broken ones as 
such before formatting. But (for the benefit of the peanut gallery) you 
should _only_ use nftl_format if you have already lost your bad block list.

--
dwmw2

RE: bad block recovery

[Stephen Bardsley]

> sbardsley@rlwinc.com said:
> >  My understanding is that the chip is now "unreliable", which I can
> > live with for now.  Does unreliable mean I can still use the chip if I
> > can somehow format it?
> 
> Yes. Blocks can go bad during normal operation, and we have to be able to 
> deal with that case _anyway_. My nftl_format program can be made to do some 
> primitive tests on each erase block, and mark the completely broken ones as 
> such before formatting. But (for the benefit of the peanut gallery) you 
> should _only_ use nftl_format if you have already lost your bad block list.
> 
> --
> dwmw2

Dave, thanks for the prompt response.

I built the mtd/utils, and read the FAQ.  All indications are that the bad
block table is gone.  So I ran nftl_format and received the message
"Erase size not 8Kb - I'm confused".  What exactly does this mean?

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?

Steve
_____________________
Stephen Bardsley
RLW Inc.
Malta, NY 

Re: bad block recovery

[David Woodhouse]

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.

--
dwmw2

RE: bad block recovery

[Stephen Bardsley]

> 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

RE: bad block recovery

[Stephen Bardsley]

Followup:

The nftl_format was successful.  I was able to create
a partion, mkfs, and mount the filesystem.  So now I'm
on the to next problem :-)  (It's what we do, solve problems)

Thanks so much for all the help.

Steve

RE: bad block recovery

[Sulung Chang]

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/