On Tue, Oct 30, 2007 at 03:54:03PM +0800, Fengguang Wu wrote: > 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] [<ffffffff8023b1b2>] __mod_timer+0xb8/0xca > > [ 3687.824492] [<ffffffff8055c87a>] schedule_timeout+0x8d/0xb4 > > [ 3687.824496] [<ffffffff8023ad6c>] process_timeout+0x0/0xb > > [ 3687.824499] [<ffffffff8055c79a>] io_schedule_timeout+0x28/0x33 > > [ 3687.824503] [<ffffffff8026bb24>] congestion_wait+0x6b/0x87 > > [ 3687.824506] [<ffffffff80245983>] autoremove_wake_function+0x0/0x38 > > [ 3687.824510] [<ffffffff8029e684>] writeback_inodes+0xcd/0xd5 > > [ 3687.824514] [<ffffffff80266dc4>] wb_kupdate+0xbb/0x10d > > [ 3687.824518] [<ffffffff80267165>] pdflush+0x0/0x1c3 > > [ 3687.824520] [<ffffffff8026727d>] pdflush+0x118/0x1c3 > > [ 3687.824523] [<ffffffff80266d09>] wb_kupdate+0x0/0x10d > > [ 3687.824527] [<ffffffff80245876>] kthread+0x49/0x77 > > [ 3687.824530] [<ffffffff8020c598>] child_rip+0xa/0x12 > > [ 3687.824535] [<ffffffff8024582d>] kthread+0x0/0x77 > > [ 3687.824538] [<ffffffff8020c58e>] 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. I have updated to v2.6.24-rc1-334-g82798a1. After using my computer for two hours, I left the computer idle overnight. This morning, pdflushd is again consuming 25% of a CPU. I will try Fengguang's patches today. florin -- Bruce Schneier expects the Spanish Inquisition. http://geekz.co.uk/schneierfacts/fact/163
Attachment:
signature.asc
Description: Digital signature
- Follow-Ups:
- Re: pdflush stuck in D state with v2.6.24-rc1-192-gef49c32
- From: Fengguang Wu <[email protected]>
- Re: pdflush stuck in D state with v2.6.24-rc1-192-gef49c32
- References:
- pdflush stuck in D state with v2.6.24-rc1-192-gef49c32
- From: Florin Iucha <[email protected]>
- pdflush stuck in D state with v2.6.24-rc1-192-gef49c32
- Prev by Date: Re: [PATCH] Only show RESOURCES_64BIT on relevant architectures
- Next by Date: Re: [PATCH] Clean up scatterlist.h and introduce macros for readability.
- Previous by thread: Re: pdflush stuck in D state with v2.6.24-rc1-192-gef49c32
- Next by thread: Re: pdflush stuck in D state with v2.6.24-rc1-192-gef49c32
- Index(es):