Description of problem: It seems that something in recent updates (glibc-2.3.3-53 installed today?) made much easier to trigger Badness in interruptible_sleep_on_timeout at kernel/sched.c:3004 This is not precisely new but apparently this was something rare in the past. It seems that accessing automounted NFS file systems, which are long unmounted at times this happens, helps to cause that. I always observed that on shutdown only. Here is a sample (a fragment of logs): mDNSResponder: mDNSResponder shutdown succeeded kernel: Badness in interruptible_sleep_on_timeout at kernel/sched.c:3004 kernel: kernel: Call Trace:<ffffffff803468e0>{interruptible_sleep_on_timeout+117} kernel: <ffffffff80132730>{default_wake_function+0} <ffffffff80144677>{kill_proc_info+38} kernel: <ffffffffa02552ed>{:lockd:lockd_down+199} <ffffffffa026d68e>{:nfs:nfs_kill_super+77} kernel: <ffffffff8018c584>{deactivate_super+220} <ffffffff801add0f>{sys_umount+2362} kernel: <ffffffff801a29d7>{dput+55} <ffffffff801866a6>{__fput+234} kernel: <ffffffff80184b97>{filp_close+103} <ffffffff80110782>{system_call+126} kernel: autofs: automount shutdown succeeded and another one from x86; this time with 2.6.8-1.541smp kernel. mDNSResponder: mDNSResponder shutdown succeeded kernel: Badness in interruptible_sleep_on_timeout at kernel/sched.c:3004 kernel: [<022d94ed>] interruptible_sleep_on_timeout+0x5d/0x154 kernel: [<0211e893>] default_wake_function+0x0/0xc kernel: [<22a9245f>] rpc_destroy_client+0x9e/0xa4 [sunrpc] kernel: [<22a852f4>] lockd_down+0xb9/0x164 [lockd] kernel: [<2343eda8>] nfs_kill_super+0x43/0x63 [nfs] kernel: [<0216252c>] deactivate_super+0x80/0x95 kernel: [<0217978e>] sys_umount+0x65/0x6c kernel: [<0217301a>] dput+0x36/0x2a4 kernel: [<0215d7f8>] __fput+0xda/0x100 kernel: [<0215c28c>] filp_close+0x59/0x5f kernel: [<0215c332>] sys_close+0xa0/0xd3 kernel: [<021797a0>] sys_oldumount+0xb/0xe autofs: automount shutdown succeeded Version-Release number of selected component (if applicable): kernel-2.6.8-1.541 How reproducible: Hard to say. Seems to increasing in frequncy.
*** This bug has been marked as a duplicate of 127018 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.