Created attachment 517422 [details]
The crash log, sent via syslog to the client machine

Description of problem:
After upgrading to 2.6.40-4.fc15.x86_64 I started experiencing crashes on my home server (named mimmi).  After some investigation, I believe it is triggered by activity on a system which is an NFS client (named freddi) of this server.  It doesn't happen with just any activity, but e.g. logging in in a new session seems to trigger the problem reliably.

The kernel writes a message staring with "kernel BUG at fs/jbd2/transaction.c" when this happens.  By setting up remote syslog:ging to the client, I could capture the dump and attach it to this report.  Shortly after this message from the server, the client starts to complain with the traditional "nfs: server mimmi not responding, still trying" in the log.

Version-Release number of selected component (if applicable):
kernel-2.6.40-4.fc15.x86_64
nfs-utils-1.2.4-1.fc15.x86_64

Additional info:
The machine isn't completely dead after the crash.  If I was logged in to a virtual console before, I can run some commands.  And it is possible to switch between different virtual consoles, unless I go to one where there is an X session.  After that I'm stuck.  And trying to log in to a new virtual console also hangs.

I SUSPECT it is when I try to run something which uses file locking the crash happens.  Starting firefox or emacs' movemail on the client seems to trigger it, for example.  But I don't know of any command that ONLY does locking, so it this is just a suspicion.  (I could of course write a simple little program that does that, if it would help you.)

The client mounts the NFS file systems using the vers=3 option.  This is a workaround for a different issue.  (For some reason one user id, my own, gets mapped to nfsnobody when using NFSv4.  It affects no other users.  I will investigate that further when I get a chance.  For the mean time, I'm using NFSv3 as a workaround.)

Booting the server with an earlier kernel, 2.6.38.8-32.fc15.x86_64, doesn't trigger the problem.  So I do have a short-time workaround.