Jffs2 write Error

Jffs2 write Error

[Phil Wilshire]

Hi Guys,

I am seeing a frequent error 

on an ARM7TDMI  system
  uClinux version 2.4.20-uc0 

Processor: Atmel AT91M40xxx revision 0
Architecture: EB01          

physmap flash device: 200000 at 1600000
Found: Atmel AT49BV32XA
number of JEDEC chips: 1

Creating 3 MTD partitions on "Physically mapped flash":
0x00000000-0x00100000 : "part1"
0x00100000-0x00200000 : "part2"
0x00200000-0x00400000 : "rest"


I have added some debugging in write.c
And I get this sort of output
I am copying a large file into the flash system.

ls -l /var/ram/mytest
-rwxr-xr-x  1 0        0          500856  Jan  1 00:00 /var/ram/mtest

cp /var/ram/mytest /var/mtd0/mytest


It all looks to be working just fine...
( PSW is my debug )
PSW Write of 2491 bytes at 0x000ac3b4 attempted. returned 0, retlen 2491
PSW Write of 2514 bytes at 0x000acd70 attempted. returned 0, retlen 2514
PSW Write of 2422 bytes at 0x000ad744 attempted. returned 0, retlen 2422
PSW Write of 2550 bytes at 0x000ae0bc attempted. returned 0, retlen 2550
PSW Write of 2523 bytes at 0x000aeab4 attempted. returned 0, retlen 2523
PSW Write of 2393 bytes at 0x000af490 attempted. returned 0, retlen 2393
PSW Write of 527 bytes at 0x000afdec attempted. returned 0, retlen 527
PSW Write of 2129 bytes at 0x0009000c attempted. returned 0, retlen 2129
 

Then I get this error

Last[3] is 66, datum is 8000066
Write of 49 bytes at 0x00090860 failed. returned -5, retlen 40
jffs2_write_dirent in garbage_collect_dirent failed: -5
Last[3] is 66, datum is 8000066
Write of 49 bytes at 0x00090894 failed. returned -5, retlen 40
jffs2_write_dirent in garbage_collect_dirent failed: -5

  which produces and IOERROR -5 =  -EIO
 

Here is the flash usage..


 /> df
Filesystem           1k-blocks      Used Available Use% Mounted on
rootfs                    1999      1999         0 100% /
/dev/ram0                 1999      1999         0 100% /
/dev/ram1                  115         8       107   7% /var
/dev/mtdblock0            1024       444       580  43% /var/mtd0  

The system was eraseall'd and then mounted before this test.
The first copy of the big file went OK the error was found on the second copy to the same file.

Any clues as to what is happening here ???


regards
  Phil Wilshire
-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768

Re: Jffs2 write Error

[Joan Dyer]

I too have encountered this error (IOERR -5).  Repeating the failed 
operation generally works but that doesn't find the cause.

I am working with a relatively new jffs2 backported to kernel 2.4.18 with 
patches.  I'm just starting to work on this; has there been any new 
information not yet on the list?

Re: Jffs2 write Error

[David Woodhouse]

On Thu, 2003-11-06 at 13:51 -0500, Joan Dyer wrote:
> I too have encountered this error (IOERR -5).  Repeating the failed 
> operation generally works but that doesn't find the cause.

It's a hardware error. Precisely what flash chip?

-- 
dwmw2

Re: Jffs2 write Error

[Joan Dyer]

> On Thu, 2003-11-06 at 13:51 -0500, Joan Dyer wrote:
> > I too have encountered this error (IOERR -5).  Repeating the failed
> > operation generally works but that doesn't find the cause.

David Woodhouse <dwmw2@infradead.org> wrote on 11/07/2003 07:24:04 PM:
> It's a hardware error. Precisely what flash chip?

Thanks for the response.  Chip is an MAD: AM29DL640.
        joan

Re: Jffs2 write Error

[Phil Wilshire]

Hi All,

Russ Dill wrote:
> 
> On Tue, 2003-11-04 at 06:37, Phil Wilshire wrote:
> > Hi Guys,
> >
> > I am seeing a frequent error
> >
> > on an ARM7TDMI  system
> >   uClinux version 2.4.20-uc0
> >
> > Processor: Atmel AT91M40xxx revision 0
> > Architecture: EB01
> >
> > physmap flash device: 200000 at 1600000
> > Found: Atmel AT49BV32XA
> > number of JEDEC chips: 1
> 

I have found my original problem.

The 
   do_write_oneword 
routine in 
  cfi_cmdset_0002.c 

