Has anyone out there tried to use linux-2.5.2-pre11/drivers/loop.c?
In my hacked version of loop.c, do_bio_blockbacked is often
called with a bio that has bio->bi_idx set to 1 rather than 0
(and with bi->bi_vcnt == 1), so it thinks it has no transfers to do.
When I add the kludge of doing "bio->bi_idx = 0;" at the beginning
of the routine, then it works fine.
It is possible that my problem is self-inflicted because I
am using a version that I have adopted the "initial value" patch to,
and I also added a temporary hack to force the requests to be processed
one sector at a time, like so:
blk_queue_max_segment_size(BLK_DEFAULT_QUEUE(MAJOR_NR), 512);
However, I think my changes are probably not the cause. Anyhow,
I thought I should mention this now to see if anyone else can
confirm or refute having similar problems.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
On Sat, Jan 12 2002, Adam J. Richter wrote:
> Has anyone out there tried to use linux-2.5.2-pre11/drivers/loop.c?
> In my hacked version of loop.c, do_bio_blockbacked is often
> called with a bio that has bio->bi_idx set to 1 rather than 0
> (and with bi->bi_vcnt == 1), so it thinks it has no transfers to do.
> When I add the kludge of doing "bio->bi_idx = 0;" at the beginning
> of the routine, then it works fine.
Must be some of your changes, end_that_request_last is the one that
increments the index and that is not called for loop requests.
> It is possible that my problem is self-inflicted because I
> am using a version that I have adopted the "initial value" patch to,
> and I also added a temporary hack to force the requests to be processed
> one sector at a time, like so:
>
> blk_queue_max_segment_size(BLK_DEFAULT_QUEUE(MAJOR_NR), 512);
Well that change has absolutely zero impact on loop, so you cannot
possibly see any changes from that. Besides, _if_ it would have an
effect you did not limit the segment size to 512 bytes -- there is no
splitting going on, so you would still receive up to 4k of data at the
time per segment.
--
Jens Axboe