First of all, I must tell ya that your mailing list is extremely selective in sending messages. I did NOT get your message in the mail. Ian's message also didn't come through. Other messages did. That's why your message had been copied and inserted into this email by hand. Do you think I'd miss your posting thus making you "right" in having the last word? It's kinda childish... > On Thursday 13 October 2005 07:31, ian at brightstareng.com wrote: > > On Wednesday 12 October 2005 12:57, Sergey Kubushyn wrote: > > > Guys, nand_read_oob() (and write too) _NEVER_ read (write) > > > oobavail part, it has _ALWAYS_ been working with _RAW_ oob > > > data !!! That is from as far back as I can see until today. > > > Your mtdif2.c file used to read the oob and pack tags from it > > > starting with bad block indicator and following reserved byte > > > since version 1.0 and it still does that in the latest > > > version. That means YAFFS2 _NEVER, EVER_ worked at all. > > > > See postings titled: [Yaffs] yaffs2 oob offset problem > > from August 2005. > > http://www.aleph1.co.uk/pipermail/yaffs/2005q3/subject.html > > > > Others have had similar problems, and others *do* have Yaffs2 > > working after various MTD/YAFFS hacking. > > > > I didn't see the original posting since Sergey has a special place in my kill > file, but the point made above is quite frustrating for me and most of the > YAFFSers wanting a "just works" scenario. > > I think the actual URL Ian wanted to post was: > http://www.aleph1.co.uk/pipermail/yaffs/2005q3/001411.html > > There is a problem with the mtd interface, that I have raised a few times with > the mtd folks. There is currently no way to read just the OOB with > AUTOPLACE. As Ian says, people have had to hack things to make this work. This is exactly the kind of attitude that makes YAFFS a pile of trash. You are complaining about MTD for more than a year as far as I can see (probably more.) You are keeping the source that NEVER EVER worked in your CVS but this does not keep you from beating the drum with "It works, everybody uses it, it's of production quality". You are adding some cosmetic patches from whoever you like ignoring critical ones from those you don't. Your source still has more serious bugs than a stray dog has fleas but you are denying it and use that very same mantra "Fix your MTD". It looks like mania grandiosa to me -- YAFFS is NOT the Earth's navel, it's not all that important that MTD guys would rush to rewrite a perfectly working, well documented software to make you happy and chear your laziness to do a trivial job. Nobody complains about MTD, just a couple of YAFFS guys. One more time -- there is absolutely no need to fix MTD. It works perfectly and it does exactly what it tells. It is YOUR responsibility to get those YAFFS tags from a raw OOB. There in NO such thing as "just OOB", OOB is the entire 64-bit area per 2K page in current large page devices. It is not even special in any sence any more, there is no separate "Read OOB" command. AUTOPLACE is not magic, it's as simple as a shovel. You just have to read nand_oobinfo structure from mtd and act accordingly to its oobavail field. This is SO trivial that 5 year child can do it in half an hour. But you keep your source that NEVER EVER worked in CVS and constantly bitching about MTD. That does not have anything to do with it, that is YOU who must make trivial fixes to your code. I would've been very surprised if MTD guys had done something for you... Furthermore, while MTD "does not work" what is the sence for keeping non-working code in CVS? If "MTD requires a fix", why didn't you put some kind of README describing the required fix? Do you think every single person that got that pile of trash from your CVS has to read the entire mailing list archive first to hack their kernels for that trash to work? If such a hack is "required" and "a lot" of people already did it why it is NOT documented? Put it somewhere in the CVS so everybody would know that MTD "requires fixing" and be able to make your wonderful FS working. And if it's really an MTD fault, grateful users of your wonderFS will start bitching about buggy and deficient MTD that will make MTD guys to fix it... > YAFFS **has** been working well for many people and has been in various > shipping products for well over a year now - just not those who insist on > using a stock mtd. Some guys can make a pig fly. But that does NOT mean that pigs fly. Your CVS YAFFS2 source NEVER EVER worked. Making it work with existing MTD API is trivial but you stubbornly avoid making that fix even being given a patch to do it constantly bitching about MTD. That MTD does NOT exist, it's a a model of a spherical horse in vacuum that will never materialize. As a matter of fact, to make your wonderFS work somehow only requires tiny changes in just 2 lines of code as my patch demonstrates. And that 2 line patch also fixes writing 64 bytes from a pointer to a 25 bytes long structure. I won't even tell that yaffs_ECCOther structure has one unsigned char and two unsigned int's so casting it's pointer to (__u8 *) is very bad idea... And your code is full of such pearls... There was not also possible to make Linux kernel mount your existing YAFFS2 as root filesystem. The second patch is also trivial 2-liner and you also refuse to apply it. Can you explain (not to me, to all those poor guys who do believe you want your source work) why? Are you waiting not only for some magical MTD that would make it work but also for some magical, made especially for your wonderFS Linux kernel? If so I can tell ya it will NEVER happen. > I have suggested a few fixes, and Thomas has acknowledged the problem and said > a fix is coming, but I have not seen anything new. I would be very suprised if you had. There is NO problem in MTD, the problem is in your code. Don't consider yourself a Napoleon, use existing API. Remeber, MTD is a part of Linux kernel and your wonderFS is not even close so it is YOU who has to make your stuff work with the kernel. Kernel does NOT require YAFFS, it's good enough without it so it's just plain stupid to expect it to change API to accomodate your stuff. And remember, JFFS3 is coming so your stuff will probably become obsolete in foreseable future and it's very unlikely it will make it into the kernel at all. And it is 101% sure it will not if you keep that attitude. > What would be really nice is if someone could take this issue, fix it on both > sides and work the changes back into mtd CVS. There is no second side. All the problems are in your code. Just think of kernel API as a law of nature. Gravity is not going to change just because you came there. As a matter of fact kernel API DO sometimes change but only for a very significant reason. Yours is not the one, especially when you FS is farther from getting in the kernel than Earth from Epsilon Eridani... I suggest that you should probably throw away that "Fix your MTD" drum and work on bugs. Try to explain, e.g. why 36 Mbyte UNCOMPRESSED tar archive takes 56 Mbytes when untarred onto YAFFS2 FS while it took exactly 36 Mbytes on YAFFS1. Try to fix that "write-once" bug that makes removed files' space irrevocably lost after remount. Try to fix those spurious "page XXXXX in gc has no object" errors after YAFFS2 remounted ultimately leading to spectacular crashes when trying to mount it as a root FS. Just to have you started, here is the decoded OOPS from such a crash: === Cut === ksymoops 2.4.11 on i686 2.6.12-1.1456_FC4smp. Options used -v vmlinux (specified) -K (specified) -L (specified) -O (specified) -m System.map (specified) -t elf32-littlearm -a arm Unable to handle kernel NULL pointer dereference at virtual address 00000004 Internal error: Oops: 805 [#1] CPU: 0 pc : [] lr : [] Not tainted sp : c02d9c98 ip : 000000a7 fp : c02d9d20 r10: c02e4000 r9 : c02e0934 r8 : c02e083c r7 : 00000000 r6 : c02e03e0 r5 : c0385000 r4 : c02e0934 r3 : 00000000 r2 : c02e0948 r1 : c02e03f4 r0 : c02e03e0 Flags: NzCv IRQs on FIQs on Mode SVC_32 Segment kernel Control: C000317F Table: 20004000 DAC: 00000017 Stack: (0xc02d9c98 to 0xc02da000) 9c80: c0396000 c0383800 9ca0: c02e083c ffffffff 00000000 00000005 aaaaaaaa 00000001 00000105 00000000 9cc0: 00000000 00000000 00000000 00000000 00000000 00001001 00000001 00000001 9ce0: 00000000 00000000 00000003 00000000 00000000 55555555 c0385000 c0350c00 9d00: c0371a00 c0217320 00000000 c02d9ec0 00000000 c02d9d6c c02d9d24 c00e1478 9d20: c00e6c94 6264746d 6b636f6c c02d0032 00000000 c0371b40 00000009 00000009 9d40: c02d9d80 c0371b40 c02c9bbc c0371a00 c02c9ba0 00008000 00000000 00000000 9d60: c02d9d7c c02d9d70 c00e1688 c00e0f8c c02d9dc0 c02d9d80 c007fc68 c00e1674 9d80: 6264746d 6b636f6c 00000032 60000013 c03747a0 c03747a0 c02c41e0 c0382000 9da0: c02c41e0 fffffff4 c0382000 c0217340 00008000 c02d9dd4 c02d9dc4 c00e16b4 9dc0: c007fb54 c00e1664 c02d9dfc c02d9dd8 c007fe9c c00e16a8 00008000 c0381000 9de0: 00000000 c0382000 00000000 c0380000 c02d9f28 c02d9e00 c00980e0 c007fe58 9e00: c02d9e0c c02d9e44 c02d9e14 c00929fc c00f8cb0 c02c7664 c02d5001 00000000 9e20: c02d9f3c c02d8000 c02c6ca0 00000000 c02c7664 c02d9e80 c02d9e44 c02d9e78 9e40: c02d9e4c c005c3ec c005bdf8 00000000 c02d8000 c0210e24 c0210e34 00000000 9e60: 00000002 60000093 c02d8000 c02d9eb8 c02d9e7c c005c8c8 c005c31c 00000003 9e80: 00000003 60000013 000000d0 00000000 c0210e08 00000001 000000d0 c0211174 9ea0: 00000000 00000000 c02ced60 c02d9ef8 c02d9ebc c005cad4 c005c648 00000000 9ec0: c02c7554 c02c4600 00000010 60000013 00000000 00000001 00000001 00000000 9ee0: 00008000 c025a028 c01e20a4 c02d9f08 c02d9efc c005cdbc c005ca04 c02d9f28 9f00: 00000000 00000000 c0381000 00008000 00008000 c025a028 c01e20a4 c02d9f58 9f20: c02d9f2c c0098538 c0097af4 00000000 00000000 c0382000 c0380000 c02d5006 9f40: 00000000 c02d500d c02d5000 c02d9f70 c02d9f5c c0008920 c00984ac 00000000 9f60: c02d5006 c02d9fbc c02d9f74 c0008a90 c0008908 c02d9f89 00000000 01f00002 9f80: c0019854 c024ea38 00000000 00000000 00000000 c00198a4 c0019854 00000001 9fa0: 00000000 00000000 00000000 00000000 c02d9fd8 c02d9fc0 c0008cd8 c00089b8 9fc0: 00000000 c01e1f54 c0019310 c02d9ff4 c02d9fdc c001c170 c0008c60 00000000 9fe0: 00000000 00000000 00000000 c02d9ff8 c003925c c001c07c bfdfdbff fabfbf7c Backtrace: [] (yaffs_GutsInitialise+0x0/0x1230) from [] (yaffs_internal_read_super+0x4fc/0x690) [] (yaffs_internal_read_super+0x0/0x690) from [] (yaffs2_internal_read_super_mtd+0x24/0x34) [] (yaffs2_internal_read_super_mtd+0x0/0x34) from [] (get_sb_bdev+0x124/0x17c) [] (get_sb_bdev+0x0/0x17c) from [] (yaffs2_read_super+0x1c/0x24) r8 = 00008000 r7 = C0217340 r6 = C0382000 r5 = FFFFFFF4 r4 = C02C41E0 [] (yaffs2_read_super+0x0/0x24) from [] (do_kern_mount+0x54/0xec) [] (do_kern_mount+0x0/0xec) from [] (do_mount+0x5fc/0x634) [] (do_mount+0x0/0x634) from [] (sys_mount+0x9c/0xe8) [] (sys_mount+0x0/0xe8) from [] (do_mount_root+0x28/0xb0) r7 = C02D5000 r6 = C02D500D r5 = 00000000 r4 = C02D5006 [] (do_mount_root+0x0/0xb0) from [] (mount_block_root+0xe8/0x1b8) r4 = C02D5006 [] (mount_block_root+0x0/0x1b8) from [] (prepare_namespace+0x88/0xd0) [] (prepare_namespace+0x0/0xd0) from [] (init+0x104/0x1cc) r5 = C0019310 r4 = C01E1F54 [] (init+0x0/0x1cc) from [] (do_exit+0x0/0xbcc) r6 = 00000000 r5 = 00000000 r4 = 00000000 Code: 15963014 e2842014 e2861014 15843014 (15832004) >>PC; c00e7ce0 <===== >>r7; c0217340 >>r5; c0019310 >>r4; c01e1f54 Code; c00e7cd0 00000000 <_PC>: Code; c00e7cd0 0: 15963014 ldrne r3, [r6, #20] Code; c00e7cd4 4: e2842014 add r2, r4, #20 ; 0x14 Code; c00e7cd8 8: e2861014 add r1, r6, #20 ; 0x14 Code; c00e7cdc c: 15843014 strne r3, [r4, #20] Code; c00e7ce0 10: 15832004 strne r2, [r3, #4] <0>Kernel panic - not syncing: Attempted to kill init! === Cut === --- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************