was being given values for datum wider than the 16 bits
we are allowed to write to the device.
The readback being limited to 16 bits, of course , failed to match


The data was being given to do_write_oneword by gc.c 

Here is the error output

Last[3] is 66, datum is 8000066 addr 3028c
Write of 49 bytes at 0x00030264 failed. returned -5, retlen 40
jffs2_write_dirent in garbage_collect_dirent failed: -5

As you can see 8000066 is impossible to write to a 16 bit device.



I put an extra check on the word size in do_write_oneword and the error just went away.

regards  
   Phil Wilshire

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768

Re: Jffs2 write Error

[Thayne Harbaugh]

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

On Sat, 2003-11-15 at 19:44, Phil Wilshire wrote:
> I have found my original problem.
> 
> The 
>    do_write_oneword 
> routine in 
>   cfi_cmdset_0002.c 
> 
> was being given values for datum wider than the 16 bits
> we are allowed to write to the device.
> The readback being limited to 16 bits, of course , failed to match
> 
> 
> The data was being given to do_write_oneword by gc.c 

Why is gc.c passing values that aren't appropriate?

> Here is the error output
> 
> Last[3] is 66, datum is 8000066 addr 3028c
> Write of 49 bytes at 0x00030264 failed. returned -5, retlen 40
> jffs2_write_dirent in garbage_collect_dirent failed: -5
> 
> As you can see 8000066 is impossible to write to a 16 bit device.

Quite obvious.

> I put an extra check on the word size in do_write_oneword and the error just went away.

What check did you put in?  What do you mean by "the error just went
away?"  That sounds like a Heisenbug (race) more than a real solution.

-- 
Thayne Harbaugh
Linux Networx

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Jffs2 write Error

[Phil Wilshire]

Hi Thane,

Thayne Harbaugh wrote:
> 
> On Sat, 2003-11-15 at 19:44, Phil Wilshire wrote:
> > I have found my original problem.
> >
> > The
> >    do_write_oneword
> > routine in
> >   cfi_cmdset_0002.c
> >
> > was being given values for datum wider than the 16 bits
> > we are allowed to write to the device.
> > The readback being limited to 16 bits, of course , failed to match
> >
> >
> > The data was being given to do_write_oneword by gc.c
> 
> Why is gc.c passing values that aren't appropriate?
I do not know . A quick scan of the software looked OK but the 
values in the actual hardware system were wrong.
It looked like only the call from gc.c produced the bad values.

> 
> > Here is the error output
> >
> > Last[3] is 66, datum is 8000066 addr 3028c
> > Write of 49 bytes at 0x00030264 failed. returned -5, retlen 40
> > jffs2_write_dirent in garbage_collect_dirent failed: -5
> >
> > As you can see 8000066 is impossible to write to a 16 bit device.
> 
> Quite obvious.
Yes i guess so. No one caught it on the first posting though.


> 
> > I put an extra check on the word size in do_write_oneword and the error just went away.
> 
> What check did you put in?  What do you mean by "the error just went

Here is the code I added. This is a hack/fix for just this system.

The diff is against the latest CVS 
============================================================================
--- drivers/mtd/chips/cfi_cmdset_0002.c.orig    Mon Nov 17 11:37:36 2003
+++ drivers/mtd/chips/cfi_cmdset_0002.c Mon Nov 17 11:45:00 2003
@@ -769,7 +769,20 @@
        int ta = 0;
        DECLARE_RETRY_CMD_CNT();

+
        adr += chip->start;
+
+        // PSW added sanity checks here...
+       if (cfi_buswidth_is_1()) {
+               if (datum & 0xffffff00) {
+                       datum &= 0x00ff;
+               }
+       }
+       if (cfi_buswidth_is_2()) {
+               if (datum & 0xffff0000) {
+                       datum &= 0xffff;
+               }
+       }

        cfi_spin_lock(chip->mutex);
        ret = get_chip(map, chip, adr, FL_WRITING);
==============================================================


> away?"  That sounds like a Heisenbug (race) more than a real solution.
Poor wording on my part. The fix was actually correcting the error. The system now works.

I do not claim that this is a real solution. However it does enable the process to work which is
what I was trying to do.

If this helps unstick some others who are having the same problem great.
I would  like to try to find out why gc.c does not 
set up the correct values in datum but I have not managed to trace that yet.

regards
  Phil Wilshire

-- 
SDCS -- System Design & Consulting Services LLC, http://www.sysdcs.com
** Embedded Linux Training **  email me for details  
630 Springhouse Sq., Leesburg VA 20175 t: 703 669 9766 f: 703 669 9768