I was out on vacation the last week of December and hence the delayed response.
Roland Dreier wrote: > > I discovered the following Oops while developing a patch to enable SRQ on > HCAs with fewer than > > 16 SG elements. > > So is this oops with some version of your patch for limited SRQ > scatter entries applied? It's hard to know exactly what is going > wrong but I suspect that if you get a device that allows more than 16 > SRQ scatter entries, your patch passes that value for num_sg without > changing the declaration of rx_sge[] to have enough entries, so when > posting the receive request, the low-level driver goes off the end of > the array. rx_sge[] could have been the culprit. I now limit the max_sge to IPOIB_CM_RX_SG, and so that is not an issue any more. The latest patch submitted : http://lists.openfabrics.org/pipermail/general/2007-December/044298.html has this fix. > > > The root of this issue appears to be that ib_query_device(priv->ca, &attr) > > reports an incorrect value for attr.max_srq_sge. The value that > > ib_query_device returns is 28 (instead of 16 that I expected). > > Why do you think the value 28 is incorrect? At one stage ib_query_device() was returning max_srq_sge of 28 and ib_query_srq() returned max_sge of 16. And because of the discrepancy I thought 28 was incorrect. However, now both return 28 and that is probably a moot point. Pradeep _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
