On 08/05/2015 12:51 PM, Jason Gunthorpe wrote:
On Tue, Aug 04, 2015 at 11:41:16PM -0700, David Dillow wrote:
On Tue, 2015-08-04 at 12:09 -0600, Jason Gunthorpe wrote:
On Mon, Aug 03, 2015 at 11:33:51AM -0700, Bart Van Assche wrote:
Bart, do you know what hardware this workaround is for?
I hope the HW vendors can comment on this. Sorry but I'm not sure which HCA
models and/or firmware versions do not support FMR mapping with a non-zero
offset.
Perhaps David can remember why he added this:
commit 8f26c9ff9cd0317ad867bce972f69e0c6c2cbe3c
It's originally from commit 559ce8f150d7d031c79c4d79173860f1bdfe3ce4,
and the list's attempts at code archaeology failed us:
http://article.gmane.org/gmane.linux.drivers.rdma/7149
Okay.. So over time we went from a clear target specific bug described
9 years ago in 559ce through chinese whispers to a general unspecific
fear of non-zero offset FMR?
But nobody has described FMR failure in this way in the past 9 years
with any specificity?
My random guesses would be broken mthca firmware at the start of the
FMR feature (long since fixed) or a wonky target that is now 10 years
obsolete..
If it was an HCA bug, I strongly have to think it is fixed now. We use
FMR all over the place and SRP is the only area I've noticed this
restriction..
If it is a target bug, then FRWR should trigger it as wel, so we are
already about to revert that workaround.
I'm inclined to drop this entirely.. What do you think Bart?
Even today I see memory corruption at the initiator side with FMR and
not with FR if I leave out the alignment check. Since this only occurs
with FMR and not with FR that excludes the target side as a possible
cause. I will have a closer look at the srp_map_finish_fmr() function.
Always passing 0 as the second argument of srp_map_desc() in
srp_map_finish_fmr() is probably wrong. Before 2011 that second argument
was the page offset of the first sg-list entry.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
