NFTL not recognizing disk on chip in some cases

Hi,

I followed the instructions given here :
http://lists.infradead.org/pipermail/linux-mtd/2002-October/006166.html

I used the second set of instructions (the one for 2.4.18) since I'm running an unmodified 2.4.19 kernel.

After having successfully created the filesystem on the disk on chip (I can mount it and work with it), I reboot and then the chip is no more recognized. The error happens in the NFTL module, it displays :

NFTL Driver: nftlcore.c $Revision: 1.85$ nftlmount.c $Revision: 1.25$ NFTL Media Headers at 0x18000 and 0x6cc000 disagree
Could not find valid boot record
Could not mount NFTL device

Now if I relaunch nftl_format a second time it may find "bad blocks" which didn't exist the first time. After that the chip is usually again recognized ... I can reproduce that with different disk on chip (this does probably mean that it's not the disk on chip that is on fault).

After more tries, it appears that the disk on chip is recognized after partitioning and formating ... but the problems appears once I copy a specific set of files on the disk on chip (it's not reproducible with any set of files) and umount the DOC (and try to reload the nftl module).

Any idea of what can go wrong ?

Regards,

Raphaël Hertzog - EIPM SA

running nftl_format.. if the NTFL driver is loaded then I think bad things may happen such as those you describe.

Regards
Henrik

ons 2003-01-29 klockan 13.47 skrev Raphael Hertzog:

Henrik Nordstrom <[email protected]>
MARA Systems AB

Am Mit, 2003-01-29 um 15.48 schrieb Henrik Nordstrom:

Unless the bad things are irreversible this should not be the case. AFAIR I always took care to remove the module before formating.

And it doesn't explain why I have the problem when I copy a set of files and why I doesn't have it with another set of files. Even stranger when I first copy the good set of files, then umount, remount, remove the good set of files and copy the problematic set of files then it's ok.

But if I copy the problematic set of files directly during the first mount after the partitioning/formating then I have the problem exposed in my previous mail.

Cheers,

Raphaël Hertzog - EIPM SA

ons 2003-01-29 klockan 17.42 skrev Raphael Hertzog:

Well.. who knows what happens if the NFTL table gets corrupted somehow due to conflict between the NFTL driver and nftl_format. I would not at all be supriced if in such case it behaves quite different depending on which fileset you copy first/how as this has impact on in which order the blocks is beeing used by the filesystem.

But if you are sure the NFTL driver was removed from the system when you ran nftl_format then it must be something else..

As of yet I have only formatted our DOC chips using the DFORMAT tool. Feels like a safer approach. And with the current GRUB patch you should be able to install GRUB direcly using DFORMAT 5.X as a binary partition image.

Note: For various reaosns (mainly lack of time and lab equipment to try out a new scheme) we are still using the msys drivers and a normal grub loading from the doc via the msys BIOS. Hope to switch to native Linux/GRUB drivers shortly.

Henrik Nordstrom <[email protected]>
MARA Systems AB

FWIW, I have seen the same problems you describe, but was never able to get to the point where it was repeatable.

The one thing that always seemed to get the DoC back to a reasonable state was running the M-Sys DFORMAT utility -- in your case, version 4.2. For instance, if I had somehow corrupted the DoC with the nftl module loaded when it shouldn't have been, subsequent nftl_format commands (even without nftl loaded) didn't seem to make things right again.

Mark

Does one of your files have 'ANAND' at the start of it (or at an offset of n*512 bytes withing the file? :)

That may get seen as an 'extra' NFTL media header sector; we should do more sanity checks and refrain from looking inside an already-detected NFTL partition.

Because in the first case the 'ANAND' went somewhere other than the first page of an erase block, so wasn't seen as an 'extra' media header? Taking raw dumps of the flash would confirm this.

dwmw2

Am Mit, 2003-01-29 um 23.41 schrieb David Woodhouse:

Yes.

$ find . -type f | xargs grep -l ANAND
./root/lib/modules/2.4.19-eipm/kernel/drivers/block/doc.o
./root/lib/modules/2.4.19-eipm/kernel/drivers/block/doc/doc.o
./root/usr/lib/grub/i386-pc/stage2
./root/usr/lib/grub/i386-pc/grub_firmware

After inspection, grub_firmware does have 'ANAND' at offset 87040 (170 * 512).

I'm happy to test any patch since I can reproduce the problem here very regularly ... :-)

I'll do that to check it.

Cheers,

Raphaël Hertzog - EIPM SA

Index: drivers/mtd/nftlmount.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/nftlmount.c,v
retrieving revision 1.31

diff -u -p -r1.31 nftlmount.c
@@ -137,7 +137,11 @@ static int find_boot_record(struct NFTLr
 				printk(KERN_NOTICE "NFTL Media Headers at 0x%x and 0x%x disagree.\n",
 				       nftl->MediaUnit * nftl->EraseSize, block * nftl->EraseSize);
 				/* if (debug) Print both side by side */
-				return -1;
+				if (boot_record_count < 2) {
+					/* We haven't yet seen two real ones */
+					return -1;
+				}
+				continue;
 			}
 			if (boot_record_count == 1)
 				nftl->SpareMediaUnit = block;

dwmw2

Am Don, 2003-01-30 um 09.19 schrieb David Woodhouse:

Raphaël Hertzog - EIPM SA

Am Don, 2003-01-30 um 09.05 schrieb Raphael Hertzog:

It looks like you're right.

When the image is ok, the problematic ANAND is on the dump at offset 0x778800 (it's a multiple of 512 but not of 16k) ... when the image is bad it is at offset 0x6cc000 (which is a multiple of 512 and 16k).

I'm currently compiling the modules with your patch to see if it's ok.

Cheers,

Raphaël Hertzog - EIPM SA