http://bugzilla.novell.com/show_bug.cgi?id=535963 Summary: nfs4 mounts block on Xen with an hour of boot Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: x86-64 OS/Version: openSUSE 11.1 Status: NEW Severity: Major Priority: P5 - None Component: Xen AssignedTo: jdouglas@novell.com ReportedBy: rbsmith@sandia.gov QAContact: qa@suse.de Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.13) Gecko/2009080200 SUSE/3.0.13-0.1.2 Firefox/3.0.13 nfs4 mounts block in dom0 on our HP Proliant DL360-G5 x86_64 servers after some period of time. This has been experienced on kernel-xen-2.6.27.21-0.1 and kernel-xen-2.6.27.25.0-1. We have not experienced it on kernel-default. Likewise, new nfs4 mount requests will block. nfs3 mounts continue to work fine. Prior to reaching this state nfs4 behaves normally. It turns out that this blocking behavior is NIC specific, nfs4 requests on a second NIC continue to work fine. The HP DL360-G5 have dual Broadcomm NICS using the bnx2 driver. One NIC serves our client machines while the other is used on a restricted administrative LAN. The behavior documented here involves 2 DL360-G5, one serving NFS out of a kernel-default-2.6.27.21-0.1 and the other mounting NFS in dom0 on kernel-xen-2.6.27.25-0.1. We've also experienced blocking behavior on the NFS server when it runs a Xen kernel. Our NFS servers listen on both interfaces. When nfs4 becomes blocked on the client's primary interface, nfs4 mount requests on the secondary NIC continue to work. So the exact same file system that is blocked on the primary NIC can be mounted on the secondary NIC and works fine. Here is the output from "echo w > /proc/sysrq-trigger" after invoking mount -t nfs4 nfsserver:/path /mnt on kernel-xen-2.6.27.25.0-1 mount.nfs4 D 0000000000000000 0 6656 6655 ffff88008ec1d848 0000000000000286 ffff88008ec1d788 ffff88008ec1d7b8 ffff88008ec1d800 ffffffff807538c0 ffffffff80757d00 ffffffff80757080 ffffffff80757d00 ffffffff80757d00 ffffffff80757d00 ffffffff80757d00 Call Trace: [<ffffffffa032d9a4>] rpc_wait_bit_killable+0x2d/0x31 [sunrpc] [<ffffffff804650ff>] __wait_on_bit+0x41/0x70 [<ffffffff80465199>] out_of_line_wait_on_bit+0x6b/0x77 [<ffffffffa032e0de>] __rpc_execute_0xdb/0x231 [sunrpc] [<ffffffffa03284fc>] rpc_run_task+0x4f/0x57 [sunrpc] [<ffffffffa03285eb>] rpc_call_sync+0x3d/0x5a [sunrpc] [<ffffffffa0395ce8>] nfs4_proc_get_root+0x96/0xe1 [nfs] [<ffffffffa0382ceb>] nfs4_path_walk+078/0x259 [nfs] [<ffffffffa037e156>] nfs4_create_server+0x92/0x20d [nfs] [<ffffffffa0387b97>] nfs4_get_sb+0xb9/0x276 [nfs] [<ffffffff802a0ad5>] vfs_kern_mount+0x95/0x11a [<ffffffff802a0bad>] do_kern_mount+0x43/0xdc [<ffffffff802b6dc7>] do_new_mount+0x5b/0x93 [<ffffffff802b7b45>] do_mount+0x1bd/0x1ea [<ffffffff802b7bfc>] sys_mount+0x8a/0xd2 [<ffffffff8020b3b8>] system_call_fastpath+0x16/0x1b [<00007feafc98588a>] 0x7feafc98588a Reproducible: Always Steps to Reproduce: 1.Boot a 2.6.27.25 xen kernel 2.mount -t nfs4 nfsserver.on.nic1:/path /mnt1 3.rsync -HAXaxs /mnt /tmp 4.Wait for several gigabytes to be transferred 5.If the rsync doesn't block, repeatedly invoke mount until it blocks: mount -t nfs4 nfsserver.on.nic1:/path2 /mnt; umount /mnt mount -t nfs4 nfsserver.on.nic2:/path1 /mnt; umount /mnt -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.