Nand flash: hang after erase

[Elizabeth Clarke]

I'm playing with nandtest on an mtd partition, and found it hangs after
it has erased the first block. Putting in some debug I find that it gets
as far as the schedule call in mtdchar.c mtd_ioctl line 324. Here's a
snapshot:

/*
FIXME: Allow INTERRUPTIBLE. Which means
not having the wait_queue head on the stack.

If the wq_head is on the stack, and we
leave because we got interrupted, then the
wq_head is no longer there when the
callback routine tries to wake us up.
*/
ret = mtd->erase(mtd, erase);
if (!ret) {
set_current_state(TASK_UNINTERRUPTIBLE);
add_wait_queue(&waitq, &wait);
if (erase->state != MTD_ERASE_DONE &&
erase->state != MTD_ERASE_FAILED)
schedule();
remove_wait_queue(&waitq, &wait);
set_current_state(TASK_RUNNING);
ret = (erase->state == MTD_ERASE_FAILED)?-EIO:0;
}

Since I'm still on the beginning of the learning curve somewhat I have
no idea what this is trying to achieve, or where to go from here. Ideas,
pointers, please?

Ta,
Beth

[David Woodhouse]

Post by Elizabeth Clarke
I'm playing with nandtest on an mtd partition, and found it hangs
after it has erased the first block. Putting in some debug I find that
it gets as far as the schedule call in mtdchar.c mtd_ioctl line 324

What is erase->state? If the erase attempt has completed, either
successfully or otherwise, it should be one of the two values which
prevents the call to schedule().

--
dwmw2

[Elizabeth Clarke]

Post by David Woodhouse
What is erase->state? If the erase attempt has completed, either
successfully or otherwise, it should be one of the two values which
prevents the call to schedule().

erase->state is zero... nand_erase is not setting it appropriately. I
bunged in a line instr->state = MTD_ERASE_DONE; on the way out and now
getting further.

Beth

[Elizabeth Clarke]

Post by Elizabeth Clarke
erase->state is zero... nand_erase is not setting it appropriately. I
bunged in a line instr->state = MTD_ERASE_DONE; on the way out and now
getting further.

hmmm, interesting. Further means as far as noticing nandtest seems to
trash the manufacturers info. Doh, I should have realised that.

And this whilst mounting jffs2:

JFFS2: Erase block at 0x00014000 is not formatted. It will be
erased nand_read_ecc: from = 0x00016000, len =
4096 nand_read_ecc: Failed ECC read,
page 0x000000b1
mtdblock_release
nand_sync: called
ok
mount: Mounting /dev/mtdblock0 on /mnt/jffs2 failed: Invalid argument

Which is where I believe I had a genuine bad block. I thought JFFS2 is
supposed to handle bad blocks? Or have I got the wrong impression...

Beth

[Thomas Gleixner]

Post by David Woodhouse

Post by Elizabeth Clarke
I'm playing with nandtest on an mtd partition, and found it hangs
after it has erased the first block. Putting in some debug I find that
it gets as far as the schedule call in mtdchar.c mtd_ioctl line 324

What is erase->state? If the erase attempt has completed, either
successfully or otherwise, it should be one of the two values which
prevents the call to schedule().

Hi !
I had the same problem some time ago. I sent my patches along with some
rewrite for better support of different hardware to Steven Hill, who
obviously maintains this nand stuff. I never got an answer.

The included diff is against kernel 2.4.17.

The change in nand.c made NAND running. I have implemented JFFS and it works
good (only mount time is a little bit ugly). I will try JFFS2 in the next
weeks.

Thomas
__________________________________________________
Thomas Gleixner, autronix automation GmbH
auf dem berg 3, d-88690 uhldingen-muehlhofen
fon: [phone] , fax: [phone]
mail: gleixner at autronix.de, http: www.autronix.de ?

Diff following:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mtd.diff.bz2
Type: application/x-bzip2
Size: 3890 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20020124/30055aa2/attachment.bz2