From: Nick Piggin <piggin@cyberone.com.au>
To: Amit Patel <patelamitv@yahoo.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org,
James Bottomley <James.Bottomley@steeleye.com>,
Alexander Viro <viro@math.psu.edu>
Subject: Re: as_arq scheduler alloc with 2.6.0-test8-mm1
Date: Wed, 29 Oct 2003 15:48:38 +1100 [thread overview]
Message-ID: <3F9F46A6.3090901@cyberone.com.au> (raw)
In-Reply-To: <20031029043423.41171.qmail@web13004.mail.yahoo.com>
Amit Patel wrote:
>--- Nick Piggin <piggin@cyberone.com.au> wrote:
>
>>No, you're on the right track. Actually, in the
>>block device
>>you will allocate the queue, and the queue will then
>>allocate
>>the elevator. First see if the queue is being
>>properly allocated
>>and freed. If it is not, then the problem is in the
>>SCSI layer.
>>
>>
>>
>
>Hi Nick,
>
>During scsi_scan.c:scsi_probe_and_add_lun it allocates
>scsi device and request_queue to send the
>scsi_request. If during this scan it finds no device
>attached to target it will deallocate request__queue.
>But since there was no disk found it never called
>add_disk and so it never go through blk_register_queue
>function to register elevator queue. So during clean
>up it just calles blk_cleanup_queue which does _not_
>clean up elevator_data.
>
>This is just what I think is happening by looking at
>the code. I might be missing something. But in this
>case either blk_cleanup_queue should clean elevator
>also as part of cleanup instead of it getting cleaned
>up through blk_unregister_queue or scsi layer needs
>to make some changes during scan. I do not know what
>implication it might have if cleanup is done as part
>of blk_cleanup_queue on other kind of block devices. I
>will try to put this cleanup as part of
>blk_cleanup_queue to see if it works.
>
Yeah that sounds right. This is due to elv-select.patch. Its
quite a rats nest in there though :(
What should be happening is blk_alloc_queue should register
the queue kobject, and blk_init_queue should allocate the
the elevator kobject (which should be registered in the process).
add_disk should just be taking a reference on the queue, and
add a symlink in sysfs to the real queue (I think). I have a
patch to do this, but it is a bit ugly because I don't know
where in sysfs to put the queue object.
Anyway, if this isn't going to be done before 2.6.0, I guess
Andrew you should drop by elv-select patches for now. That
doesn't fix anything, but it hides some of the problems.
next prev parent reply other threads:[~2003-10-29 4:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3F9F2928.7030704@cyberone.com.au>
2003-10-29 4:34 ` as_arq scheduler alloc with 2.6.0-test8-mm1 Amit Patel
2003-10-29 4:48 ` Nick Piggin [this message]
2003-10-26 9:54 Mr Amit Patel
2003-10-26 11:41 ` Andrew Morton
2003-10-26 18:03 ` Mr Amit Patel
2003-10-27 17:59 ` Mr Amit Patel
2003-10-27 21:38 ` Andrew Morton
2003-10-27 23:36 ` Nick Piggin
2003-10-29 1:45 ` Amit Patel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F9F46A6.3090901@cyberone.com.au \
--to=piggin@cyberone.com.au \
--cc=James.Bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patelamitv@yahoo.com \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.