On Sat, Jun 28, 2014 at 10:02:19PM +0530, Kiran Kankipati wrote: > I don't understand, are you having problems on the compress side, or the > decompress side? Where in the lz4 is a bug happening? > >> Sorry sorry. > I dont have a clue. Well the reason is, if compress is happening well and > decomp is getting this issue. Then decomp is having a bug. > If compression is corrupting data, then decomp may get this issue too. Hence I > am not fully sure. > But the error code happening in the decomp API. > > > Do you have a data stream that I can use to run it through the lz4 code > to see where the problem is in the compress/decompress code? > >> Again sorry about it. Since iam testing with real-time packets. I dont > >> have > it Greg. > > I can copypaste the error logs of my TrafficSqueezer per-packet tests. Since > I > am running a simulation test, I am doing each packet > compression + decompression. This way I can test TrafficSqueezer stack. As > well > in our case we can test LZ4 too. > > Kindly refer screenshot: > > But please note, sometimes it works fine too. Sometimes I am getting this > error > :( > > Its purely LZ4-HC error. Since the return code of > lz4_decompress_unknownoutputsize() API is <0 i.e error !
As you are compressing and then decompressing, this doesn't look to be the same "type" of error we have fixed recently, so I don't know what to do here. If you find a data stream that this can be tested with, please let me know and I'll be glad to try it out. Until then, I need more of a hint as to the problem before I can do anything, sorry. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
