On Sun, Oct 28, 2007 at 10:24:29AM -0500, Florin Iucha wrote: [...] > [ 3687.824468] > [ 3687.824470] pdflush D ffffffff805787c0 0 248 2 > [ 3687.824473] ffff810006001d90 0000000000000046 0000000000000000 0000000000000286 > [ 3687.824476] ffff8100057fc770 ffff810003062000 ffff8100057fc978 0000000106001da0 > [ 3687.824480] 0000000000000003 ffffffff8023b1b2 0000000000000000 0000000000000000 > [ 3687.824483] Call Trace: > [ 3687.824488] [] __mod_timer+0xb8/0xca > [ 3687.824492] [] schedule_timeout+0x8d/0xb4 > [ 3687.824496] [] process_timeout+0x0/0xb > [ 3687.824499] [] io_schedule_timeout+0x28/0x33 > [ 3687.824503] [] congestion_wait+0x6b/0x87 > [ 3687.824506] [] autoremove_wake_function+0x0/0x38 > [ 3687.824510] [] writeback_inodes+0xcd/0xd5 > [ 3687.824514] [] wb_kupdate+0xbb/0x10d > [ 3687.824518] [] pdflush+0x0/0x1c3 > [ 3687.824520] [] pdflush+0x118/0x1c3 > [ 3687.824523] [] wb_kupdate+0x0/0x10d > [ 3687.824527] [] kthread+0x49/0x77 > [ 3687.824530] [] child_rip+0xa/0x12 > [ 3687.824535] [] kthread+0x0/0x77 > [ 3687.824538] [] child_rip+0x0/0x12 > [ 3687.824540] > > What could cause this? I use NFS4 to automount the home directories > from a Solaris10 server, and this box found a few bugs in the NFS4 > code (fixed in the 2.6.22 kernel). > > I'll try running with 2.6.23 again for a few days, to see if I get the > pdflush stuck. Any other ideas? It could be triggered by the more aggressive writeback behavior - the new code will keep on retrying as long as there are dirty inodes pending. Florin, would you try the attached patches against 2.6.24-git? They may generate big traffic of printk messages, but will help debug the problem. Thank you, Fengguang