* Re: CRC errors when continuous fseek/fputs on JFFS2
[not found] <20060516061354.GA18958@wohnheim.fh-wedel.de>
@ 2006-05-16 12:40 ` syed khader
2006-05-16 14:26 ` Jörn Engel
0 siblings, 1 reply; 12+ messages in thread
From: syed khader @ 2006-05-16 12:40 UTC (permalink / raw)
To: linux-mtd
Hi
when I removed fseek/fwrite in the test case I am
not seeing any CRC errors. The modified code goes like
this :
int main()
{
int fd;
int i;
char buf[SIZE];
strcpy(buf, "abcdefg\r\n");
printf("%s", buf);
fd = open("testfile",O_RDWR|O_CREAT);
for(i =0 ; i < 10 ; i++)
{
write(fd, buf, sizeof(buf));
lseek(fd, -4, SEEK_CUR);
}
}
Why does CRC errors occur when I use fseek/fwrite
and not when I use plain system calls write/lseek??
Regards
Syed
--- J�rn Engel <joern@wohnheim.fh-wedel.de> wrote:
> On Mon, 15 May 2006 21:58:47 -0700, syed khader
> wrote:
> >
> > My question is not how the test case should be
> > written, why would CRC errors appear when I never
> > powered off my system while it is writing into
> jffs2.
> > I would like to ask what would happen if a
> integer
> > overflow occurs: does it result in crc error?
>
> Anything resulting in a crc error is a bug. But I
> cannot tell you
> much more with your current testcase. fwrite() is
> implemented by the
> libc and does buffering. Therefore it is impossible
> to tell when libc
> actually calls the kernel and which functions it
> calls with which
> parameters. And that makes debugging fairly hard.
>
> So a temporary question is indeed how the testcase
> should be written.
> Please replace the f* functions so we can remove
> libc from the
> picture.
>
> J�rn
>
> --
> Invincibility is in oneself, vulnerability is in the
> opponent.
> -- Sun Tzu
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CRC errors when continuous fseek/fputs on JFFS2
2006-05-16 12:40 ` CRC errors when continuous fseek/fputs on JFFS2 syed khader
@ 2006-05-16 14:26 ` Jörn Engel
2006-05-16 15:01 ` syed khader
0 siblings, 1 reply; 12+ messages in thread
From: Jörn Engel @ 2006-05-16 14:26 UTC (permalink / raw)
To: syed khader; +Cc: linux-mtd
On Tue, 16 May 2006 05:40:46 -0700, syed khader wrote:
>
> when I removed fseek/fwrite in the test case I am
> not seeing any CRC errors. The modified code goes like
> this :
>
> int main()
> {
> int fd;
> int i;
> char buf[SIZE];
>
> strcpy(buf, "abcdefg\r\n");
> printf("%s", buf);
> fd = open("testfile",O_RDWR|O_CREAT);
> for(i =0 ; i < 10 ; i++)
> {
> write(fd, buf, sizeof(buf));
> lseek(fd, -4, SEEK_CUR);
> }
> }
> Why does CRC errors occur when I use fseek/fwrite
> and not when I use plain system calls write/lseek??
Because it doesn't do the same thing. But what did the fseek/fwrite
version do?
Can you run the old testcase with strace? Something like
$ strace -v 1>1 2>2 your_testcase
Then send us the contents of 2.
Jörn
--
When in doubt, punt. When somebody actually complains, go back and fix it...
The 90% solution is a good thing.
-- Rob Landley
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CRC errors when continuous fseek/fputs on JFFS2
2006-05-16 14:26 ` Jörn Engel
@ 2006-05-16 15:01 ` syed khader
2006-05-16 15:31 ` Jörn Engel
0 siblings, 1 reply; 12+ messages in thread
From: syed khader @ 2006-05-16 15:01 UTC (permalink / raw)
To: J�rn Engel, syed khader; +Cc: linux-mtd
Hi
unfortunately I cannot run strace on my uclinux
console. It does not support strace. Anyways after
enabling debugging I got the following messages:
Reading 139264-139600 from node at 0x0017c66c (3)
Node read from 0017c66c: node_crc fa34d69f, calculated
CRC fa34d69f. dsize 151, csize cb, offset 22000, buf
00c97000
Read 203 bytes to 00c2aa60
Data CRC matches calculated CRC 4aab08a5
Decompress 203 bytes from 00c2aa60 to 337 bytes at
00cb4000
inflate skipping adler32
node read done
node read was OK. Looping
jffs2_read_inode_range: offset 139600, end 143360
Reading 139600-139768 from node at 0x0017c77c (3)
Node read from 0017c77c: node_crc 78842b6e, calculated
CRC 78842b6e. dsize ac, csize 90, offset 22150, buf
00c97150
Read 144 bytes to 00c2aa60
Data CRC matches calculated CRC b6cefe00
Decompress 144 bytes from 00c2aa60 to 172 bytes at
00c2ab60
inflate skipping adler32
node read done
node read was OK. Looping
jffs2_read_inode_range: offset 139768, end 143360
Reading 139768-139892 from node at 0x0017c850 (3)
Node read from 0017c850: node_crc dce8e33f, calculated
CRC dce8e33f. dsize 7e, csize 7e, offset 221f8, buf
00c971f8
Read 126 bytes to 00c915e0
Data CRC matches calculated CRC 0b89026a
node read done
node read was OK. Looping
jffs2_read_inode_range: offset 139892, end 143360
Reading 139892-139896 from node at 0x0017c914 (3)
Node read from 0017c914: node_crc 66fb0a5a, calculated
CRC 66fb0a5a. dsize 8, csize 8, offset 22274, buf
00c97274
Read 8 bytes to 00c09b60
Data CRC matches calculated CRC 6067465a
node read done
node read was OK. Looping
jffs2_read_inode_range: offset 139896, end 143360
Reading 139896-139961 from node at 0x0017c960 (3)
Node read from 0017c960: node_crc f1c73f10, calculated
CRC f1c73f10. dsize 41, csize 3f, offset 22278, buf
00c97278
Read 63 bytes to 00c0b720
Data CRC matches calculated CRC 3e33dceb
Decompress 63 bytes from 00c0b720 to 65 bytes at
00c97278
inflate skipping adler32
node read done
node read was OK. Looping
jffs2_read_inode_range: offset 139961, end 143360
Reading 139961-139964 from node at 0x0017c9e4 (3)
Node read from 0017c9e4: node_crc 57239698, calculated
CRC 57239698. dsize 4, csize 4, offset 222b9, buf
00c972b9
Read 4 bytes to 00c09b60
Data CRC 675ef222 != calculated CRC 83b8ee96 for node
at 0017c9e4
node read done
jffs2_read_inode_range error -5
readpage finished
end prepare_write(). pg->flags 10020047
jffs2_commit_write(): ino #4, page at 0x22000, range
2067-2092, flags 10020047
jffs2_write_inode_range(): Ino #4, ofs 0x22810, len
0x1c
jffs2_commit_write() loop: 0x1c to write to 0x22810
jffs2_reserve_space(): Requested 0xc4 bytes
jffs2_reserve_space(): alloc sem got
jffs2_do_reserve_space(): Giving 0x29d8 bytes at
0x17d628
calling deflate with avail_in 16, avail_out 16
deflate returned with avail_in 0, avail_out 0,
total_in 16, total_out 16
zlib compressed 16 bytes into 26; failing
jffs2_add_physical_node_ref(): Node at 0x17d628(3),
size 0x60
jffs2_write_dnode wrote node at 0x0017d628(3) with
dsize 0x1c, csize 0x1c, node_crc 0xe42c67a5, data_crc
0xca22a1bd, totlen 0x00000060
jffs2_add_full_dnode_to_inode(ino #4, f 00c481a8, fn
00cb0df0)
adding node 22810-2282c @0x0017d628 on flash, newfrag
*00cb64a4
jffs2_lookup_node_frag(00c481c0, 141328)
j_a_f_d_t_f: Lookup gave frag 0x227fc-0x22814; phys
0x0017d5cc (*00cb6488)
j_a_f_d_t_f: dealing with frag 0x227fc-0x22814; phys
0x0017d5cc (*00cb6488)
jffs2_complete_reservation()
jffs2_thread_should_wake(): nr_free_blocks 57,
nr_erasing_blocks 0, dirty_size 0x2dda4: no
increasing writtenlen by 28
jffs2_commit_write() returning 25
jffs2_dirty_inode() not calling setattr() for ino #4
jffs2_prepare_write()
jffs2_do_readpage_nolock(): ino #4, page at offset
0x22000
jffs2_read_inode_range: ino #4, range
0x00022000-0x00023000
jffs2_lookup_node_frag(00c481c0, 139264)
jffs2_read_inode_range: offset 139264, end 143360
Reading 139264-139600 from node at 0x0017c66c (3)
Node read from 0017c66c: node_crc fa34d69f, calculated
CRC fa34d69f. dsize 151, csize cb, offset 22000, buf
00c97000
Read 203 bytes to 00c2aa60
Data CRC matches calculated CRC 4aab08a5
Decompress 203 bytes from 00c2aa60 to 337 bytes at
00cb4000
inflate skipping adler32
node read done
node read was OK. Looping
jffs2_read_inode_range: offset 139600, end 143360
--- J�rn Engel <joern@wohnheim.fh-wedel.de> wrote:
> On Tue, 16 May 2006 05:40:46 -0700, syed khader
> wrote:
> >
> > when I removed fseek/fwrite in the test case I
> am
> > not seeing any CRC errors. The modified code goes
> like
> > this :
> >
> > int main()
> > {
> > int fd;
> > int i;
> > char buf[SIZE];
> >
> > strcpy(buf, "abcdefg\r\n");
> > printf("%s", buf);
> > fd = open("testfile",O_RDWR|O_CREAT);
> > for(i =0 ; i < 10 ; i++)
> > {
> > write(fd, buf, sizeof(buf));
> > lseek(fd, -4, SEEK_CUR);
> > }
> > }
> > Why does CRC errors occur when I use
> fseek/fwrite
> > and not when I use plain system calls
> write/lseek??
>
> Because it doesn't do the same thing. But what did
> the fseek/fwrite
> version do?
>
> Can you run the old testcase with strace? Something
> like
>
> $ strace -v 1>1 2>2 your_testcase
>
> Then send us the contents of 2.
>
> J�rn
>
> --
> When in doubt, punt. When somebody actually
> complains, go back and fix it...
> The 90% solution is a good thing.
> -- Rob Landley
>
>
______________________________________________________
> Linux MTD discussion mailing list
>
http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CRC errors when continuous fseek/fputs on JFFS2
2006-05-16 15:01 ` syed khader
@ 2006-05-16 15:31 ` Jörn Engel
2006-05-17 5:12 ` syed khader
0 siblings, 1 reply; 12+ messages in thread
From: Jörn Engel @ 2006-05-16 15:31 UTC (permalink / raw)
To: syed khader; +Cc: linux-mtd
On Tue, 16 May 2006 08:01:54 -0700, syed khader wrote:
>
> jffs2_read_inode_range: offset 139961, end 143360
> Reading 139961-139964 from node at 0x0017c9e4 (3)
> Node read from 0017c9e4: node_crc 57239698, calculated
> CRC 57239698. dsize 4, csize 4, offset 222b9, buf
> 00c972b9
> Read 4 bytes to 00c09b60
> Data CRC 675ef222 != calculated CRC 83b8ee96 for node
> at 0017c9e4
> node read done
This is the only mismatch I could find in your log. What I couldn't
find was the matching write to 0x0017c9e4. Still unable to see the
actual bug. Hmm.
Can you start out with a fresh image, run your testcase and get a
complete log? I hope that it contains both a crc mismatch like this
and the write of the node before.
Quite likely the log will be too large for this list. A link to a
webpage would be sufficient, if that is possible.
Jörn
--
I don't understand it. Nobody does.
-- Richard P. Feynman
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CRC errors when continuous fseek/fputs on JFFS2
2006-05-16 15:31 ` Jörn Engel
@ 2006-05-17 5:12 ` syed khader
2006-05-17 6:25 ` zlib compression is failing syed khader
0 siblings, 1 reply; 12+ messages in thread
From: syed khader @ 2006-05-17 5:12 UTC (permalink / raw)
To: Jörn Engel, syed khader; +Cc: linux-mtd
Hi
I am sending the log file after doing a fresh test.
Here is the link to the log:
http://rapidshare.de/files/20655260/jffs2crclog.txt.html
--- Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:
> On Tue, 16 May 2006 08:01:54 -0700, syed khader
> wrote:
> >
> > jffs2_read_inode_range: offset 139961, end 143360
> > Reading 139961-139964 from node at 0x0017c9e4 (3)
> > Node read from 0017c9e4: node_crc 57239698,
> calculated
> > CRC 57239698. dsize 4, csize 4, offset 222b9, buf
> > 00c972b9
> > Read 4 bytes to 00c09b60
> > Data CRC 675ef222 != calculated CRC 83b8ee96 for
> node
> > at 0017c9e4
> > node read done
>
> This is the only mismatch I could find in your log.
> What I couldn't
> find was the matching write to 0x0017c9e4. Still
> unable to see the
> actual bug. Hmm.
>
> Can you start out with a fresh image, run your
> testcase and get a
> complete log? I hope that it contains both a crc
> mismatch like this
> and the write of the node before.
>
> Quite likely the log will be too large for this
> list. A link to a
> webpage would be sufficient, if that is possible.
>
> Jörn
>
> --
> I don't understand it. Nobody does.
> -- Richard P. Feynman
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* zlib compression is failing
2006-05-17 5:12 ` syed khader
@ 2006-05-17 6:25 ` syed khader
2006-05-17 9:10 ` Jörn Engel
0 siblings, 1 reply; 12+ messages in thread
From: syed khader @ 2006-05-17 6:25 UTC (permalink / raw)
To: syed khader, J�rn Engel; +Cc: linux-mtd
Hi
in the logs I am seeing the following error
messages:
zlib compressed 68 bytes into 77; failing
why does zlib compression fail?
regards
Syed
--- syed khader <sk.syed@yahoo.com> wrote:
> Hi
>
> I am sending the log file after doing a fresh
> test.
> Here is the link to the log:
>
>
http://rapidshare.de/files/20655260/jffs2crclog.txt.html
>
>
> --- J�rn Engel <joern@wohnheim.fh-wedel.de> wrote:
>
> > On Tue, 16 May 2006 08:01:54 -0700, syed khader
> > wrote:
> > >
> > > jffs2_read_inode_range: offset 139961, end
> 143360
> > > Reading 139961-139964 from node at 0x0017c9e4
> (3)
> > > Node read from 0017c9e4: node_crc 57239698,
> > calculated
> > > CRC 57239698. dsize 4, csize 4, offset 222b9,
> buf
> > > 00c972b9
> > > Read 4 bytes to 00c09b60
> > > Data CRC 675ef222 != calculated CRC 83b8ee96 for
> > node
> > > at 0017c9e4
> > > node read done
> >
> > This is the only mismatch I could find in your
> log.
> > What I couldn't
> > find was the matching write to 0x0017c9e4. Still
> > unable to see the
> > actual bug. Hmm.
> >
> > Can you start out with a fresh image, run your
> > testcase and get a
> > complete log? I hope that it contains both a crc
> > mismatch like this
> > and the write of the node before.
> >
> > Quite likely the log will be too large for this
> > list. A link to a
> > webpage would be sufficient, if that is possible.
> >
> > J�rn
> >
> > --
> > I don't understand it. Nobody does.
> > -- Richard P. Feynman
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
>
>
______________________________________________________
> Linux MTD discussion mailing list
>
http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zlib compression is failing
2006-05-17 6:25 ` zlib compression is failing syed khader
@ 2006-05-17 9:10 ` Jörn Engel
2006-05-17 10:42 ` Josh Boyer
2006-05-17 11:22 ` syed khader
0 siblings, 2 replies; 12+ messages in thread
From: Jörn Engel @ 2006-05-17 9:10 UTC (permalink / raw)
To: syed khader; +Cc: linux-mtd
Side note: You might want to read the list etiquette. Open source
taste is a bit different and usually frowns upon things that are
perfectly acceptable in companies. In particular, when writing mails
you should only quote relevant bits from the last mail, remove
everything else, and write your answers underneith the quoted text you
are referring to. And here is the full thing:
http://www.infradead.org/~dwmw2/email.html
On Tue, 16 May 2006 23:25:52 -0700, syed khader wrote:
>
> in the logs I am seeing the following error
> messages:
>
> zlib compressed 68 bytes into 77; failing
>
> why does zlib compression fail?
When compressing data, there is always the chance that data is
actually being _expanded_ instead of compressed. Imaging compressing
a compressed file. Zlib has to add a small header and then tries to
compress the data, which doesn't work. So it simply stores the data
verbatim after the header, resulting in bigger data than before.
When this happens, jffs2 doesn't want to store the bigger "compressed"
data, but just the plain uncompressed data, saving a little flash
space.
Quite interesting, though, are the sizes. 68 bytes is exactly a jffs2
inode header. It makes me a bit uneasy if that cannot be compressed.
So maybe it is time to finally ask some basic questions:
o What kernel version are you using?
o Are there any patches on top of it?
o Is the mtd/jffs2 code from above kernel version or from cvs/git?
> > Here is the link to the log:
> >
> http://rapidshare.de/files/20655260/jffs2crclog.txt.html
I just see a page telling me to subscribe to some service. Don't you
have some other webspace you could use?
Jörn
--
I've never met a human being who would want to read 17,000 pages of
documentation, and if there was, I'd kill him to get him out of the
gene pool.
-- Joseph Costello
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zlib compression is failing
2006-05-17 9:10 ` Jörn Engel
@ 2006-05-17 10:42 ` Josh Boyer
2006-05-17 11:22 ` syed khader
1 sibling, 0 replies; 12+ messages in thread
From: Josh Boyer @ 2006-05-17 10:42 UTC (permalink / raw)
To: Jörn Engel; +Cc: linux-mtd, syed khader
On 5/17/06, Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:
>
> Quite interesting, though, are the sizes. 68 bytes is exactly a jffs2
> inode header. It makes me a bit uneasy if that cannot be compressed.
Why? JFFS2 doesn't store the node headers compressed. It shouldn't
even be trying to compress them.
josh
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zlib compression is failing
2006-05-17 9:10 ` Jörn Engel
2006-05-17 10:42 ` Josh Boyer
@ 2006-05-17 11:22 ` syed khader
2006-05-17 13:19 ` Jörn Engel
1 sibling, 1 reply; 12+ messages in thread
From: syed khader @ 2006-05-17 11:22 UTC (permalink / raw)
To: J�rn Engel, syed khader; +Cc: linux-mtd
Hi
I have uClinux2.4.24(which corresponds to 2.4
kernel). It originally had jffs2.1. Since 2.1 was
quite slow, we moved it to jffs2.2 by applying patch
from mtd cvs as follows:
cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs
login (password: anoncvs)
cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs
co mtd
cd <mtd-path>/patches
sh patchin.sh -c -j <kernel-path>
The CVS tag was D2004.05.11.18.30.00
After applying the patch I am seeing the CRC errors.
As per the logs there were zlib error messages which I
thought were the reason behind CRC errors.
Regarding this link you dont need to register: you can
select free service and download the file directly
http://rapidshare.de/files/20655260/jffs2crclog.txt.html
--- J�rn Engel <joern@wohnheim.fh-wedel.de> wrote:
> Side note: You might want to read the list
> etiquette. Open source
> taste is a bit different and usually frowns upon
> things that are
> perfectly acceptable in companies. In particular,
> when writing mails
> you should only quote relevant bits from the last
> mail, remove
> everything else, and write your answers underneith
> the quoted text you
> are referring to. And here is the full thing:
> http://www.infradead.org/~dwmw2/email.html
>
> On Tue, 16 May 2006 23:25:52 -0700, syed khader
> wrote:
> >
> > in the logs I am seeing the following error
> > messages:
> >
> > zlib compressed 68 bytes into 77; failing
> >
> > why does zlib compression fail?
>
> When compressing data, there is always the chance
> that data is
> actually being _expanded_ instead of compressed.
> Imaging compressing
> a compressed file. Zlib has to add a small header
> and then tries to
> compress the data, which doesn't work. So it simply
> stores the data
> verbatim after the header, resulting in bigger data
> than before.
>
> When this happens, jffs2 doesn't want to store the
> bigger "compressed"
> data, but just the plain uncompressed data, saving a
> little flash
> space.
>
> Quite interesting, though, are the sizes. 68 bytes
> is exactly a jffs2
> inode header. It makes me a bit uneasy if that
> cannot be compressed.
> So maybe it is time to finally ask some basic
> questions:
> o What kernel version are you using?
> o Are there any patches on top of it?
> o Is the mtd/jffs2 code from above kernel version or
> from cvs/git?
>
> > > Here is the link to the log:
> > >
> >
>
http://rapidshare.de/files/20655260/jffs2crclog.txt.html
>
> I just see a page telling me to subscribe to some
> service. Don't you
> have some other webspace you could use?
>
> J�rn
>
> --
> I've never met a human being who would want to read
> 17,000 pages of
> documentation, and if there was, I'd kill him to get
> him out of the
> gene pool.
> -- Joseph Costello
>
>
______________________________________________________
> Linux MTD discussion mailing list
>
http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zlib compression is failing
2006-05-17 11:22 ` syed khader
@ 2006-05-17 13:19 ` Jörn Engel
2006-05-17 13:48 ` syed khader
0 siblings, 1 reply; 12+ messages in thread
From: Jörn Engel @ 2006-05-17 13:19 UTC (permalink / raw)
To: syed khader; +Cc: linux-mtd
On Wed, 17 May 2006 04:22:39 -0700, syed khader wrote:
>
> I have uClinux2.4.24(which corresponds to 2.4
> kernel). It originally had jffs2.1. Since 2.1 was
> quite slow, we moved it to jffs2.2 by applying patch
> from mtd cvs as follows:
>
> cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs
> login (password: anoncvs)
> cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs
> co mtd
> cd <mtd-path>/patches
> sh patchin.sh -c -j <kernel-path>
>
> The CVS tag was D2004.05.11.18.30.00
All of that is quite old. 1.5 years for the mtd/jffs2 and 2.5 years
for 2.4.24.
Can you reproduce the same problem with current code? Either 2.6.16
or 2.4.32?
Jörn
--
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity.
-- W. A. Wulf
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zlib compression is failing
2006-05-17 13:19 ` Jörn Engel
@ 2006-05-17 13:48 ` syed khader
2006-05-17 14:28 ` David Woodhouse
0 siblings, 1 reply; 12+ messages in thread
From: syed khader @ 2006-05-17 13:48 UTC (permalink / raw)
To: J�rn Engel, syed khader; +Cc: linux-mtd
Hi
yeah that is an option. but till the time we move to
2.6 we should support 2.4 and have to resolve this
problem.
Probably looking into the changes would help.
Thanks
syed
--- J�rn Engel <joern@wohnheim.fh-wedel.de> wrote:
> On Wed, 17 May 2006 04:22:39 -0700, syed khader
> wrote:
> >
> > I have uClinux2.4.24(which corresponds to 2.4
> > kernel). It originally had jffs2.1. Since 2.1 was
> > quite slow, we moved it to jffs2.2 by applying
> patch
> > from mtd cvs as follows:
> >
> > cvs -d
> :pserver:anoncvs@cvs.infradead.org:/home/cvs
> > login (password: anoncvs)
> > cvs -d
> :pserver:anoncvs@cvs.infradead.org:/home/cvs
> > co mtd
> > cd <mtd-path>/patches
> > sh patchin.sh -c -j <kernel-path>
> >
> > The CVS tag was D2004.05.11.18.30.00
>
> All of that is quite old. 1.5 years for the
> mtd/jffs2 and 2.5 years
> for 2.4.24.
>
> Can you reproduce the same problem with current
> code? Either 2.6.16
> or 2.4.32?
>
> J�rn
>
> --
> More computing sins are committed in the name of
> efficiency (without
> necessarily achieving it) than for any other single
> reason - including
> blind stupidity.
> -- W. A. Wulf
>
>
______________________________________________________
> Linux MTD discussion mailing list
>
http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: zlib compression is failing
2006-05-17 13:48 ` syed khader
@ 2006-05-17 14:28 ` David Woodhouse
0 siblings, 0 replies; 12+ messages in thread
From: David Woodhouse @ 2006-05-17 14:28 UTC (permalink / raw)
To: syed khader; +Cc: linux-mtd, J�rn Engel
On Wed, 2006-05-17 at 06:48 -0700, syed khader wrote:
> yeah that is an option. but till the time we move to
> 2.6 we should support 2.4 and have to resolve this
> problem.
> Probably looking into the changes would help.
> Thanks
> syed
Please stop top-posting. Read http://david.woodhou.se/email.html
and please also trim your quotations appropriately.
You seem to have a hybrid of old, relatively stable code (2.4) with
newer, 'exciting' JFFS2 -- but not even the _current_ JFFS2 code; older
code in which we _know_ we've fixed bugs since then. That isn't really
something we can support you with.
If you want the stability of 2.4, then _use_ 2.4, and deal with the fact
that its JFFS2 is slow.
If you want the improvements which are in 2.6, then just switch to it
and don't attempt to mix and match.
Mixing the 2.4 kernel with a JFFS2 snapshot from CVS is entirely
unsupportable and basically gets you the worst of both worlds.
--
dwmw2
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2006-05-17 14:28 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20060516061354.GA18958@wohnheim.fh-wedel.de>
2006-05-16 12:40 ` CRC errors when continuous fseek/fputs on JFFS2 syed khader
2006-05-16 14:26 ` Jörn Engel
2006-05-16 15:01 ` syed khader
2006-05-16 15:31 ` Jörn Engel
2006-05-17 5:12 ` syed khader
2006-05-17 6:25 ` zlib compression is failing syed khader
2006-05-17 9:10 ` Jörn Engel
2006-05-17 10:42 ` Josh Boyer
2006-05-17 11:22 ` syed khader
2006-05-17 13:19 ` Jörn Engel
2006-05-17 13:48 ` syed khader
2006-05-17 14:28 ` David Woodhouse
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox