From: Jeff D. <jd...@ka...> - 2002-01-31 03:03:19
|
mma...@ya... said: > Actually, if you run the jffs2 test with the new blkmtd module and a > kernel without UM_FASTCALL, but all debugging enabled you get a > "Segfault with no mm" but I guess that is expected. No, it's not. This is what happens when I do mkfs.jffs2: usermode:~# ~/mkfs.jffs2 -r /mnt1/ -o /dev/mtdblock/0 -e 0x20000 -p mkfs.jffs2: write: No space left on device blkmtd: write: cant grab cache page 384 Followed by the panic. It looks to me like a blkmtd bug: write_err: while(--pagecnt) { SetPageError(pages[pagecnt]); page_cache_release(pages[pagecnt]); } If pagecnt == 0, then the loop starts at -1, which seems like a bad idea. This patch works for me (sort of cruddy though - wrapping a 'if(pagecnt > 0)' around the while might be better): --- drivers/mtd/devices/blkmtd.c~ Wed Oct 10 11:50:31 2001 +++ drivers/mtd/devices/blkmtd.c Wed Jan 30 16:44:11 2002 @@ -753,9 +753,9 @@ } write_err: - while(--pagecnt) { - SetPageError(pages[pagecnt]); - page_cache_release(pages[pagecnt]); + while(pagecnt) { + SetPageError(pages[pagecnt - 1]); + page_cache_release(pages[--pagecnt]); } kfree(pages); return err; With that, I get some nasty-looking errors: usermode:~# ./mkfs.jffs2 -r /mnt1/ -o /dev/mtdblock/0 -e 0x20000 -p mkfs.jffs2: write: No space left on device end_request: I/O error, dev 1f:00 (mtdblock), sector 7624 end_request: I/O error, dev 1f:00 (mtdblock), sector 7632 end_request: I/O error, dev 1f:00 (mtdblock), sector 7640 end_request: I/O error, dev 1f:00 (mtdblock), sector 7648 end_request: I/O error, dev 1f:00 (mtdblock), sector 7656 ... But the device can be mounted, and I see some kind of a kernel pool, which I don't understand (maybe the memory had not totally been cleared?): usermode:~# mount -t jffs2 /dev/mtdblock/0 /mnt usermode:~# cd /mnt usermode:/mnt# ls -al total 84 drwxr-xr-x 1 root root 0 Jan 30 16:49 . drwxr-xr-x 22 root root 4096 Jul 22 2001 .. -rw-r--r-- 1 root root 65986 Mar 20 2000 CREDITS drwxr--r-- 1 root root 0 Mar 20 2000 Documentation -rw-r--r-- 1 root root 15605 Mar 20 2000 Makefile Booting UML with more memory makes mkfs.jffs2 do this: usermode:~# ./mkfs.jffs2 -r /mnt1/ -o /dev/mtdblock/0 -e 0x20000 -p mkfs.jffs2: write: No space left on device and it mounts OK and there's the same kernel pool there. Your next recipe: mma...@ya... said: > 1. mkfs.jffs2 -r /mnt1/ -o /dev/rd/2 > 2. insmod blkmtd.o device=/dev/rd/2 > 3. mount -t jffs2 /dev/mtdblock/0 /mnt2 > 4. umount /dev/mtdblock/0 produces the same thing from mkfs.jffs2: usermode:~# ./mkfs.jffs2 -r /mnt1/ -o /dev/rd/2 mkfs.jffs2: write: No space left on device and this sort of thing from the mount: usermode:~# mount -t jffs2 /dev/mtdblock/0 /mnt jffs2_scan_empty(): Empty block at 0x0000ffac ends at 0x00010000 (with 0xe0021985)! Marking dirty jffs2_scan_empty(): Empty block at 0x0002fffc ends at 0x00030000 (with 0xe0021985)! Marking dirty with the same results as before. Repeating a few times did the same thing, except mkfs.jffs2 finishes immediately. So, at this point, I don't see anything wrong with UML here. Jeff |