Re: Multi-partition block layer behaviour

[Shaohua Li <shaohua.li@intel.com>]

On Mon, 2011-10-31 at 18:21 +0800, Tiju Jacob wrote:
> >> ok, thanks. So this means the elevator is switching in the test. How
> >> about below patch:
> >>
> >> diff --git a/block/elevator.c b/block/elevator.c
> >> index a3b64bc..e14824a 100644
> >> --- a/block/elevator.c
> >> +++ b/block/elevator.c
> >> @@ -683,8 +683,13 @@ void __elv_add_request(struct request_queue *q, struct request *rq, int where)
> >>                 * - Usually, back inserted requests won't be merged
> >>                 *   with anything.  There's no point in delaying queue
> >>                 *   processing.
> >> +                * If elevator is switching, doesn't need run the queue.
> >> +                * elevator switching will run it anyway. And this could
> >> +                * cause warning since the code might run in atomic
> >> +                * environment(blk_flush_plug_list() callbed in schedule())
> >>                 */
> >> -               __blk_run_queue(q);
> >> +               if (!test_bit(QUEUE_FLAG_ELVSWITCH, &q->queue_flags))
> >> +                       __blk_run_queue(q);
> >>                break;
> >>
> >>        case ELEVATOR_INSERT_SORT_MERGE:
> >>
> >>
> > oh, wait. We should have no this issue with latest kernel, because
> > blk_schedule_flush_plug is moved out of schedule atomic environment. please
> > try a latest kernel, for example, 3.1.
> >
> 
> Even after applying the above patch, I am getting the same error. We
> have to use the linux 3.0.* kernel series. So is there a fix for the
> 3.0 series?
> We'll defenetly check with the 3.1 kernel and let know.
please ignore the patch. There is a fix in upstream:
9c40cef2b799f9b5e7fa5de4
and it's marked -stable, so it will go to 3.0 stable.
if 3.1 kernel doesn't work, please report back with a log.

Thanks,
Shaohua