From jens.axboe@oracle.com Mon Feb 5 04:54:22 2007 Date: Mon, 5 Feb 2007 13:56:43 +0100 From: Jens Axboe To: Christoph Lameter Cc: Andrew Morton , David Chinner , linux-kernel@vger.kernel.org Subject: Re: 2.6.20-rc6-mm3 On Mon, Feb 05 2007, Jens Axboe wrote: > On Mon, Feb 05 2007, Jens Axboe wrote: > > On Thu, Feb 01 2007, Christoph Lameter wrote: > > > On Thu, 1 Feb 2007, Jens Axboe wrote: > > > > > > > That looks like barriers, could you try with those disabled? Sorry for > > > > making you go through this, I can't debug and fix it myself before > > > > monday. > > > > > > Disabling barriers + your patch works. Modified /etc/fstab and added a > > > nobarrier option to the root filesystem. If I take your patch out then the > > > systems hangs again. > > > > I can't reproduce this. Can you see if this debug patch catches > > anything? You need to enable barriers again. > > Nevermind, that was too aggressive. I'll come up with a better debug > patch. Alright, try this one. It should show whether this is a missing unplug or not (which I think it is, hence the stall in qrcu sync). A process may legitimately block with plugged requests, that sometimes happens for bio/rq allocation etc. In that case we do want to unplug anyway though, as I don't think we should hold requests plugged even for a merge if we are going to block. And the below means we can move this out of io_schedule() and eliminate the io_schedule() requirement that I'm not too fond of, as I don't want to reintroduce all the problems we had with missing unplugs in the 2.4 kernels. But for now this is just a debug test, can you see if xfs with barriers for that kernel now works as expected? Index: current/kernel/sched.c =================================================================== --- current.orig/kernel/sched.c 2007-02-01 09:57:50.000000000 -0800 +++ current/kernel/sched.c 2007-02-05 09:46:49.000000000 -0800 @@ -3463,6 +3463,8 @@ asmlinkage void __sched schedule(void) print_irqtrace_events(current); dump_stack(); } + if (unlikely(current->io_context && current->io_context->plugged)) + blk_replug_current_nested(); profile_hit(SCHED_PROFILING, __builtin_return_address(0)); need_resched: