On Mon, Dec 29, 2008 at 8:35 PM, John McCabe-Dansted <[email protected]> wrote: > On Sun, Dec 28, 2008 at 10:36 PM, John McCabe-Dansted <[email protected]> > wrote: >> FYI, I have attached another patch. This fixes the above error, but >> there is still another bug. AFAICT now all page reads report that >> decompression failed. I do not know what causes this bug, and this >> patch is still filled with extra pr_info("Debug ...") lines to help >> my try to track this down. I'll look into this as time permits. > > OK, fixed this. This patch still doesn't attempt to support 64bit and > leads to crashes even on 32bit... I don't know if this is a new bug in > my code or yours, I remember your original code being crashy as well, > but I blamed this on the swap write errors. > > If I swapon, it may crash on heavy load, and also > > # tar -c / > /dev/ramzswap0 > tar: Removing leading `/' from member names > tar: Removing leading `/' from hard link targets > <then it just hangs> > > #tar -c / | gzip > /dev/ramzswap0 > OTOH seems stable, as does > sudo dd if=/dev/zero of=/dev/ramzswap0 > > > Also, why do we initialize the swap in the module? Why don't we just > run mkswap /dev/ramzswap0? >
Any write to /dev/ramzswap0 from userspace will lead to crash. Writing compression blk device that supports arbitrary R/W is harder to write and is useless for our purpose. We just need to handle swap requests the way we do currently. I also don't understand how you are getting these crashes on 32/64-bit. Try latest SVN - it should run just fine (it now also handles case for uncompressible pages). Nitin _______________________________________________ linux-mm-cc mailing list [email protected] http://lists.laptop.org/listinfo/linux-mm-cc
