Messages in this thread | | | Date | Sun, 18 Dec 2005 20:16:42 +0100 | From | Willy Tarreau <> | Subject | Re: RESUBMITTING [PATCH] MTD (kernel 2.4.32): kernel stuck in tight loop occasionally on flash access |
| |
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/
| |