NFTL not recognizing disk on chip in some cases

NFTL not recognizing disk on chip in some cases

[Raphael Hertzog]

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

Re: NFTL not recognizing disk on chip in some cases

[Henrik Nordstrom]

>From what I recall you must not have the NFTL driver loaded while
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:
> 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,
-- 
Henrik Nordstrom <hno@marasystems.com>
MARA Systems AB

Re: NFTL not recognizing disk on chip in some cases

[Raphael Hertzog]

Am Mit, 2003-01-29 um 15.48 schrieb Henrik Nordstrom:
> From what I recall you must not have the NFTL driver loaded while
> running nftl_format.. if the NTFL driver is loaded then I think bad
> things may happen such as those you describe.

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

Re: NFTL not recognizing disk on chip in some cases

[Henrik Nordstrom]

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

> 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.

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 <hno@marasystems.com>
MARA Systems AB

Re: NFTL not recognizing disk on chip in some cases

[Mark Meade]

On Wednesday 29 January 2003 11:42 am, Raphael Hertzog wrote:
> Unless the bad things are irreversible this should not be the case.
> AFAIR I always took care to remove the module before formating.

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

Re: NFTL not recognizing disk on chip in some cases

[David Woodhouse]

On 29 Jan 2003, Raphael Hertzog wrote:

> Am Mit, 2003-01-29 um 15.48 schrieb Henrik Nordstrom:
> > From what I recall you must not have the NFTL driver loaded while
> > running nftl_format.. if the NTFL driver is loaded then I think bad
> > things may happen such as those you describe.
> 
> 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.

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.

> 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.

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

Re: NFTL not recognizing disk on chip in some cases

[Raphael Hertzog]

Am Mit, 2003-01-29 um 23.41 schrieb David Woodhouse:
> Does one of your files have 'ANAND' at the start of it (or at an offset of 
> n*512 bytes withing the file? :)

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).

> 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.

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

> 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.

I'll do that to check it. 

Cheers,
-- 
Raphaël Hertzog - EIPM SA

Re: NFTL not recognizing disk on chip in some cases

[David Woodhouse]

On 30 Jan 2003, Raphael Hertzog wrote:

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

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
--- drivers/mtd/nftlmount.c	15 Nov 2002 16:34:43 -0000	1.31
+++ drivers/mtd/nftlmount.c	30 Jan 2003 08:19:46 -0000
@@ -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

Re: NFTL not recognizing disk on chip in some cases

[Raphael Hertzog]

Am Don, 2003-01-30 um 09.19 schrieb David Woodhouse:
> On 30 Jan 2003, Raphael Hertzog wrote:
> 
> > I'm happy to test any patch since I can reproduce the problem here very
> > regularly ... :-)
> 
> 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
> --- drivers/mtd/nftlmount.c	15 Nov 2002 16:34:43 -0000	1.31
> +++ drivers/mtd/nftlmount.c	30 Jan 2003 08:19:46 -0000
> @@ -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;

Ok. It effectively fixes the problem. It's not very nice since the
notice is still displayed ... but that doesn't matter much.

Thanks for the patch !

Cheers,
-- 
Raphaël Hertzog - EIPM SA

Re: NFTL not recognizing disk on chip in some cases

[Raphael Hertzog]

Am Don, 2003-01-30 um 09.05 schrieb Raphael Hertzog:
> > 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.
> 
> I'll do that to check it. 

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