* 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