Bad blocks

Bad blocks

[Kalev Lember]

Hi,

I am going to use DOC Millennium Plus and I do not want to use M-Systems 
propietary kernel modules.
Having read the mailing list archives I have some questions.  Does current 
INFTL code support bad block handling? Without that I would say it is 
virtually useless. Am I correct?

-- 
Best regards,
Kalev Lember

Re: Bad blocks

[David Woodhouse]

On Thu, 2004-04-01 at 17:06 +0300, Kalev Lember wrote:
> Hi,
> 
> I am going to use DOC Millennium Plus and I do not want to use M-Systems 
> propietary kernel modules.
> Having read the mailing list archives I have some questions.  Does current 
> INFTL code support bad block handling? Without that I would say it is 
> virtually useless. Am I correct?

It doesn't, and you're probably correct, yes.

This is fairly high up on my TODO list but keeps getting preempted by
RealWork(tm). Are you volunteering? It shouldn't be too hard.

-- 
dwmw2

patch for AMD am29dl800b

[David Updegraff]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

Hi.

I have a gadget with this amd chip on it.  Whose id and layout dfn. is 
not in the jedec_probe tables.  Unfortuanately, they have _SIX_ (6) 
erase regions.  Anyone know of a reason expanding the regions[] array to 
6 is a bad idea?  Or why dealing with this chip in general is a bad idea?

-dbu.

[-- Attachment #2: am29dl800b.patch --]
[-- Type: text/x-patch, Size: 1651 bytes --]

--- drivers/mtd/chips/jedec_probe.c.orig	2004-04-01 17:27:18.267578712 -0600
+++ drivers/mtd/chips/jedec_probe.c	2004-04-01 17:59:06.562473792 -0600
@@ -38,6 +38,9 @@
 
 
 /* AMD */
+#define AM29DL800BB	0x22C8
+#define AM29DL800BT	0x224A
+
 #define AM29F800BB	0x2258
 #define AM29F800BT	0x22D6
 #define AM29LV400BB	0x22BA
@@ -222,7 +225,7 @@
 	const int NumEraseRegions;
 	const int CmdSet;
 	const __u8 uaddr[4];		/* unlock addrs for 8, 16, 32, 64 */
-	const ulong regions[4];
+	const ulong regions[6];
 };
 
 #define ERASEINFO(size,blocks) (size<<8)|(blocks-1)
@@ -342,6 +345,45 @@
 			ERASEINFO(0x10000,15),
 		}
 	}, {
+/* add DL */
+		.mfr_id		= MANUFACTURER_AMD,
+		.dev_id		= AM29DL800BB,
+		.name		= "AMD AM29DL800BB",
+		.uaddr		= {
+			[0] = MTD_UADDR_0x0AAA_0x0555,  /* x8 */
+			[1] = MTD_UADDR_0x0555_0x02AA,  /* x16 */
+		},
+		.DevSize	= SIZE_1MiB,
+		.CmdSet		= P_ID_AMD_STD,
+		.NumEraseRegions= 6,
+		.regions	= {
+			ERASEINFO(0x04000,1),
+			ERASEINFO(0x08000,1),
+			ERASEINFO(0x02000,4),
+			ERASEINFO(0x08000,1),
+			ERASEINFO(0x04000,1),
+			ERASEINFO(0x10000,14)
+		}
+	}, {
+		.mfr_id		= MANUFACTURER_AMD,
+		.dev_id		= AM29DL800BT,
+		.name		= "AMD AM29DL800BT",
+		.uaddr		= {
+			[0] = MTD_UADDR_0x0AAA_0x0555,  /* x8 */
+			[1] = MTD_UADDR_0x0555_0x02AA,  /* x16 */
+		},
+		.DevSize	= SIZE_1MiB,
+		.CmdSet		= P_ID_AMD_STD,
+		.NumEraseRegions= 6,
+		.regions	= {
+			ERASEINFO(0x10000,14),
+			ERASEINFO(0x04000,1),
+			ERASEINFO(0x08000,1),
+			ERASEINFO(0x02000,4),
+			ERASEINFO(0x08000,1),
+			ERASEINFO(0x04000,1)
+		}
+	}, {
 		.mfr_id		= MANUFACTURER_AMD,
 		.dev_id		= AM29F800BB,
 		.name		= "AMD AM29F800BB",

Re: patch for AMD am29dl800b

[David Woodhouse]

Please don't reply to unrelated threads. This isn't about bad blocks and
doesn't live with the message to which you replied.

On Thu, 2004-04-01 at 18:01 -0600, David Updegraff wrote:
> Hi.
> 
> I have a gadget with this amd chip on it.  Whose id and layout dfn. is 
> not in the jedec_probe tables.  Unfortuanately, they have _SIX_ (6) 
> erase regions.  Anyone know of a reason expanding the regions[] array to 
> 6 is a bad idea?  Or why dealing with this chip in general is a bad idea?

Hmmm. And this chip really doesn't do CFI?

I wonder how much space we take up with this table, and if we should put
the regions outside the table rather than inline ("ulong *regions").
> 
> ______________________________________________________________________
-- 
dwmw2

Re: patch for AMD am29dl800b

[David Updegraff]

> Please don't reply to unrelated threads. This isn't about bad blocks and
> doesn't live with the message to which you replied.

Whoops.. me aculpa.

> 
> On Thu, 2004-04-01 at 18:01 -0600, David Updegraff wrote:
> 
>>Hi.
>>
>>I have a gadget with this amd chip on it.  Whose id and layout dfn. is 
>>not in the jedec_probe tables.  Unfortuanately, they have _SIX_ (6) 
>>erase regions.  Anyone know of a reason expanding the regions[] array to 
>>6 is a bad idea?  Or why dealing with this chip in general is a bad idea?
> 
> 
> Hmmm. And this chip really doesn't do CFI?

My attempts at that failed; and their PDF only says 'JEDEC compatible'.

> I wonder how much space we take up with this table, and if we should put
> the regions outside the table rather than inline ("ulong *regions").

.. or invent a command-line syntax; since in embedded situations one 
usually knows what one is looking for.. or has that alredy been 
discussed and discarded?

-dbu.

Re: patch for AMD am29dl800b

[David Woodhouse]

On Fri, 2004-04-02 at 07:30 -0600, David Updegraff wrote:
> > Hmmm. And this chip really doesn't do CFI?
> 
> My attempts at that failed; and their PDF only says 'JEDEC compatible'.

OK.

> > I wonder how much space we take up with this table, and if we should put
> > the regions outside the table rather than inline ("ulong *regions").
> 
> .. or invent a command-line syntax; since in embedded situations one 
> usually knows what one is looking for.. or has that alredy been 
> discussed and discarded?

You assume far too much competence on the part of the people who would
be expected to provide such arguments. You _can_ write a map driver
which bypasses the probe and set up the appropriate command set
directly, I think. There's not really much need to -- if you're _that_
concerned about bloat you won't be using Linux in the first place.

I've committed your patch; thanks.

-- 
dwmw2

Re: Bad blocks

[Greg Ungerer]

David Woodhouse wrote:
> On Thu, 2004-04-01 at 17:06 +0300, Kalev Lember wrote:
>>I am going to use DOC Millennium Plus and I do not want to use M-Systems 
>>propietary kernel modules.
>>Having read the mailing list archives I have some questions.  Does current 
>>INFTL code support bad block handling? Without that I would say it is 
>>virtually useless. Am I correct?
> 
> 
> It doesn't, and you're probably correct, yes.
> 
> This is fairly high up on my TODO list but keeps getting preempted by
> RealWork(tm). Are you volunteering? It shouldn't be too hard.

Yeah, high on my todo list as well. But I am not going to
get to it any time soon. It should be quite simple to do.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

Re: Bad blocks

[Kalev Lember]

On Thu, 1 Apr 2004, David Woodhouse wrote:
> On Thu, 2004-04-01 at 17:06 +0300, Kalev Lember wrote:
> > INFTL code support bad block handling? Without that I would say it is 
> 
> This is fairly high up on my TODO list but keeps getting preempted by
> RealWork(tm). Are you volunteering? It shouldn't be too hard.

No, I could not do it because I do not have a developing platform, I have 
only access to some devices that have DoC soldered on their mainboards. 
They can boot only from DoC, currently using M-Systems driver and linux. 
If I were to make one unbootable the would have to reflash it in the 
manufacturers plant. Sorry.

-- 
Kalev Lember

Bad Blocks...

[Eddie Dawydiuk]

Hello Yaffers,

After running some stress tests on a 128MB NAND Flash I have found some
strange behavior while using the Yaffs filesystem... The stress test
creates a ring-buffer of 5 directories, each directory contains 10,000
files with a size of 1248 bytes (Please find the source code attached). 
When running this application on a 32MB NAND Flash I am able to fill the
disk and then delete the files as expected... Although when running the
test on a 128MB NAND Flash(with the same kernel) I find that after
creating slightly over 35,000 files I am unable to write any more files to
disk(my board hangs). After rebooting the board, when I attempt to delete
the files only some of the files are deleted successfully(on the first
attempt). After attempting several more times I am able to delete all of
the files but I find that I have hundreds of bad blocks(there are no error
messages when I attempt to delete a file and it is unsucessfully deleted).
I have provided the output of /proc/yaffs below(after running the stress
test multiple times) and am using a 2.4.26 kernel... I have read the other
posts refering to bad block management
(http://www.aleph1.co.uk/pipermail/yaffs/2005q1/000955.html) and have
ensured the fixes suggested have been made. If anyone has any suggestions
I would appreciate them...

$ cat /proc/yaffs
YAFFS built:Apr 26 2005 10:44:45
$Id: yaffs_fs.c,v 1.3 2005/01/25 00:38:25 eddie Exp $
$Id: yaffs_guts.c,v 1.41 2005/04/24 08:54:36 charles Exp $

Device yaffs
startBlock......... 1
endBlock........... 7999
chunkGroupBits..... 2
chunkGroupSize..... 4
nErasedBlocks...... 1575
nTnodesCreated..... 35000
nFreeTnodes........ 21790
nObjectsCreated.... 34400
nFreeObjects....... 21795
nFreeChunks........ 142801
nPageWrites........ 71420
nPageReads......... 2573700
nBlockErasures..... 4021
nGCCopies.......... 317
garbageCollections. 3599
passiveGCs......... 3599
nRetriedWrites..... 0
nRetireBlocks...... 2397
eccFixed........... 0
eccUnfixed......... 0
tagsEccFixed....... 0
tagsEccUnfixed..... 654
cacheHits.......... 0
nDeletedFiles...... 22161
nUnlinkedFiles..... 22162
nBackgroudDeletions 0
useNANDECC......... 1

Thanks,
Eddie

Re: Bad Blocks...

[Charles Manning]

On Wednesday 27 April 2005 08:33, Eddie Dawydiuk wrote:
> Hello Yaffers,
>
> After running some stress tests on a 128MB NAND Flash I have found some
> strange behavior while using the Yaffs filesystem... The stress test
> creates a ring-buffer of 5 directories, each directory contains 10,000
> files with a size of 1248 bytes (Please find the source code attached).
> When running this application on a 32MB NAND Flash I am able to fill the
> disk and then delete the files as expected... Although when running the
> test on a 128MB NAND Flash(with the same kernel) I find that after
> creating slightly over 35,000 files I am unable to write any more files to
> disk(my board hangs). After rebooting the board, when I attempt to delete
> the files only some of the files are deleted successfully(on the first
> attempt). After attempting several more times I am able to delete all of
> the files but I find that I have hundreds of bad blocks(there are no error
> messages when I attempt to delete a file and it is unsucessfully deleted).
> I have provided the output of /proc/yaffs below(after running the stress
> test multiple times) and am using a 2.4.26 kernel... I have read the other
> posts refering to bad block management
> (http://www.aleph1.co.uk/pipermail/yaffs/2005q1/000955.html) and have
> ensured the fixes suggested have been made. If anyone has any suggestions
> I would appreciate them...


Hi Eddie

I have not tried making 35000 files on a Linux box myself, but all of this 
should work fine.

The core problem, it seems to me, is the excessive number of bad blocks being 
generated. nRetiredBlocks of 2397 shows that over a quarter of your blocks 
have been marked bad in just one run.  Anything over 1-2% in a product 
lifetime is unlhealthy.

Sever block failures will cause flow-on failures like garbage collection 
problems etc.

Block failures are generally a result of ecc errors. I see you're using NAND 
ecc, so make sure that is doing the right thing.

I suggest adding some of the low level tracing (eg. YAFFS_TRACE_BAD_BLOCKS) 
and maybe turn on more mtd tracing. Feel free to add your own too :-)

-- Charles