Re: RESUBMITTING [PATCH] MTD (kernel 2.4.32): kernel stuck in tight loop occasionally on flash access

[Willy Tarreau <willy@w.ods.org>]

Hi Vijay,

On Sun, Dec 18, 2005 at 10:50:54AM -0800, Vijay Sampath wrote:
> Resubmitting patch after feedback from Grant Coady and Willy Tarreau.
> Changed description and erroneous diff output for dontdiff file.
> 
> 
> We are running a Timesys modified version of the 2.4 kernel.
> Occasionally we see board lockups on heavy file system and direct MTD
> flash accesses. I have traced this down to a bug in the 2.4 MTD code
> (chip driver to be specific) and see this problem even in the latest 2.4
> kernel (2.4.32). I realize that this problem may not be seen by others
> using the stock kernel, but I think it needs to be fixed anyway for
> correctness.
> 
> The problem is in cfi_cmdset_0001.c, and is present in drivers for other
> chips as well. In the function cfi_intelext_sync() function before
> calling schedule(), the current process needs to be put to sleep by
> calling set_current_state(TASK_UNINTERRUPTIBLE). If it is not put to
> sleep, the task remains in the run queue of the kernel and if its
> priority is high enough, the kernel will constantly keep scheduling this
> process, the state of the chip will never change.
> 
> Adding this one line seems to make our lockups go away. There were
> questions raised as to why TASK_UNINTERRUPTIBLE. The same driver uses
> TASK_UNINTERRUPTIBLE in other similar places while waiting for hardware
> to complete erasing etc. I chose the same thing.

OK, that seems reasonnable. Thanks for the explanation.
I'm queuing it for the -hf tree.

> I am not subscribed to the mailing list, so please CC me on any replies.
> 
> Signed-off-by: Vijay Sampath <vijay.sampath@aktino.com>
> 

Thanks,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/