在550天的令人印象深刻的正常运行时间没有麻烦之后，我从一个FreeNAS-box上挂载了一个nfs-share几天后，我们的四路opteron系统变成了一个损坏的系统。
正在进行的会话保持活动，但新的login失败，因为既没有获得一个shell或chroot的工作（鉴别工作，正如我在/ var / log / secure中看到的那样 – 把login过程在之后简化了）。
/ var / log / messages指向安装写入进程的写入写入过程：
BUG: soft lockup - CPU#38 stuck for 61s! [maq:27850] Modules linked in: nfs lockd fscache nfs_acl auth_rpcgss sunrpc sit tunnel4 tun fuse autofs4 cpu freq_ondemand powernow_k8 freq_table ipt_REJECT nf_conntrack_ipv4 nf_defra g_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log sg amd64_edac_mod edac_core edac_mce_amd i2c_piix4 i2c_core igb dca ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom 3w_sas ata_generic pata_acpi pata_atiixp ahci qla2xxx scsi_transport_fc scsi_tgt dm_mod [last unloaded: scsi_wait_scan] CPU 38: Modules linked in: nfs lockd fscache nfs_acl auth_rpcgss sunrpc sit tunnel4 tun fuse autofs4 cpufreq_ondemand powernow_k8 freq_table ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log sg amd64_edac_mod edac_core edac_mce_amd i2c_piix4 i2c_core igb dca ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom 3w_sas ata_generic pata_acpi pata_atiixp ahci qla2xxx scsi_transport_fc scsi_tgt dm_mod [last unloaded: scsi_wait_scan] Pid: 27850, comm: maq Not tainted 2.6.32-71.29.1.el6.x86_64 #1 H8QG6 RIP: 0010:[<ffffffff814cbab7>] [<ffffffff814cbab7>] _spin_unlock_irqrestore+0x17/0x20 RSP: 0018:ffff886c12ddd8f8 EFLAGS: 00000202 RAX: 0000000000000202 RBX: ffff886c12ddd8f8 RCX: 000000000000f14b RDX: ffff886060611448 RSI: 0000000000000202 RDI: 0000000000000202 RBP: ffffffff81013c8e R08: ffff886060611450 R09: 94adb435c189d607 R10: 0000000000000000 R11: 0000000000000001 R12: ffff881027c2d200 R13: 0000000000000026 R14: ffff88015521a8c0 R15: ffff8835e94e3200 FS: 00007f8aa27be720(0000) GS:ffff886060880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007ff69c45a000 CR3: 0000003289c86000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: [<ffffffff810920ae>] ? prepare_to_wait_exclusive+0x4e/0x80 [<ffffffff814ca168>] ? __wait_on_bit_lock+0x48/0xc0 [<ffffffff81091dd7>] ? bit_waitqueue+0x87/0xd0 [<ffffffffa0338560>] ? nfs_wait_bit_killable+0x0/0x40 [nfs] [<ffffffff814ca258>] ? out_of_line_wait_on_bit_lock+0x78/0x90 [<ffffffff81091ee0>] ? wake_bit_function+0x0/0x50 [<ffffffffa0345c9a>] ? nfs_commit_inode+0xaa/0x1c0 [nfs] [<ffffffffa0345e29>] ? nfs_wb_page+0x79/0xd0 [nfs] [<ffffffffa0344170>] ? nfs_page_find_request+0x50/0x70 [nfs] [<ffffffffa0345ec0>] ? nfs_flush_incompatible+0x40/0x70 [nfs] [<ffffffffa0334aa3>] ? nfs_write_begin+0x93/0x220 [nfs] [<ffffffff8110cbce>] ? generic_file_buffered_write+0x10e/0x2a0 [<ffffffff8110e520>] ? __generic_file_aio_write+0x250/0x480 [<ffffffff8110e7bf>] ? generic_file_aio_write+0x6f/0xe0 [<ffffffffa033571a>] ? nfs_file_write+0xda/0x1e0 [nfs] [<ffffffff8116d05a>] ? do_sync_write+0xfa/0x140 [<ffffffff81091ea0>] ? autoremove_wake_function+0x0/0x40 [<ffffffff8120caab>] ? selinux_file_permission+0xfb/0x150 [<ffffffff811fff16>] ? security_file_permission+0x16/0x20 [<ffffffff8116d358>] ? vfs_write+0xb8/0x1a0 [<ffffffff8116dd91>] ? sys_write+0x51/0x90 我试图杀死（-9）引发错误（'maq'）的进程，但是进程正在进行，并且不能被杀死（通过nfs挂载的文件系统也是如此）。 重新启动本地计算机上的所有服务以及freenas服务器上的nfs服务都无济于事。 在一个或多或less不稳定的系统上工作了两个小时之后，我不得不重新启动系统（没有任何挂起的情况下工作）。
当我检查日志文件时，我看到yum的自动更新function已启用，并且selinux-policy的内容已更新。 这可能导致login问题？
如果（短？）写延迟（可以通过使用'mount -o soft'来阻止新的软locking），那么nfs可以导致一个或多或less的完全阻塞系统？ 或者这可能是一个内核错误？
uname -r 2.6.32-71.29.1.el6.x86_64 cat /etc/issue Scientific Linux release 6.0 (Carbon)
升级你的操作系统
（例如，像这样debugging旧内核的错误是没有意义的）
这适用于CentOS，RHEL，Scientific Linux等.EL6.0充满了问题/错误，几乎不能用于我的目的。 EL6.1稍微好一些，但是我的系统在EL6.2和6.3的水平上确实稳定了。
您可能遇到上游RHEL勘误内核中修复的问题。