From: Jeff D. <jd...@ka...> - 2002-01-29 01:31:56
|
mma...@ya... said: > .. it loops 12 times, on the 12th try it passes > {count = -65535, wait_lock = {gcc_is_buggy = 0}, wait_list = { > next = 0xa08eda3c, prev = 0xa08eda3c}} > to down_read, and then proceeds to panic. This doesn't look like it has anything to do with mtd or jffs at all. Can you go into arch/um/Makefile-i386, remove UM_FASTCALL from CFLAGS, and in .config change CONFIG_RWSEM_XCHGADD_ALGORITHM to CONFIG_RWSEM_GENERIC_SPINLOCK and see if that helps? Some versions of gcc have a bug which causes register corruption in regparam procedures when -pg is on. I'm suspicious that something similar might be going on here. Alternatively, if you have some different versions of gcc lying around, you could build UML with them and see if it behaves better. Also, can you reproduce this with a compiled kernel from the UML site? Jeff |
From: Jeff D. <jd...@ka...> - 2002-01-29 13:57:01
|
dw...@in... said: > http://sources.redhat.com/jffs2/ Hmmm, that doesn't seem too useful either. ~ 1003: wget ftp://sources.redhat.com/pub/jffs2/mkfs.jffs2 --08:57:27-- ftp://sources.redhat.com:21/pub/jffs2/mkfs.jffs2 => `mkfs.jffs2' Connecting to sources.redhat.com:21... connected! Logging in as anonymous ... Login incorrect. Jeff |
From: David W. <dw...@in...> - 2002-01-29 14:01:16
|
Must have been a temporary problem. $ wget ftp://sources.redhat.com:21/pub/jffs2/mkfs.jffs2 --13:58:30-- ftp://sources.redhat.com/pub/jffs2/mkfs.jffs2 => `mkfs.jffs2' Connecting to sources.redhat.com:21... connected! Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD /pub/jffs2 ... done. ==> PORT ... done. ==> RETR mkfs.jffs2 ... done. Length: 41,947 (unauthoritative) 0K .......... .......... .......... .......... 100% @ 19.83 KB/s 13:58:37 (19.83 KB/s) - `mkfs.jffs2' saved [41947] -- dwmw2 |
From: Jeff D. <jd...@ka...> - 2002-01-29 13:58:17
|
md...@de... said: > There's one in Debian... > Package: mtd-tools That doesn't seem to be in potato: usermode:~# apt-get install mtd-tools Reading Package Lists... Done Building Dependency Tree... Done E: Couldn't find package mtd-tools Jeff |
From: Jonathan R. <mma...@ya...> - 2002-01-29 18:20:56
|
On Tue, 29 Jan 2002, Jeff Dike wrote: > md...@de... said: > > There's one in Debian... > > Package: mtd-tools > > That doesn't seem to be in potato: That's correct. It's in testing "woody" and unstable. |
From: Jeff D. <jd...@ka...> - 2002-01-29 15:05:31
|
mma...@ya... said: > The testing kernel already had UM_FASTCALL removed, Has it been that way the whole time? If so, you should have said so. That definitely will mess up semaphores. I've just never seen it do it so reliably before. Jeff |
From: Jonathan R. <mma...@ya...> - 2002-01-29 18:08:38
|
On Tue, 29 Jan 2002, Jeff Dike wrote: > mma...@ya... said: > > The testing kernel already had UM_FASTCALL removed, > > Has it been that way the whole time? If so, you should have said so. > That definitely will mess up semaphores. I've just never seen it do it > so reliably before. It also happens with a kernel which has no debugging enabled and is compiled with UM_FASTCALL. Just to check I created a kernel with all debugging enabled except gprof, and compiled it with UM_FASTCALL, but the blkmtd module compiled for the new kernel complained about an unresolved symbol __bb_init_func. The module which predated this module complained about the same thing and an unresolved symbol mcount when running with the new no-gprof debugging kernel. 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. |
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 |
From: David W. <dw...@in...> - 2002-01-31 07:14:44
|
(In response to post archived at http://www.geocrawler.com/lists/3/SourceForge/709/0/7698482/ ) If you have problems in UML with JFFS2 on the 'mtdram' device, which just uses vmalloc'd RAM as backing store, blame me. If you have problems only when using blkmtd, the gentleman with whom you wish to speak is Simon Evans <sp...@se...>. jd...@ka... said: > usermode:~# ./mkfs.jffs2 -r /mnt1/ -o /dev/mtdblock/0 -e 0x20000 -p > mkfs.jffs2: write: No space left on device How big would the resulting JFFS2 image be? mkfs.jffs2 is like mkisofs not like mkfs.jffs2 - it doesn't just build an empty filesystem of the correct size for the device, it attempts to spew out a JFFS2 filesystem containing the entire contents of the target directory (in this case your /mnt1). > jffs2_scan_empty(): Empty block at 0x0000ffac ends at 0x00010000 (with 0xe0021985)! Marking dirty Those are harmless. They just mean you didn't tell mkfs.jffs2 the correct eraseblock size for your device - it assumed 64KiB, when it fact the blkmtd device emulates a 128KiB erase size. Nodes can't cross eraseblocks and JFFS2 then found a few bytes of empty space just before 0x10000, 0x30000 etc. - and commented upon them because it thinks it should only find empty space just before the end of an eraseblock. -- dwmw2 |
From: Jonathan R. <mma...@ya...> - 2002-02-01 19:17:26
|
> 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 As David correctly pointed out "No space left on device" means exactly that. > 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 > > So, at this point, I don't see anything wrong with UML here. I've confirmed this, but only under certain conditions. I am being to discover that the version of gcc being used is important as you've hinted, but it seems to be more than just a UM_FASTCALL/semaphore problem. I downgraded to the version of gcc you are using based on the pre-compiled uml kernel found at the sourceforge site. For the no-erasure jffs2 test using Debian gcc compilers: VERSION UM_FASTCALL RESULTS ------- ----------- ------- gcc_1:2.95.2-13 yes SUCCEEDS gcc_1:2.95.2-13 no SUCCEEDS gcc-295_1:2.95.4-2 yes FAILS gcc-295_1:2.95.4-2 no FAILS gcc-3.0_1:3.0.3-1 yes FAILS and NOT TO PRETTY gcc-3.0_1:3.0.3-1 no FAILS and NOT TO PRETTY Jonathan |
From: David W. <dw...@in...> - 2002-02-15 09:24:42
|
mma...@ya... said: > For the no-erasure jffs2 test using Debian gcc compilers: > > VERSION UM_FASTCALL RESULTS > ------- ----------- ------- > > gcc_1:2.95.2-13 yes SUCCEEDS > gcc_1:2.95.2-13 no SUCCEEDS > gcc-295_1:2.95.4-2 yes FAILS > gcc-295_1:2.95.4-2 no FAILS > gcc-3.0_1:3.0.3-1 yes FAILS and NOT TO PRETTY > gcc-3.0_1:3.0.3-1 no FAILS and NOT TO PRETTY Hmmm. What were the failure modes? And again, does it happen with the 'mtdram' device instead of the 'blkmtd' device. I run JFFS2 compiled with gcc 3.1 on MIPS and ARM systems without problems. I rarely bother with PeeCees though, and I've never used the blkmtd device. -- dwmw2 |
From: Jonathan R. <mma...@ya...> - 2002-02-15 19:45:30
|
On Fri, 15 Feb 2002, David Woodhouse wrote: > > mma...@ya... said: > > For the no-erasure jffs2 test using Debian gcc compilers: > > > > VERSION UM_FASTCALL RESULTS > > ------- ----------- ------- > > > > gcc_1:2.95.2-13 yes SUCCEEDS > > gcc_1:2.95.2-13 no SUCCEEDS > > gcc-295_1:2.95.4-2 yes FAILS > > gcc-295_1:2.95.4-2 no FAILS > > gcc-3.0_1:3.0.3-1 yes FAILS and NOT TO PRETTY > > gcc-3.0_1:3.0.3-1 no FAILS and NOT TO PRETTY > > Hmmm. What were the failure modes? And again, does it happen with the > 'mtdram' device instead of the 'blkmtd' device. This was under uml, and a compiler/uml thing; the kernel panicked. Yes, it was the blkmtd device. > I run JFFS2 compiled with gcc 3.1 on MIPS and ARM systems without problems. > I rarely bother with PeeCees though, and I've never used the blkmtd device. I'll have to give the mtdram device a try. Basically, my goal is to set-up a simulator under uml. I know setting up a jffs/jffs2 fs from within uml won't be a problem, but setting up an arm emulator will be more of a challenge. The question is this, should I port uml to arm and run it under gdb's armulator, should I set-up the armulator within uml, or are there better approaches? Jonathan |
From: Jonathan R. <mma...@ya...> - 2002-01-29 04:51:20
|
On Mon, 28 Jan 2002, Jeff Dike wrote: > mma...@ya... said: > > .. it loops 12 times, on the 12th try it passes > > {count = -65535, wait_lock = {gcc_is_buggy = 0}, wait_list = { > > next = 0xa08eda3c, prev = 0xa08eda3c}} > > to down_read, and then proceeds to panic. > > This doesn't look like it has anything to do with mtd or jffs at all. > > Can you go into arch/um/Makefile-i386, remove UM_FASTCALL from CFLAGS, > and in .config change CONFIG_RWSEM_XCHGADD_ALGORITHM to > CONFIG_RWSEM_GENERIC_SPINLOCK and see if that helps? The testing kernel already had UM_FASTCALL removed, changing the .config resulted in the compile failing with rwsem-spinlock.c:33: redefinition of `init_rwsem' (see the end of of the message for the complete log). > Some versions of gcc have a bug which causes register corruption in > regparam procedures when -pg is on. I'm suspicious that something similar > might be going on here. Yours -> (gcc version 2.95.2 20000220 (Debian GNU/Linux)) Mine -> (gcc version 2.95.4 20010703 (Debian prerelease)) > Alternatively, if you have some different versions of gcc lying around, > you could build UML with them and see if it behaves better. > > Also, can you reproduce this with a compiled kernel from the UML site? I wish I could, but in order to test these lines: mount -t hostfs none -o /tmp/gboot_non_root_1000/loopback /mnt1 mkfs.jffs2 -r /mnt1/ -o /dev/rd/2 insmod blkmtd.o device=/dev/rd/2 mount -t jffs2 /dev/mtdblock/0 /mnt2 mtd device capability has to be in the kernel, and the same thing applies in order for jffs/jffs2 to be properly compiled. Here are the configs required: # # Memory Technology Devices (MTD) # CONFIG_MTD=y CONFIG_MTD_BLKMTD=m CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y Log for failed compile with CONFIG_RWSEM_GENERIC_SPINLOCK replacement: gcc -D__KERNEL__ -I/usr/src/linux-2.4.17-9um/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fprofile-arcs -ftest-coverage -g -pg -DPROFILING -U__i386__ -Ui386 -D__arch_um__ -DSUBARCH="i386" -DNESTING=0 -D_LARGEFILE64_SOURCE -I/usr/src/linux-2.4.17-9um/arch/um/include -Derrno=kernel_errno -DPATCHLEVEL=4 -DEXPORT_SYMTAB -c rwsem-spinlock.c rwsem-spinlock.c:33: redefinition of `init_rwsem' /usr/src/linux-2.4.17-9um/include/asm/arch/rwsem.h:85: `init_rwsem' previously defined here rwsem-spinlock.c: In function `init_rwsem': rwsem-spinlock.c:34: structure has no member named `activity' rwsem-spinlock.c: In function `__rwsem_do_wake': rwsem-spinlock.c:63: structure has no member named `activity' rwsem-spinlock.c:82: structure has no member named `activity' rwsem-spinlock.c: In function `__rwsem_wake_one_writer': rwsem-spinlock.c:96: structure has no member named `activity' rwsem-spinlock.c: At top level: rwsem-spinlock.c:110: redefinition of `__down_read' /usr/src/linux-2.4.17-9um/include/asm/arch/rwsem.h:98: `__down_read' previously defined here rwsem-spinlock.c: In function `__down_read': rwsem-spinlock.c:118: structure has no member named `activity' rwsem-spinlock.c:120: structure has no member named `activity' rwsem-spinlock.c: At top level: rwsem-spinlock.c:156: redefinition of `__down_write' /usr/src/linux-2.4.17-9um/include/asm/arch/rwsem.h:123: `__down_write' previously defined here rwsem-spinlock.c: In function `__down_write': rwsem-spinlock.c:164: structure has no member named `activity' rwsem-spinlock.c:166: structure has no member named `activity' rwsem-spinlock.c: At top level: rwsem-spinlock.c:201: redefinition of `__up_read' /usr/src/linux-2.4.17-9um/include/asm/arch/rwsem.h:150: `__up_read' previously defined here rwsem-spinlock.c: In function `__up_read': rwsem-spinlock.c:206: structure has no member named `activity' rwsem-spinlock.c: At top level: rwsem-spinlock.c:218: redefinition of `__up_write' /usr/src/linux-2.4.17-9um/include/asm/arch/rwsem.h:176: `__up_write' previously defined here rwsem-spinlock.c: In function `__up_write': rwsem-spinlock.c:223: structure has no member named `activity' make[2]: *** [rwsem-spinlock.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4.17-9um/lib' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.17-9um/lib' make: *** [_dir_lib] Error 2 |
From: Jeff D. <jd...@ka...> - 2002-01-29 05:16:19
|
Is there a deb of the mtd utilities anywhere? I configured mtd and jffs into UML, and it seems perfectly happy after I fixed a halt bug. I grabbed the mtd cvs and it seems pretty well unbuildable. I'm trying to get a mkfs.jffs2. Jeff |
From: Matt Z. <md...@de...> - 2002-01-29 05:22:54
|
On Tue, Jan 29, 2002 at 12:18:32AM -0500, Jeff Dike wrote: > Is there a deb of the mtd utilities anywhere? I configured mtd and jffs > into UML, and it seems perfectly happy after I fixed a halt bug. I grabbed > the mtd cvs and it seems pretty well unbuildable. There's one in Debian... Package: mtd-tools Priority: extra Section: utils Installed-Size: 424 Maintainer: David Schleef <ds...@sc...> Architecture: i386 Source: mtd Version: 20011217-3 Depends: libc6 (>= 2.2.4-4), zlib1g (>= 1:1.1.3) Filename: pool/main/m/mtd/mtd-tools_20011217-3_i386.deb Size: 122318 MD5sum: 397ace5e1dc1cb6b64cff244069572c9 Description: Memory Technology Device Tools Tools for manipulating memory technology devices, such as flash memory, Disk-On-Chip, or ROM. Includes mkfs.jffs, a tool to create JFFS (journaling flash file system) filesystems. -- - mdz |
From: Jeff D. <jd...@ka...> - 2002-01-29 13:46:32
|
md...@de... said: > There's one in Debian... > Package: mtd-tools Hmmm, I asked the little engine on debian.org for einfo (which should be part of this) and it didn't come up with that. Jeff |
From: Matt Z. <md...@de...> - 2002-01-29 20:21:58
|
On Tue, Jan 29, 2002 at 08:48:10AM -0500, Jeff Dike wrote: > md...@de... said: > > There's one in Debian... > > Package: mtd-tools > > Hmmm, I asked the little engine on debian.org for einfo (which should be > part of this) and it didn't come up with that. Indeed it is: -rwxr-xr-x root/root 3280 2002-01-14 16:02:47 ./usr/bin/einfo By default the search engine looks at stable, though. You have to select from the drop-down box for it to do otherwise. -- - mdz |
From: David W. <dw...@in...> - 2002-01-29 11:04:33
|
jd...@ka... said: > Is there a deb of the mtd utilities anywhere? I configured mtd and > jffs into UML, and it seems perfectly happy after I fixed a halt bug. > I grabbed the mtd cvs and it seems pretty well unbuildable. > I'm trying to get a mkfs.jffs2. http://sources.redhat.com/jffs2/ If the kernel code in CVS doesn't compile, let me know how and I'll fix it. If you just couldn't build mkfs.jffs2, I know about that (or at least expected it) and will fix it shortly, after I've finished massaging the code so that it works in eCos. -- dwmw2 |