OK, this works on my i386 system but I'm still getting
ib_mad: Invalid directed route
on ppc64. I'll try to debug what exactly is happening (ie put some
prints in to see why smi_handle_dr_smp_send() is rejecting it).
- R.
___
openib-general mail
Roland> OK, this works on my i386 system but I'm still getting
Roland> ib_mad: Invalid directed route
Roland> on ppc64. I'll try to debug what exactly is happening (ie
Roland> put some prints in to see why smi_handle_dr_smp_send() is
Roland> rejecting it).
By the way, the i3
On Tue, 2004-11-09 at 15:53, Roland Dreier wrote:
> By the way, the i386 system is connected directly to the switch
> running the SM,
That's the config I run in too.
> while the ppc64 system is a few hops away.
I think Sean's original config was a couple of hops.
> So it's
> just as likely to
OK, I think I understand the problem, but I'm not sure what the
correct solution is. When a DR SMP arrives at a CA from the SM,
hop_cnt == hop_ptr == number of hops in the directed route, and
somehow they are not updated correctly by the time the response
reaches handle_outgoing_smp().
I can't fo
On Tue, 2004-11-09 at 18:54, Roland Dreier wrote:
> OK, I think I understand the problem, but I'm not sure what the
> correct solution is. When a DR SMP arrives at a CA from the SM,
> hop_cnt == hop_ptr == number of hops in the directed route,
What was the number ?
> and somehow they are not upd
Roland> OK, I think I understand the problem, but I'm not sure
Roland> what the correct solution is. When a DR SMP arrives at a
Roland> CA from the SM, hop_cnt == hop_ptr == number of hops in
Roland> the directed route,
Hal> What was the number ?
For one port it was 4 and for
It seems that MAD handling is still not quite right. It seems in my
set up that IPoIB is not seeing the response to its MCMember
set... (it does look like the query is reaching the SM)
- R.
___
openib-general mailing list
[EMAIL PROTECTED]
http://openi
On Wed, 2004-11-10 at 00:55, Roland Dreier wrote:
> It seems that MAD handling is still not quite right. It seems in my
> set up that IPoIB is not seeing the response to its MCMember
> set... (it does look like the query is reaching the SM)
This is a separate issue from the ports not becoming act
> "Hal" == Hal Rosenstock <[EMAIL PROTECTED]> writes:
Hal> I can see now that this is wrong and have a fix for what
Hal> stops IPoIB from working. The problem was that the response
Hal> was received by the MAD layer but not dispatched due to the
Hal> change(s) noted above.
On Wed, 2004-11-10 at 10:36, Roland Dreier wrote:
> Yes, IPoIB works for me again.
Thanks for validating.
> Hal> Also, it seems to me that no response needs to be handed to
> Hal> process_mad. Does this optimization make sense ?
>
> I'm not sure I understand the question. process_mad d
Hal> I'm asking about also checking the method prior to calling
Hal> process_mad. If the method is a response method (e.g. GetResp
Hal> for one), we could bypass calling process_mad. Or is this not
Hal> worth the extra checks in the MAD layer as it is low enough
Hal> overhead an
Hal Rosenstock wrote:
> On Wed, 2004-11-10 at 00:55, Roland Dreier wrote:
>
>>It seems that MAD handling is still not quite right. It seems in my
>>set up that IPoIB is not seeing the response to its MCMember
>>set... (it does look like the query is reaching the SM)
>
>
> This is a separate iss
Hal Rosenstock wrote:
This is a separate issue from the ports not becoming active (DR handling
issue). I broke this part yesterday (not a good day at all :-( at either
r1184 and/or r1181 when I added what I thought was correct based on
Sean's emails (not dispatching additional error cases in
ib_mad
Sean> What exactly does it mean then when process_mad returns
Sean> success? Do any of the return bits from process_mad
Sean> indicate that the MAD was for the HCA driver?
SUCCESS means that process_mad didn't encounter any errors. If REPLY
or CONSUMED is set then process_mad actuall
By the way, if I am reading the code correctly, it looks like the MAD
layer only checks for IB_MAD_RESULT_REPLY and not
IB_MAD_RESULT_CONSUMED. If IB_MAD_RESULT_CONSUMED is set then the
packet is something like a trap repress handled by the SMA or a
locally generated trap that the driver forwarded
On Wed, 2004-11-10 at 11:59, Roland Dreier wrote:
> Sean> What exactly does it mean then when process_mad returns
> Sean> success? Do any of the return bits from process_mad
> Sean> indicate that the MAD was for the HCA driver?
>
> SUCCESS means that process_mad didn't encounter any e
On Wed, 2004-11-10 at 11:05, Roland Dreier wrote:
> I think keeping the MAD code simpler is probably best right now.
Hope that is for technical reasons and not for the recent missteps.
-- Hal
___
openib-general mailing list
[EMAIL PROTECTED]
http://ope
Roland> I think keeping the MAD code simpler is probably best right now.
Hal> Hope that is for technical reasons and not for the recent missteps.
Yes, it's just that the MAD code is quite complicated already with
multiple tests for DR SMPs etc; mad.c alone is over 2000 lines now. I
don't
I haven't cleared the other issues before getting back to this but
wanted to respond to some of the points below:
On Tue, 2004-11-09 at 23:55, Roland Dreier wrote:
> Roland> OK, I think I understand the problem, but I'm not sure
> Roland> what the correct solution is. When a DR SMP arrive
Roland> I guess the problem with calling smi_handle_dr_smp_recv()
Roland> twice on the same packet is that the function may alter
Roland> the packet.
Hal> No, the second call to smi_handle_dr_smp_recv() was on the
Hal> outgoing response and not the incoming request. The thought
On Wed, 2004-11-10 at 16:29, Roland Dreier wrote:
> Roland> I guess the problem with calling smi_handle_dr_smp_recv()
> Roland> twice on the same packet is that the function may alter
> Roland> the packet.
>
> Hal> No, the second call to smi_handle_dr_smp_recv() was on the
> Ha
On Wed, 2004-11-10 at 12:02, Roland Dreier wrote:
> By the way, if I am reading the code correctly, it looks like the MAD
> layer only checks for IB_MAD_RESULT_REPLY and not
> IB_MAD_RESULT_CONSUMED.
You are reading the code correctly.
> If IB_MAD_RESULT_CONSUMED is set then the
> packet is som
Hal Rosenstock wrote:
On Wed, 2004-11-10 at 11:59, Roland Dreier wrote:
Sean> What exactly does it mean then when process_mad returns
Sean> success? Do any of the return bits from process_mad
Sean> indicate that the MAD was for the HCA driver?
SUCCESS means that process_mad didn't encount
23 matches
Mail list logo
