EBH question 1

Zhao,

did JFFS2 work in your test in this case:

1. flash_eraseall -j /dev/mtd0
flash_eraseall is *old*, it puts cleanmarkers and is not EBH-aware.

2. mount jffs2
3. copy any file to jffs2
4. unmount
5. mount

?

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

Yes, it can work. I have tested before checking in the patch. In particular it handled the eraseblocks with cleanmarker by the old way and cleanmarker is replaced by EBH after an erase operation happened to an eraseblock.

Thanks,
Forrest

Now it doesn't work :-(

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

Hi, Artem

The following is what I do in my lab:
1 download MTD snapshot of 2005/10/30(the snapshot before I check in EBH patch)
2 ./patchkernel.sh -c -2 /usr/src/linux.2.6.12.2 3 make; make modules_install
4 modprobe mtdram
5 cd util/; make
6 ./flash_eraseall -j /dev/mtd0
Then kernel panic happened, seemed there's a bug in mtd_char code.

So I use another way to do the test:
1 download MTD snapshot of 2005/10/30(the snapshot before I check in EBH patch)
2 ./patchkernel.sh -c -2 /usr/src/linux.2.6.12.2 3 make; make modules_install
4 modprobe mtdram
5 mount -t jffs2 /dev/mtdblock0 /mnt
6 copy two files to /mnt
7 umount /mnt
8 download MTD snapshot of 2005/11/10(the snapshot with EBH patch)
9 ./patchkernel.sh -c -2 /usr/src/linux.2.6.12.2 10 make; make modules_install
11 mount -t jffs2 /dev/mtdblock0 /mnt
12 the previously copied two files are still there 13 run ltp fs test on /mnt
14 nothing wrong happened, no error report

May I know what happened at your side?

Thanks,
Forrest

Sorry for the typo, this should be 2005/12/10
instead of 2005/11/10

Zhao

I tried CVS head (Dec 12). I used 2.6.14.3 on x86 and Nandsim. 2.6.14 requires removal of the second NULL argument (parent) to class_device_create() call to make it work.

I erased the partition with flash_eraseall (I tried both -j and without). I mounted the partition, copied big file (libc) onto it, unmounted, and then mounted again.

All messaged are directed to console, When I mount the file system again, I get:

  # mount -t jffs2 /dev/mtdblock0 /mnt
  ...
  Dec 13 12:53:15 slayer kernel: Node at 0x00001e30 with length 0x000008e0 would run over the end of the erase block 
  Dec 13 12:53:15 slayer kernel: Perhaps the file system was created with the wrong erase size? Reject to mount.
  Dec 13 12:53:15 slayer kernel: [JFFS2 DBG] (3602) jffs2_do_mount_fs: build_fs failed
  mount: /dev/mtdblock0: can't read superblock

I can reproduce the same problem on an Arm based test board with 2.6.15-rc4 with Nandsim and Onenandsim. On 2.6.15 class_device_create() call works out of the box and no editing is needed.

Jarkko Lavinn

Actually even without that patch JFFS2 doesn't work. I don't know which regression tests you did, but JFFS2 fails to do simle a thing:

mount
copy a file
unmount
mount

and it is reproducable on nandsim.

Artem.

Yes, I reproduced the bug for CVS snapshot after 2005/11/14 on kernel 2.6.12.2.
For snapshot before 2005/11/14 on kernel 2.6.12.2, JFFS2 works fine.
I just got 2.6.15-rc5 and will do the same test later.

Thanks,
Forrest

Thanks, I know that it worked before EBH. Could you please take the *lates* CVS stanpshot. Try this on nandsim.

I've fixed this revently.

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

Today I tried to build mtd latest CVS snapshot on kernel 2.6.15-rc5, but got the following error message:

WARNING: /lib/modules/2.6.15-rc5/kernel/drivers/mtd/mtdchar.ko needs unknown symbol mtd_class_device_create

I grep the whole kernel source tree, but no other files have the definition of mtd_class_device_create.

Did I miss something?

Thanks,
Forrest

Today I did the regression test on kernel 2.6.15-rc5 again, the result is the same as the one on kernel 2.6.12.2. The test steps are:
1 mount /dev/mtdblock0 to /mnt, which is a nandsim partition 2 copy a small file(2755 bytes) to /mnt
3 umount /mnt
4 mount /dev/mtdblock0 again

The CVS snapshot before 2005/11/13 is good; the snapshot after 2005/11/13 is broken. I checked in EBH patch on 2005/11/04, so this is not a bug in EBH. Anyway I'll take look at the diff between 2005/11/12 and 2005/11/13 to find the bug out.

For snapshot before 2005/11/13, I also did some stress test on /mnt, it works very well.

For snapshot after 2005/11/13, kernel panic can be easily reproduced by copying a small file.

Thanks,
Forrest