Neil Brown wrote:

On Sunday November 4, jpiszcz@lucidpixels.com wrote:

quoted

# ps auxww | grep D
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       273  0.0  0.0      0     0 ?        D    Oct21  14:40 [pdflush]
root       274  0.0  0.0      0     0 ?        D    Oct21  13:00 [pdflush]

After several days/weeks, this is the second time this has happened, while 
doing regular file I/O (decompressing a file), everything on the device 
went into D-state.

At a guess (I haven't looked closely) I'd say it is the bug that was
meant to be fixed by

commit 4ae3f847e49e3787eca91bced31f8fd328d50496

except that patch applied badly and needed to be fixed with
the following patch (not in git yet).
These have been sent to stable@ and should be in the queue for 2.6.23.2

	My linux-2.6.23/drivers/md/raid5.c contains your patch for a long time :

...
         spin_lock(&sh->lock);
         clear_bit(STRIPE_HANDLE, &sh->state);
         clear_bit(STRIPE_DELAYED, &sh->state);

         s.syncing = test_bit(STRIPE_SYNCING, &sh->state);
         s.expanding = test_bit(STRIPE_EXPAND_SOURCE, &sh->state);
         s.expanded = test_bit(STRIPE_EXPAND_READY, &sh->state);
         /* Now to look around and see what can be done */

         /* clean-up completed biofill operations */
         if (test_bit(STRIPE_OP_BIOFILL, &sh->ops.complete)) {
                 clear_bit(STRIPE_OP_BIOFILL, &sh->ops.pending);
                 clear_bit(STRIPE_OP_BIOFILL, &sh->ops.ack);
                 clear_bit(STRIPE_OP_BIOFILL, &sh->ops.complete);
         }

         rcu_read_lock();
         for (i=disks; i--; ) {
                 mdk_rdev_t *rdev;
                 struct r5dev *dev = &sh->dev[i];
...

but it doesn't fix this bug.

	Regards,

	JKB