Created attachment 268 [details] Patched glxMesa Spec for the new CVS sources
Created attachment 269 [details] lvs.cf file
This is seen on qa3.
When exporting a simple posix volume through NFS, on doing a showount -e localhost on the NFS client/nfs server, glusterfsd goes into a cpu usage loop on a spinlock hanging the whole process. The lock hung on is in: gf_mem_set_acct_info
Downgrading to Normal because the work-around is to disable memory-accounting by: export GLUSTERFS_DISABLE_MEM_ACCT=1 And then running glusterfsd.
This probably caused by a bug in the memory accounting init phase in NFS translator.
The bug occurs because before entering the NFS translator, the nfs-rpc layer does not set THIS, leaving it pointing to some other translator. The locking code sees some crap lock structure because the memory type to be indexed is crap because the translator which gets accessed while allocating memory in mount3.c, for mnt3-export, is not NFS but something else.
PATCH: http://patches.gluster.com/patch/4426 in master (nfsrpc: Introduce THIS-setting support to fix mem-accounting)
PATCH: http://patches.gluster.com/patch/4423 in master (nfs: Set actorxl to enable setting THIS to nfsx)
Regression test: 1. Export a simple posix volume through gnfs. 2. Start the nfs server. 3. At the nfs client: $ showmount -e <server> This will hang the nfs server in the mnt3-export code path. Verify this through log. Next step. 4. Kill the nfs server daemon. 5. Run the following command: export GLUSTERFS_DISABLE_MEM_ACCT=1 6. Start gnfs again. 7. Run the following command on the client: $ showmount -e <server> This time, the nfs server daemon will not hang. showmount will report the output correctly. If with the patches here, step 3 still hangs, there is a regression.