On Sat, Sep 08, 2007 at 01:20:17PM -0700, Stefan Farestam wrote: > [drm] writeback test succeeded in 2 usecs > BUG: unable to handle kernel NULL pointer dereference at virtual address > 00000000 > printing eip: > 00000000 > *pde = 00000000 > Oops: 0000 [#1] ... > EIP: 0060:[<00000000>] Tainted: P VLI
You have a proprietary kernel module loaded (some Cisco IPSEC thing). This may or may not have much to do with the problem you are experiencing in your filesystem, but, in general, you will not get much attention from the upstream folks (or most distro's) unless you are running an untainted kernel. > EIP is at _stext+0x3feff000/0x14 ... > Call Trace: > [<c013bf4c>] read_cache_page+0x83/0x120 > [<f9b68bd7>] ecryptfs_do_readpage+0x36/0xce [ecryptfs] ... > Code: Bad EIP value. > EIP: [<00000000>] _stext+0x3feff000/0x14 SS:ESP 0068:f50ffdfc I know that there are others out there running eCryptfs over their home directories without any problems (or, at least, none that have bothered to tell me if there was a problem). Try kernel version 2.6.22.6 from kernel.org, and do not load any proprietary kernel modules. If you are still seeing this problem, give the newest experimental version of eCryptfs (well, keep in mind that even the upstream kernel module is still tagged ``EXPERIMENTAL'') that I just released yesterday a try on your 2.6.21 kernel: http://downloads.sourceforge.net/ecryptfs/ecryptfs-20070907.tar.bz2 I completely overhauled the I/O routines with the lower filesystem, and this particular problem may simply go away for you. For instance, the function ``ecryptfs_do_readpage'' does not even exist any more in my new code base. The good thing about this is that the code to handle I/O with the lower files is much less complex, and eCryptfs should no longer blow up on the upcoming release of NFS (which doesn't implement prepare_write() and commit_write() any more). Given the magnitude of this change, I would bet that some other exotic problem will pop up when you try to run it on your home directory, but if you have the time and energy to try it out, I am curious to know how it works for you. If you are even more adventurous, try to narrow down exactly which application is causing the oops. In the meantime, I will go ahead and install a copy of Feisty to see if I can reproduce any of the bugs that you have experienced. It looks like Trevor was able to reproduce the Apache bug, so it should be interesting to see how Apache is managing to get to the lower file address space. Thanks, Mike
pgpLlJSVrFzeF.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ eCryptfs-users mailing list eCryptfs-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecryptfs-users
