Hi,
I've a block device driver which does the following,
Inside the request function I do something like this:
request(fn) {
while ((req = elv_next_request(q)) != NULL) {
....................set up the request;
spin_unlock_irq(q->queue_lock);
call the transfer(set_up_req) function;
spin_lock_irq(q->queue_lock);
}
spin_unlock_irq (q->queue_lock);
/* allow callback to execute as it needs the lock!!! */
spin_lock_irq (q->queue_lock);
}
and the transfer function calls the scsi_execute_asyn(....) with the
callback function doing the end request. So, the ending of the request is
done like below:
callback(fn) {
spin_lock_irqsave(q->queue_lock, flags);
if (!end_that_request_first(set_up_req->req, cmpstatus,
set_up_req->req->nr_sectors)) {
add_disk_randomness(...);
end_that_request_last(set_up_req->req,0);
}
spin_unlock_irqrestore(q->queue_lock, flags);
}
This code works fine with most of the kernel versions, but fails on some
like , Linux 2.6.18-8.el5-xen
Please help me to find out where I'm going wrong?
Thanks in advance for an early reply.
Anil P.
--
View this message in context: http://www.nabble.com/problem-with-ending-requests-asynchronously-in-my-block-device-driver-tp14354996p14354996.html
Sent from the linux-kernel mailing list archive at Nabble.com.
On Sat, 2007-12-15 at 12:52 -0800, a_kumar wrote:
> I've a block device driver which does the following,
Why not send the actual code?
> This code works fine with most of the kernel versions, but fails on some
> like , Linux 2.6.18-8.el5-xen
You've provided no information. What we need:
*). A well formed report, complete with oops, panic, other output.
*). Description of how it "fails".
Note also that there is no upstream Linux "2.6.18-8.el5-xen" kernel.
There is a Red Hat Enterprise Linux kernel release with that revision
(this is the one that shipped in the GA RHEL5.0 kernel). You should
contact your vendor for support with their kernel if you are unable to
provide a well-formed bug report against an upstream kernel release.
Jon.