On Thu, 2005-10-13 at 11:09 -0700, Sergey Kubushyn wrote: > 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... If its as simple as a shovel and a 5-year-old can fix it, then submit a patch to do this instead of sounding like a 5-year-old that keeps complaining that you can't get a cookie. Honey *always* works better than vinegar. > 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. Refuse? The patch only showed up yesterday. What do you expect, your patches to be accepted, tested and then integrated into CVS *before* you write them? Its not like people with CVS write access are sitting around waiting all day for pearls of wisdom to drop out of your brain. > > 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. * > ****************************************************************** > > > _______________________________________________ > yaffs mailing list > yaffs@stoneboat.aleph1.co.uk > http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs -- Peter Barada