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 : [<c00e7ce0>] lr : [<c03858b4>] 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:
> [<c00e6c84>] (yaffs_GutsInitialise+0x0/0x1230) from [<c00e1478>] (yaffs_internal_read_super+0x4fc/0x690)
> [<c00e0f7c>] (yaffs_internal_read_super+0x0/0x690) from [<c00e1688>] (yaffs2_internal_read_super_mtd+0x24/0x34)
> [<c00e1664>] (yaffs2_internal_read_super_mtd+0x0/0x34) from [<c007fc68>] (get_sb_bdev+0x124/0x17c)
> [<c007fb44>] (get_sb_bdev+0x0/0x17c) from [<c00e16b4>] (yaffs2_read_super+0x1c/0x24)
> r8 = 00008000 r7 = C0217340 r6 = C0382000 r5 = FFFFFFF4
> r4 = C02C41E0
> [<c00e1698>] (yaffs2_read_super+0x0/0x24) from [<c007fe9c>] (do_kern_mount+0x54/0xec)
> [<c007fe48>] (do_kern_mount+0x0/0xec) from [<c00980e0>] (do_mount+0x5fc/0x634)
> [<c0097ae4>] (do_mount+0x0/0x634) from [<c0098538>] (sys_mount+0x9c/0xe8)
> [<c009849c>] (sys_mount+0x0/0xe8) from [<c0008920>] (do_mount_root+0x28/0xb0)
> r7 = C02D5000 r6 = C02D500D r5 = 00000000 r4 = C02D5006
> [<c00088f8>] (do_mount_root+0x0/0xb0) from [<c0008a90>] (mount_block_root+0xe8/0x1b8)
> r4 = C02D5006
> [<c00089a8>] (mount_block_root+0x0/0x1b8) from [<c0008cd8>] (prepare_namespace+0x88/0xd0)
> [<c0008c50>] (prepare_namespace+0x0/0xd0) from [<c001c170>] (init+0x104/0x1cc)
> r5 = C0019310 r4 = C01E1F54
> [<c001c06c>] (init+0x0/0x1cc) from [<c003925c>] (do_exit+0x0/0xbcc)
> r6 = 00000000 r5 = 00000000 r4 = 00000000
> Code: 15963014 e2842014 e2861014 15843014 (15832004)
>
>
> >>PC; c00e7ce0 <yaffs_GutsInitialise+105c/1230> <=====
>
> >>r7; c0217340 <nlmsvc_procedures+30c/360>
> >>r5; c0019310 <af_unix_init+24/80>
> >>r4; c01e1f54 <crc32table_le+2e0/400>
>
> Code; c00e7cd0 <yaffs_GutsInitialise+104c/1230>
> 00000000 <_PC>:
> Code; c00e7cd0 <yaffs_GutsInitialise+104c/1230>
> 0: 15963014 ldrne r3, [r6, #20]
> Code; c00e7cd4 <yaffs_GutsInitialise+1050/1230>
> 4: e2842014 add r2, r4, #20 ; 0x14
> Code; c00e7cd8 <yaffs_GutsInitialise+1054/1230>
> 8: e2861014 add r1, r6, #20 ; 0x14
> Code; c00e7cdc <yaffs_GutsInitialise+1058/1230>
> c: 15843014 strne r3, [r4, #20]
> Code; c00e7ce0 <yaffs_GutsInitialise+105c/1230>
> 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 <
Peter.B@LogicPD.com>
(text/plain)