On Thu, Sep 23, 2004 at 01:19:02PM -0400, Shailabh Nagar wrote:
> Shailabh Nagar wrote:
> >Marc E. Fiuczynski wrote:
> >
> >>Hi Shailabh,
> >>
> >>In my Fedora Core 2 (1.521) based 2.6.8 kernel I am seeing the "sleeping
> >>function called from invalid context" problem that I reported before.
> >>Below
> >>is the calltrace. As you can see, it appears to be coming from the
> >>call to
> >>mempool_alloc in your version of cfq_get_queue. Maybe it is necessary to
> >>specify a different GFP value in my FC2 kernel?! I suppose this is on my
> >>plate to fix, as you do not see this in your vanilla 2.6.8.1 kernel,
> >>right?
> >
> >
> >No, I don't.
> >
> >This cfq-iosched.c appears to be buggy. In vanilla 2.6.8.1, the
> >cfq-iosched.c has the following change to the mempool code:
> >
> >if (gfp_mask & __GFP_WAIT) {
> > spin_unlock_irq(q->queue_lock);
> > new_cfqq = mempool_alloc(cfq_mpool, gfp_mask);
> > spin_lock_irq(q->queue_lock);
> > goto retry;
> >
> >So we'd need to do something similar (unlock the request queue before
> >allocating). Problem is that we don't have easy access to the request
> >queue in our version....let me rustle up a patch which should fix that.
> >
> >Perhaps I should just bite the bullet and separate the "io priority
> >addition" parts of our cfq-iosched.c out. That'll help us take advantage
> >of other bug fixes. Let me see - I'll put out a hack first.
>
> Please try the attached patch. It boots fine for me.
>
> -- Shailabh
> >
> >-- Shailabh
> >
> diff -Nru a/drivers/block/cfq-iosched.c b/drivers/block/cfq-iosched.c
> --- a/drivers/block/cfq-iosched.c Thu Sep 23 13:17:57 2004
> +++ b/drivers/block/cfq-iosched.c Thu Sep 23 13:17:57 2004
> @@ -131,6 +131,8 @@
> struct hlist_head *crq_hash;
> mempool_t *crq_pool;
>
> + request_queue_t *queue;
> +
> struct io_prio_data cid[IOPRIO_NR];
>
> /*
> @@ -719,7 +721,9 @@
> struct cfq_queue *cfqq = __cfq_find_cfq_hash(cfqd, hashkey, hashval);
>
> if (!cfqq) {
> + spin_unlock_irq(cfqd->queue->queue_lock);
> cfqq = mempool_alloc(cfq_mpool, GFP_NOIO);
> + spin_lock_irq(cfqd->queue->queue_lock);
hmm, any reason to get the lock here and not
later on, when you initialized the cfqq?
> memset(cfqq, 0, sizeof(*cfqq));
> INIT_HLIST_NODE(&cfqq->cfq_hash);
> @@ -1049,6 +1053,7 @@
>
> cfqd->dispatch = &q->queue_head;
> e->elevator_data = cfqd;
> + cfqd->queue = q;
>
> return 0;
> out_crqpool:
best,
Herbert
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
