I'm playing around with a script to unpack images to the CF, and I get the following kernel oops:

loop: loaded (max 8 devices)
blkmtd: version $Revision: 1.24 $
blkmtd: mtd4: [/dev/loop/4] erase_size = 16KiB
CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 803cc53c, ra == 803cc4c4
Oops in arch/mips/mm/fault.c::do_page_fault, line 166[#1]:
Cpu 0
$ 0   : 00000000 1000f800 81cf5de0 00000000
$ 4   : 00010000 00000001 82d73c80 8077ec30
$ 8   : 804184ac 82d73c00 00000000 804a54b4
$12   : 804a54e0 001fffff 001f0000 2ab99d3c
$16   : 00000002 807750c0 82d73914 804b0000
$20   : 10010050 10010000 00000000 00000001
$24   : 00000000 801a8118
$28   : 81cf4000 81cf5dd0 1000d1c0 803cc4c4
Hi    : 00000000
Lo    : 00000000
epc   : 803cc53c __down_write+0xe4/0x198     Tainted: P
ra    : 803cc4c4 __down_write+0x6c/0x198
Status: 1000f802    KERNEL EXL
Cause : 3080000c
BadVA : 00000000
PrId  : 00018448
Modules linked in: blkmtd loop usbhid sd_mod usb_storage scsi_mod rfmod dreambox_rc2 fp lcd xilleon avs stb_proc tu1216 alps_bsbe1 stv0299 mb86a15
Process umount (pid: 1709, threadinfo=81cf4000, task=807750c0)
Stack : 00000204 82d73c00 80420090 00000000 82d73914 10010000 807750c0 00000002
        82d73800 82d73910 82d7382c 00000000 8025a9e4 804a54b4 00000000 00000002
        00000000 00000d6c 82d73800 804b0000 80258d70 00000000 00000000 00000000
        00000000 00000000 82d73c00 804b0000 82d73c4c 80180a64 00000001 00000000
        82d73c00 804a54b4 82d73c00 804b0000 80420090 8018a900 81cf5e68 81cf5e68
        ...
Call Trace:
 [<8025a9e4>] jffs2_flush_wbuf_pad+0x20/0x50
 [<80258d70>] jffs2_sync_fs+0x60/0x180
 [<80180a64>] fsync_super+0x1a8/0x208
 [<8018a900>] generic_shutdown_super+0x50/0x27c
 [<80259538>] jffs2_kill_sb+0x14/0x3c
 [<801a98e0>] free_vfsmnt+0x18/0x34
 [<8018a890>] deactivate_super+0xdc/0xfc
 [<80194eac>] path_release_on_umount+0x18/0xd0
 [<801aa4bc>] sys_umount+0x4c/0x26c
 [<801aa4bc>] sys_umount+0x4c/0x26c
 [<8018fab8>] sys_lstat64+0x3c/0x4c
 [<8010f5c0>] stack_done+0x20/0x3c
 [<8010f5c0>] stack_done+0x20/0x3c




Code: 27a20010  afb20010  ae420004 <ac620000> afa30014  40016000  3421001f  3821001e  40816000

Basically, the program will

a) Unpack the nfi to make boot.jjfs2 and root.jffs2 filesystem images
b) Use the loopback device to make the image look like a block device
d) Use the blkmtd kernel module to add a block device as an MTD
c) Mount the simulated MTD as jffs2
d) Copy out the files
e) umount
f) remove the kernel module
g) delete the loopback

The oops happens at step e), when I try to unmount the jffs2 file system.

And yeah, it works perfectly on my PC, kernel 2.6.13.3.

Anybody?

And BTW, the loopback device (/dev/loop/*) isn't configured in the kernel. Could this be added, please? Also, I would be grateful if the standard config included the blkmtd and/or the block2mtd as modules...

Thanks. That's more or less what I've though I might have to do, and what I've hoped to avoid.

Already tried the block2mtd. Got an oops when loading the module.

Just in case anybody cares...

I've now tried a few more approaches, but with no success so far. As reported earlier, blkmtd.ko works until unmounting the file system, when I get a kernel oops, while block2mtd.ko oops when loading.

I've since tried the blkmtd.ko module, whith the same result as the blkmtd.ko. I've also tried the current mtd+jffs2 kernel from CVS, but that kernel failed to mount the root file system from flash. A bit more conservative approach using only the latest mtd sources, while leaving the jffs2 code unchanged, also failed to mount the root file system. Lots of work, no results...

I have a theory about the cause of the problem. I think it may be a spinwheel lock that is used without being initialized. It's used in "wbuf.c" in the jffs2 code, and it seems to be properly initialized only for NAND devices.

A few questions to those who knows something about this:
1) Does my theory sound reasonable? Is anybody running 2.6.12 on a PC, where blkmtd.ko works?
2) Could it be that my failure to mount the existing root partition in flash (using the latest jffs2+mtd sources) is caused by an incompatibility between the year-old jffs2 code in 2.6.12 and the current CVS? In which case, does anybody have a good guess what would be a suitable date for checking out a version that fixes some bugs, but is still compatible with the old layout?

BTW: Recent (since last fall) versions of jffs2 apparantly includes some code to speed up the initial scan of the file system, which should lead to faster boot times on the dreambox. Wouldn't it be great if DMM adopted this code and reduced the boot time by a few seconds? (Hint, hint. Nudge, nudge! )

Going back to the current CVS version of mtd+jffs2, I found out why the resulting kernel didn't mount root. Quite simple really. Devfs is deprecated in linux 2.6, and in the current CVS of mtd, support for devfs has been dropped. By adding devfs support again, + some minor fixes due to incomplete backwards compatibility with 2.6.12, I now have a kernel that seems to work.
- It compiles
- It links
- It boots from flash
What more could you want?

I'll let it run for some days to see if there are any problems. First tests looks promising. No oops anymore when unmounting a blkmtd-device.

If there's any interest, I guess I could tidy up the patches a bit and post them here. Let me know.

Zitat

Original von Lior
devfs is disabled and being removed since Linux 2.6.13, dm7025 still has the version 2.6.12 with devfs and after 2.6.13-rc3, in MTD devfs is replaced with udev like lot of drivers because devfs is abandoned by its maintainer.

Here's somebody else's view on sticking to devfs: http://lists.infradead.org/pip…d/2005-August/013385.html
Of course, I only saw this one after having experienced the same problems, and it took me more than two hours to find out that missing devfs support was the problem. Oh, the joys of kernel hacking....

Zitat

Original von Lior
if you have nothing to do other than fooling around with MTD, then try to get work YAFFS on DM7025. I've been told that YAFFS is better than JFFS2 for NAND, the only disadvantage is that YAFFS does not support compression which is not important because we all have large CFs

Actually, my fooling around with MTD wasn't only for the fun of it. I only got involved because my script to unpack an NFI to a CF caused a kernel oops. Now that problem is fixed, I hope, and I can get on with it.

But, now that I have a recent version of the mtd up and running, there are a few paths for experiments that open up:
- YAFFS
- maybe JFFS3
- summary information (see http://www.inf.u-szeged.hu/jffs2/mount.php)
YAFFS is maybe the least interesting of these paths. It only runs on NAND (not on CF, it seems) and running uncompressed on the tiny internal flash will probably hurt too much. Using summary information looks very interesting, though. It currently takes 10+ seconds to mount the root file system, so this is a major contribution to the slow boot times that we are experiencing.