A compiled Matlab process has been observed stuck in the D-state trying to run sync_page,
[root@ldas-pcdev1 ~]# cat /proc/15478/wchan sync_page This is on an SL6.1 system running, [root@ldas-pcdev1 ~]# uname -a Linux ldas-pcdev1 2.6.32-220.7.1.el6.x86_64 #1 SMP Tue Mar 6 15:45:33 CST 2012 x86_64 x86_64 x86_64 GNU/Linux At this point the process is un-killable, though there are no problems accessing any of the 150 files currently open by the processes (all mounted over NFS using v3). This has happened a few times with different 2.6.32 kernels from SL6.1 over the last few months and requires a reboot to clear the process table. It also seems to be very similar to the following RHEL report and any help in fixing this problem would be appreciated, https://access.redhat.com/knowledge/solutions/60557 Here is the process stack trace for my most recent hung process, [root@ldas-pcdev1 ~]# cat /proc/15478/stack [<ffffffff81110afd>] sync_page+0x3d/0x50 [<ffffffff81110a97>] __lock_page+0x67/0x70 [<ffffffff81128a4c>] truncate_inode_pages_range+0x44c/0x460 [<ffffffff81128a75>] truncate_inode_pages+0x15/0x20 [<ffffffff8119169e>] generic_delete_inode+0x18e/0x1d0 [<ffffffff81191745>] generic_drop_inode+0x65/0x80 [<ffffffff811905c2>] iput+0x62/0x70 [<ffffffffa03be1ce>] nfs_dentry_iput+0x3e/0x60 [nfs] [<ffffffff8118d10c>] dentry_iput+0x7c/0x100 [<ffffffff8118d281>] d_kill+0x31/0x60 [<ffffffff8118ecac>] dput+0x7c/0x150 [<ffffffff811836fa>] path_put+0x1a/0x40 [<ffffffffa03c5552>] __put_nfs_open_context+0xc2/0xf0 [nfs] [<ffffffffa03c5630>] put_nfs_open_context+0x10/0x20 [nfs] [<ffffffffa03cebfc>] nfs_clear_request+0x5c/0x80 [nfs] [<ffffffffa03cec3a>] nfs_free_request+0x1a/0x30 [nfs] [<ffffffff8126e257>] kref_put+0x37/0x70 [<ffffffffa03ceb99>] nfs_release_request+0x19/0x20 [nfs] [<ffffffffa03d32d3>] nfs_find_and_lock_request+0xb3/0xd0 [nfs] [<ffffffffa03d33a1>] nfs_migrate_page+0x41/0xf0 [nfs] [<ffffffff81163e1a>] move_to_new_page+0xaa/0x1a0 [<ffffffff8116434f>] migrate_pages+0x43f/0x4b0 [<ffffffff81159e84>] compact_zone+0x4f4/0x770 [<ffffffff8115a3a1>] compact_zone_order+0xa1/0xe0 [<ffffffff8115a4fc>] try_to_compact_pages+0x11c/0x190 [<ffffffff81123d35>] __alloc_pages_nodemask+0x5f5/0x940 [<ffffffff81158c2a>] alloc_pages_vma+0x9a/0x150 [<ffffffff81171b65>] do_huge_pmd_anonymous_page+0x145/0x370 [<ffffffff8113c4da>] handle_mm_fault+0x25a/0x2b0 [<ffffffff81042b79>] __do_page_fault+0x139/0x480 [<ffffffff814f253e>] do_page_fault+0x3e/0xa0 [<ffffffff814ef8f5>] page_fault+0x25/0x30 [<ffffffffffffffff>] 0xffffffffffffffff This is running on a 32-core Opteron Sun Fire X4600 M2 system with 128GByte of memory, and the NFS files being accessed where mounted with, [root@ldas-pcdev1 ~]# mount | grep omega thumper1:/home/omega on /mnt/zfs1/omega type nfs (rw,noacl,timeo=150,retrans=5,vers=3,sloppy,addr=10.14.0.22)
