[Yaffs] Sorry state of YAFFS2
Sergey Kubushyn
ksi at koi8.net
Thu Oct 13 19:09:01 BST 2005
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 : [<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 at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
More information about the yaffs
mailing list