>> pri_path = alt_path = path 1
>> works
>>
>
>no, I haven't tested that. I can try that too, if u think that can
>provide useful info..
I misunderstood one of your earlier e-mails then. I threw together a test case
to try this, and it worked for me. Can you see if the same works for you? If
no
somenath wrote:
> Sean Hefty wrote:
>
>> Can you confirm that I have your test failure correctly?
>>
>> pri_path = path 1
>> alt_path = NULL
>> works
>
>
>
> yes.
>
>>
>> pri_path = path 2
>> alt_path = NULL
>> works
>>
> yes.
>
>> pri_path = alt_path = path 1
>> works
>>
>
> no, I haven't tested
Sean Hefty wrote:
> Can you confirm that I have your test failure correctly?
>
> pri_path = path 1
> alt_path = NULL
> works
yes.
>
> pri_path = path 2
> alt_path = NULL
> works
>
yes.
> pri_path = alt_path = path 1
> works
>
no, I haven't tested that. I can try that too, if u think that can
Can you confirm that I have your test failure correctly?
pri_path = path 1
alt_path = NULL
works
pri_path = path 2
alt_path = NULL
works
pri_path = alt_path = path 1
works
pri_path = alt_path = path 2
works
pri_path = path 1
alt_path = path 2
fails
Are the only difference between path 1 and 2
Sean Hefty wrote:
> somenath wrote:
>
>> I must be missing something here: do I have to do anything with:
>>
>> 1.path_mig_state field of ib_qp_attr?
>
>
> This should be set when transitioning to RTS. The field is set by the
> ib_cm in ib_cm_init_qp_attr. (Actually, are you using this call to
somenath wrote:
> I must be missing something here: do I have to do anything with:
>
> 1.path_mig_state field of ib_qp_attr?
This should be set when transitioning to RTS. The field is set by the ib_cm in
ib_cm_init_qp_attr. (Actually, are you using this call to set your QP
attributes?)
> 2.
John> I was confused by this, but I believe that the readl to reg
John> 698 is not completing because the DDR memory is not yet
John> available because SYS_EN never got down to the card before
John> the readl, or did not complete before readl. This could be
John> wrong I don't
Hi all,
I've a question about one of the gen2_basic tests. The test is test 3
of the QP test collection. There's a piece of code in this test that
does a modify_qp, followed by a query_qp. The query QP bit checks that
the modify_qp did what was expected of it. One check looks like this:
Roland,
Thanks for looking at this, I appologize for not giving enough detail,
I'm never too sure how much to post.
Roland Dreier wrote:
> John> I put a PCI-X analyzer on the bus along with the HCA and
> John> found that we saw a Memory Read to register 698 but no
> John> evidence of
Sean Hefty wrote:
>>ib_sa_path_rec_get(
>> device,
>> HCA_PRM_PORT, /* first port =1, second
>>port=2 */
>>
>>
>
>Note that this tells the ib_sa module which port to send the request out on.
>It's separate from the actual path information being req
Oh, and no Signed-off-by: line either...
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
John> I put a PCI-X analyzer on the bus along with the HCA and
John> found that we saw a Memory Read to register 698 but no
John> evidence of the SYS_EN command making it down to the
John> card. We were trying to read the gobit before the DOORBELL
John> had completed. I think th
Roland,
I have been testing OFED-1.1 on SGI Altix (ia64) and on certain of our machines
we see a kernel panic because of a PIO read error coming from mthca_cmd_post()
Here's the stack trace :-
0xe06040f28000 4957 4913 04 R 0xe06040f283a0 *modprobe
0xa001caa0 ia64_l
> ib_sa_path_rec_get(
>device,
>HCA_PRM_PORT, /* first port =1, second
>port=2 */
Note that this tells the ib_sa module which port to send the request out on.
It's separate from the actual path information being requested, which is based
on the GID
At 11:24 AM 10/13/2006, Sean Hefty wrote:
> >3. in req_handler() we follow the same steps as we have done without APM..
> > i.e. create qpairs, change qp state to RTR and then send REP.
> >
> >however, when trying to change state to RTR usinb ib_modify_qp() I get
> >an error (-22).
> >
> >two in
Sean Hefty wrote:
>>3. in req_handler() we follow the same steps as we have done without APM..
>> i.e. create qpairs, change qp state to RTR and then send REP.
>>
>>however, when trying to change state to RTR usinb ib_modify_qp() I get
>>an error (-22).
>>
>>two info: same code will work if I pa
Sean strikes again. That seems perfect.
On 10/13/06 12:29 PM, "Steve Wise" <[EMAIL PROTECTED]> wrote:
>
> That seems good.
>
>
>
> On Fri, 2006-10-13 at 09:29 -0700, Sean Hefty wrote:
>> Tom Tucker wrote:
>>> The only "correct" way would be to declare a sockaddr structure * to a
>>> struct
Krishna Kumar2 wrote:
> Oops, I made it against older bits. Should I recreate this patchset against
> latest tree (and change #12 as suggested above) ?
Actually, I'd just like the patches against the upstream kernel (maybe for a
for-2.6.20 branch in Roland's git tree?). Patch 7 is a good cleanu
>3. in req_handler() we follow the same steps as we have done without APM..
> i.e. create qpairs, change qp state to RTR and then send REP.
>
>however, when trying to change state to RTR usinb ib_modify_qp() I get
>an error (-22).
>
>two info: same code will work if I pass alt_path as NULL or ch
Steve Wise wrote:
> FYI: Once the ucma gets into roland's git tree, I'll base the chelsio
> drivers against the appropriate branch (for-2.6.20?) and test this whole
> thing with the chelsio driver, user and kernel.
Ok - I also have updates to the librdmacm that matches up with these changes.
I
FYI: Once the ucma gets into roland's git tree, I'll base the chelsio
drivers against the appropriate branch (for-2.6.20?) and test this whole
thing with the chelsio driver, user and kernel.
Steve.
On Tue, 2006-10-10 at 16:51 -0700, Sean Hefty wrote:
> Export the rdma_cm capabilities to users
That seems good.
On Fri, 2006-10-13 at 09:29 -0700, Sean Hefty wrote:
> Tom Tucker wrote:
> > The only "correct" way would be to declare a sockaddr structure * to a
> > struct socket_storage allocated buffer and waste 4 bytes in the rdma_cm_id
> > structure.
> >
> > Anyway, it's buggin' me...M
Tom Tucker wrote:
> The only "correct" way would be to declare a sockaddr structure * to a
> struct socket_storage allocated buffer and waste 4 bytes in the rdma_cm_id
> structure.
>
> Anyway, it's buggin' me...Maybe I'm being anal...
>
> Thoughts?
We could change the definition to something sim
Sean:
The definition of rdma_cm_id in usermode defines the src and dst addresses
as sockaddr_in6. I understand that the reason you did this is because this
guarantees that enough space is allocated. The problem is that the user will
assume that a structure defined as sockaddr_in6 is in fact an in6
Hello,
I've tagged the current version of the iwarp branch. This tag (or copy
really) marks the 2.6.17 stable version of the iwarp branch including
the chelsio rnic LLD and RDMA drivers. This tag should be used if you
intend to run iwarp on 2.6.17 kernels.
To check out this branch:
svn co
25 matches
Mail list logo
