Subject : [2.6.24-rc] pdflush stuck in D state Submitter : tvrtko.ursulin@sophos.com References : http://lkml.org/lkml/2007/11/22/15
Here is a trace for good and bad pdflush processes: Nov 22 16:35:09 oxygene kernel: ======================= Nov 22 16:35:09 oxygene kernel: pdflush S c014fe4e 0 150 2 Nov 22 16:35:09 oxygene kernel: 00000000 00000046 00000000 c014fe4e f7c30fa4 c014f9c6 f7ce8560 f7ce869c Nov 22 16:35:09 oxygene kernel: c201e100 00000001 fffffffc 00000002 00000000 00000000 00000000 00000000 Nov 22 16:35:09 oxygene kernel: 00000021 f7c30fc8 c014fe4e 00000000 00000000 c014ff09 00000202 f7ce8560 Nov 22 16:35:09 oxygene kernel: Call Trace: Nov 22 16:35:09 oxygene kernel: [pdflush+0/434] pdflush+0x0/0x1b2 Nov 22 16:35:09 oxygene kernel: [background_writeout+125/173] background_writeout+0x7d/0xad Nov 22 16:35:09 oxygene kernel: [pdflush+0/434] pdflush+0x0/0x1b2 Nov 22 16:35:09 oxygene kernel: [pdflush+187/434] pdflush+0xbb/0x1b2 Nov 22 16:35:09 oxygene kernel: [kthread+56/96] kthread+0x38/0x60 Nov 22 16:35:09 oxygene kernel: [kthread+0/96] kthread+0x0/0x60 Nov 22 16:35:09 oxygene kernel: [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10 Nov 22 16:35:09 oxygene kernel: ======================= Nov 22 16:35:09 oxygene kernel: pdflush D f7c3aef4 0 151 2 Nov 22 16:35:09 oxygene kernel: 0b83b953 00000046 00000002 f7c3aef4 f7c3aeec 00000000 f7ce8ac0 f7ce8bfc Nov 22 16:35:09 oxygene kernel: c201e100 00000001 f7c3af18 0b83b9cc f7c3af18 00000003 00000000 00000001 Nov 22 16:35:09 oxygene kernel: 00000000 f7c3af18 0b83b9cc f7c3af70 00000000 c027ddb7 f781e000 c010490c Nov 22 16:35:09 oxygene kernel: Call Trace: Nov 22 16:35:09 oxygene kernel: [schedule_timeout+112/141] schedule_timeout+0x70/0x8d Nov 22 16:35:09 oxygene kernel: [apic_timer_interrupt+40/48] apic_timer_interrupt+0x28/0x30 Nov 22 16:35:09 oxygene kernel: [process_timeout+0/5] process_timeout+0x0/0x5 Nov 22 16:35:09 oxygene kernel: [schedule_timeout+107/141] schedule_timeout+0x6b/0x8d Nov 22 16:35:09 oxygene kernel: [io_schedule_timeout+27/36] io_schedule_timeout+0x1b/0x24 Nov 22 16:35:09 oxygene kernel: [congestion_wait+80/100] congestion_wait+0x50/0x64 Nov 22 16:35:09 oxygene kernel: [autoremove_wake_function+0/53] autoremove_wake_function+0x0/0x35 Nov 22 16:35:09 oxygene kernel: [pdflush+0/434] pdflush+0x0/0x1b2 Nov 22 16:35:09 oxygene kernel: [wb_kupdate+152/219] wb_kupdate+0x98/0xdb Nov 22 16:35:09 oxygene kernel: [pdflush+282/434] pdflush+0x11a/0x1b2 Nov 22 16:35:09 oxygene kernel: [wb_kupdate+0/219] wb_kupdate+0x0/0xdb Nov 22 16:35:09 oxygene kernel: [kthread+56/96] kthread+0x38/0x60 Nov 22 16:35:09 oxygene kernel: [kthread+0/96] kthread+0x0/0x60 Nov 22 16:35:09 oxygene kernel: [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10 Nov 22 16:35:09 oxygene kernel: =======================
The same happens here on my laptop: pdflush D c10458e0 0 18280 2 00000000 00000046 c138a080 c10458e0 c156e4a0 c11b3e20 c0494eb0 c0497940 f7403000 f7403140 c17fb940 00000000 d89d3f14 0040ca85 d89d3f14 00000202 c012afd7 00000000 00000202 d89d3f14 0040ca85 d89d3f6c 00000000 c0353878 Call Trace: [<c012afd7>] __mod_timer+0x9d/0xa7 [<c0353878>] schedule_timeout+0x70/0x8d [<c010672c>] do_IRQ+0x5c/0x70 [<c012abea>] process_timeout+0x0/0x5 [<c0353873>] schedule_timeout+0x6b/0x8d [<c0353739>] io_schedule_timeout+0x1b/0x24 [<c01542d3>] congestion_wait+0x51/0x65 [<c0133a74>] autoremove_wake_function+0x0/0x33 [<c015027c>] pdflush+0x0/0x1ac [<c014fee0>] wb_kupdate+0x99/0xde [<c015027c>] pdflush+0x0/0x1ac [<c015038f>] pdflush+0x113/0x1ac [<c014fe47>] wb_kupdate+0x0/0xde [<c01339a5>] kthread+0x38/0x5f [<c013396d>] kthread+0x0/0x5f [<c0104b97>] kernel_thread_helper+0x7/0x10 2.6.24-rc3, but with prior rcs, too. I can make it happen quite easy by calling some svn update of big repositories.
Manually calling sync from command line will put pdflush back into S state, but after a while it will switch to D again. My kernel: 2.6.24-rc2 My CPU: Intel Core 2 Duo (only one pdflush is stuck) My disk: SATA -> LVM PV -> LVM VG -> LVM LV -> DM-crypt -> root partition -> LVM LV -> DM-crypt -> swap partition
It looks like this is the same issue as in Bug #9291. *** This bug has been marked as a duplicate of bug 9291 ***