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 encounter
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
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.
Hal So I am
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
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 issue from
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
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 actually
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
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 errors.
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 arrives
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
Hal
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
agent: Fix agent_mad_send PCI mapping and gather address and length
Index: agent.c
===
--- agent.c (revision 1183)
+++ agent.c (working copy)
@@ -116,10 +116,10 @@
/* PCI mapping */
gather_list.addr =
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
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 i386
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
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
19 matches
Mail list logo
