On Mon, Jan 4, 2010 at 2:34 AM, David Dillow wrote:
>
> On Sat, 2010-01-02 at 13:19 +0100, Bart Van Assche wrote:
> > This patch fixes this issue by adding support for SRP_CRED_REQ information
> > units in the SRP initiator. Additionally, this patch makes the per-session
> > variable req_lim visib
Hi Jeff,
On Dec 31, 2009, at 11:08 AM, Jeff Haferman wrote:
>
> Linux kernel = 2.6.18-92.1.26.el5_lustre.1.6.7.2smp
> OS = Centos 5.2
>
> We have a Sun Blade system with Sun IB products
> (switch= Sun part number X2821A-Z 36 port QDR switch)
> (hcas = Sun part number X4216A-Z dual port DDR PCI
SRP_SQ_SIZE was used in many places that needed to know about the
real size of the data structures, and needed to use a magic offset.
Additionally, the meaning of the value was different depending on
where it was used. Prepare for future work by naming the use
appropriately for the site.
Also, doc
Export the target's current request limit, in case it is useful for
debugging.
---
I don't feel strongly that this should go in, only that it should be
a separate patch if it does.
drivers/infiniband/ulp/srp/ib_srp.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff -
This patch adds support for SRP_CRED_REQ to avoid a lockup by targets
that use that mechanism to return credits to the initiator. This
prevents a lockup observed in the field where we would never add the
credits from the SRP_CRED_REQ to our current count, and would therefore
never send another comm
On Sat, 2010-01-02 at 13:19 +0100, Bart Van Assche wrote:
> This patch fixes this issue by adding support for SRP_CRED_REQ information
> units in the SRP initiator. Additionally, this patch makes the per-session
> variable req_lim visible through sysfs, which makes observing the initiator
> state e
Jeff Haferman wrote:
I tried posting this to gene...@lists.openfabrics.org and got an auto-reply
saying that
list is no longer active and to instead post here... I posted here a few days
ago but
no response, so, my question is, does anyone have any ideas, or, is there a more
appropriate place t
I tried posting this to gene...@lists.openfabrics.org and got an auto-reply
saying that
list is no longer active and to instead post here... I posted here a few days
ago but
no response, so, my question is, does anyone have any ideas, or, is there a more
appropriate place to post?
I've made a b
On 09:48 Thu 31 Dec , Hal Rosenstock wrote:
>
> I thought this was only done when these issues are actually found and
> in general we are relying on compliance.
OpenSM can rely on compliance in many cases, but it cannot crash (or
become nonoperational in any other way) relying on compliance.
