JFFS2+NAND problem in 2.6.13-at91

Hi,

I was previously using 2.6.12-rc1, AT91 with JFFS2 on NAND and I had no problems whatsoever with using JFFS2 on NAND.

I recently upgraded to 2.6.13 and now JFFS2 on NAND seems a little broken ...

This is what I usually do when configuring a new board:

# flash_eraseall -j /dev/mtd3
# mount -t jffs2 /dev/mtdblock3 /mnt/NAND
# copy FS to /mnt/NAND, etc ,etc

but now the mount fails with output::

/root # mount -t jffs2 /dev/mtdblock3 /mnt/NAND jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00028038: 0xffff instead

<SNIP> much of the same ...

jffs2_scan_eraseblock(): Node at 0x00b28008 {0x1985, 0x2003, 0x00000008) has invalid CRC 0xffffffdf (calculated 0x6b7c27e6) jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00b2800c: 0x0008 instead

<SNIP> much of the same ...

jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00ff0030: 0xffff instead
Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes empty_blocks 0, bad_blocks 0, c->nr_blocks 1024
mount: Mounting /dev/mtdblock3 on /mnt/NAND failed: Input/output error

I had a look at previous posts and I couldn't find any answers, so I enabled debugging for MTD at level 3 and ... the mount worked(!) and I could write a file to NAND, reboot, remount and the file was still there. So it proves that the formatting was correct.

When I changed the MTD debugging to level 2 (or less), the mount started to fail again. Therefore something in the reading from the NAND must be incorrect.

This sounds like some sort of timing issues to me if switching on debugging output causes the system to start working.

Has anyone else seen this problem?

regards,

Aras Vaichas

<SNIP>

I did a quick experiment and I added a 1ms delay at the end of each command as a test and it "fixes" the problem.

in at91_nand.c:at91_nand_command()

        /* wait until command is processed */
        while (!my_nand->dev_ready(mtd))
                ;

        msleep(1);
}

But of course scanning and mounting now takes a very long time and this obviously isn't a permanent fix but it might help to locate where the problem code is.

Does this prove that it's a timing problem? perhaps some race condition?

regards,

Aras Vaichas

nand_base.c

Thanks for the hint, I've got my NAND working again.

I did a diff between the nand_base.c version shipped with 2.6.13 (v1.147) and 2.6.12-rc1 (v1.138) and noticed that a delay loop had been moved further down the code, I moved this delay back to where it was in v1.138 and it is now working again. i assume that there was a probably a good reason to move this delay in the first place though and I don't wish to break anything else ...

e.g.

@@ -1410,6 +1410,18 @@
                this->read_buf(mtd, &buf[i], thislen);
                i += thislen;
 
+
+               /* Apply delay or wait for ready/busy pin
+                * Do this before the AUTOINCR check, so no problems
+                * arise if a chip which does auto increment
+                * is marked as NOAUTOINCR by the board driver.
+                */
+               if (!this->dev_ready)
+                       udelay (this->chip_delay);
+               else
+                       nand_wait_ready(mtd);
+
+
                /* Read more ? */
                if (i < len) {
                        page++;

@@ -1421,16 +1433,6 @@
                                this->select_chip(mtd, -1);
                                this->select_chip(mtd, chipnr);
                        }
-
-                       /* Apply delay or wait for ready/busy pin
-                        * Do this before the AUTOINCR check, so no problems
-                        * arise if a chip which does auto increment
-                        * is marked as NOAUTOINCR by the board driver.
-                        */
-                       if (!this->dev_ready)
-                               udelay (this->chip_delay);
-                       else
-                               nand_wait_ready(mtd);
 
                        /* Check, if the chip supports auto page increment
                         * or if we have hit a block boundary.

Tom, did you want to check this? Should I submit a patch?

regards,

Aras Vaichas

Hi.

The delay_loop calibration logic has been changed in 2.6.13. It might break udelay() on some architectures.

--
Regards.
Tim.

This is the third report saying about the same problem, but the other two claimed that disabling summary helps, could you confirm this ? Or this is unrelated?

Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

perhaps unrelated, and I can't find *any* summary options in my configuration ... can you be more specific? Do you mean EBS?

Aras

Ah, ok, it is now called EBS, yes.

Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.