| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [TEST PATCH] xen/blkfront: use blk_rq_map_sg togener
Jan Beulich wrote:
But isn't this just reducing the likelihood of hitting the problem? Without
understanding why the entry limit gets exceeded (and fixing that), the
potential for this to happen again is still there.
I had the same thought, but Jens says it fixes the real problem, so that
satisfies me ;)
Greg reported that simply decreasing the max segments to one less than
the ring size was sufficient to clear up the symptoms, which indicates
it was never submitting more than one extra segment. Jens writes:
The second problem is
that the block layer then appears to create one too many segments, but
from the dump it has rq->nr_phys_segments ==
BLKIF_MAX_SEGMENTS_PER_REQUEST. I suspect the latter is due to
xen-blkfront not handling the merging on its own. It should check that
the new page doesn't form part of the previous page.
which suggests that blkfront was omitting a merging check that driver
should perform, results in this problem. I don't really understand why
the upper layers can't do this merge check, but I'm sure Jens has a good
reason.
Of course, the change made here has its own benefits, so I fully agree
it should be applied (though I wonder whether it's indeed a -stable
candidate).
Well, it appears to be the proper fix to a real bug observed in the
field, which makes it an ideal -stable candidate.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home