Just a small thing FW version 2.0.0 is very old FW.
You should upgrade it to the latest which is now 3.3.2
-Itamar
-Original Message-
From: Troy Benjegerdes [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 17, 2005 7:11 AM
To: Roland Dreier
Cc: openib-general@openib.org
Subject:
[EMAIL PROTECTED]
¡¡-
[EMAIL PROTECTED]@[EMAIL PROTECTED]@f«EpXgEnCq[
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL
PROTECTED]@[EMAIL
Title: User Level Events - request for support
I would like to propose for gen2 stack to have a user level API supporting registration for notifications on unaffiliated asynchronous events.
As an example in cases when the local IB port link goes down an SM that runs on top of this port needs
Quoting r. Eitan Zahavi [EMAIL PROTECTED]:
Subject: User Level Events - request for support
I would like to propose for gen2 stack to have a user level API supporting
registration for notifications on unaffiliated asynchronous events.
As an example in cases when the local IB port link
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: userspace doorbells
Michael Roland, I see you have made the doorbell page volatile.
Michael This makes sence, and must be enough on x86_64, but for
Michael this to work on PPC, wont you still need to insert a
Michael
Title: RE: [openib-general] failure using second hca via udapl
gen1 stack ULPs was not tested with multiple HCAs - so I guess there is more then one bug there.
Tziporet
-Original Message-
From: mark kowalski [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 16, 2005 7:31 PM
To:
Title: RE: [openib-general] how to turn on kernel level tracing (mtl_log)
Regarding the low level driver (VAPI) only:
The kernel debug messages can be generated only at compile time.
to generate them one need to compile with the variable MTCONF set to debug.
Once it is compiled you can decide
On Wed, 2005-03-16 at 23:58, Troy Benjegerdes wrote:
I'm having trouble building opensm et all from roland-uverb... (and I
can't really test NetPIPE without an SM )
Please note that OpenSM changes are not being integrated on the
roland-uverbs branch and this is essentially a snapshot from when
From the latest http://standards.ieee.org/regauth/oui/oui.txt
00-14-05 (hex)OpenIB, Inc.
001405 (base 16)OpenIB, Inc.
M/S JF5-357
2111 NE 25th Avenue
Hillsboro OR
agent: Add IB ping server agent (used with ibping diagnostic tool)
Signed-off-by: Shahar Frank [EMAIL PROTECTED]
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Index: include/ib_mad.h
===
--- include/ib_mad.h(revision 2012)
+++
Quoting r. Hal Rosenstock [EMAIL PROTECTED]:
Subject: [PATCH] agent: Add IB ping server agent
agent: Add IB ping server agent (used with ibping diagnostic tool)
Signed-off-by: Shahar Frank [EMAIL PROTECTED]
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Index: include/ib_mad.h
On Thu, 2005-03-17 at 09:44, Michael S. Tsirkin wrote:
I think we want an option to compile this out of kernel, at least
for documentation purposes.
Not sure what you mean for documentation purposes.
I think ping its useful (at least here in mellanox I think
I was the one who first proposed
Quoting r. Hal Rosenstock [EMAIL PROTECTED]:
Subject: Re: [PATCH] agent: Add IB ping server agent
On Thu, 2005-03-17 at 09:44, Michael S. Tsirkin wrote:
I think we want an option to compile this out of kernel, at least
for documentation purposes.
Not sure what you mean for documentation
On Thu, 2005-03-17 at 05:03, Michael S. Tsirkin wrote:
However I think I agree it might make sence to add this capability
to umad. Since sm is already blocking on read from umad, it might
be simplest to make read return with an error code. Does this make
sence?
Alternatively, we could try
I would suggest moving the ping server at least into its own source
file, if not into its own module. I'm not convinced that we want to
have a vendor-specific MAD handler unconditionally compiled into the
core MAD support.
It might make some sense to have the option of handling ping packets
in
On Thu, 2005-03-17 at 10:11, Roland Dreier wrote:
I would suggest moving the ping server at least into its own source
file, if not into its own module. I'm not convinced that we want to
have a vendor-specific MAD handler unconditionally compiled into the
core MAD support.
Moving this into
On Thu, 2005-03-17 at 10:11, Roland Dreier wrote:
I would suggest moving the ping server at least into its own source
file, if not into its own module. I'm not convinced that we want to
have a vendor-specific MAD handler unconditionally compiled into the
core MAD support.
It might make
Hal One more thing: This is analagous to the (ICMP) ping server
Hal built into the kernel.
Sort of, except it's not part of the IB spec. ICMP and in particular
ICMP echo support is a MUST for any RFC-compliant IP implementation.
One other thought just occurred to me -- what advantages
Title: RE: [openib-general] [PATCH] agent: Add IB ping server agent
Hi Hal,
If the response would have included the guid and lid of the responding port this could potentially be used to validate path record cache in a distributed manner...
Also could help in diagnostics.
Eitan Zahavi
Grant Troy, in order to use MSI or MSI-X, you need 3.3.2
Grant firmware. And in case it's not obvious, expect best perf
Grant with MSI-X if you platform supports it. Either msflint or
Grant tvflash should work for upgrading the cards.
I don't think MSI is supported by Linux on
Roland Dreier wrote:
I would suggest moving the ping server at least into its own source
file, if not into its own module. I'm not convinced that we want to
have a vendor-specific MAD handler unconditionally compiled into the
core MAD support.
I agree with this. This feels like it should be a
On Thu, 2005-03-17 at 12:38, Sean Hefty wrote:
Roland Dreier wrote:
I would suggest moving the ping server at least into its own source
file, if not into its own module. I'm not convinced that we want to
have a vendor-specific MAD handler unconditionally compiled into the
core MAD
Quoting r. Hal Rosenstock [EMAIL PROTECTED]:
Subject: Re: [PATCH] agent: Add IB ping server agent
On Thu, 2005-03-17 at 12:38, Sean Hefty wrote:
Roland Dreier wrote:
I would suggest moving the ping server at least into its own source
file, if not into its own module. I'm not convinced
Michael S. Tsirkin wrote:
I think a compile option is simpler, and would be sufficient.
We can examine the different MAD agents to identify common
functionality that can be pulled into a library or set of helper
functions. I've already started trying to identify areas with the RMPP
On Thu, 2005-03-17 at 12:48, Michael S. Tsirkin wrote:
Quoting r. Hal Rosenstock [EMAIL PROTECTED]:
OK but this will result in some code duplication. I should have this
later today and will revert back the changes to agent.c and agent_priv.h
of earlier today.
I think a compile option is
Fix error handling in mr allocation for arbel native:
mthca_free must get an mr index, not a key.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Index: hw/mthca/mthca_mr.c
===
--- hw/mthca/mthca_mr.c (revision 2012)
+++
On Thu, 2005-03-17 at 12:45, Michael S. Tsirkin wrote:
I think GetResp will always go to the SM, while OPENIB_PING is point to
point.
Response matching is transaction ID based with the MAD agent ID embedded
in the transaction ID so these can be demultiplexed to separate
entities.
-- Hal
Hi Eitan,
On Thu, 2005-03-17 at 11:55, Eitan Zahavi wrote:
If the response would have included the guid and lid of the responding
port this could potentially be used to validate path record cache in a
distributed manner...
Also could help in diagnostics.
An entire range of IB ping types
Michael I mean, they will go to the SM LID.
Are you sure? Where is this in the spec? I really thought that get
responses for SM class queries will be formed the same way as
responses for any other class. That is, the response will be sent to
source LID of the query, etc.
- R.
Michael I think a compile option is simpler, and would be sufficient.
Hal I agree. Is this an acceptable approach ?
I think I'd prefer to avoid having this #ifdef'ed. If we have OpenIB
vendor class handling nicely encapsulated, it's nice and maintainable,
and it makes it clear how
Hal An entire range of IB ping types could be implemented
Hal analagous to ICMP types.
Seems like a good argument for splitting the support out into its own
source file at least.
- R.
___
openib-general mailing list
openib-general@openib.org
On Thu, 2005-03-17 at 11:38, Roland Dreier wrote:
One other thought just occurred to me -- what advantages does this
vendor-specific ping MAD have over a LID-routed NodeDescription get query?
No MKey issue is the first thing that comes to mind.
Also, the ability to support various options such
Hal Rosenstock wrote:
An entire range of IB ping types could be implemented analagous to ICMP
types.
This is more of a reason to break this out into a separate module.
- Sean
___
openib-general mailing list
openib-general@openib.org
agent: Remove IB ping server from agent
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Index: agent_priv.h
===
--- agent_priv.h(revision 2017)
+++ agent_priv.h(working copy)
@@ -57,7 +57,6 @@
int port_num;
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH] agent: Add IB ping server agent
Michael I mean, they will go to the SM LID.
Are you sure? Where is this in the spec? I really thought that get
responses for SM class queries will be formed the same way as
responses
This patch implements FMR support. I also rolled into it two fixes
for regular mrs that I posed previously, let me know if its a problem.
This seems to be working fine for me, although I only did relatively basic
tests. Both Tavor and Arbel Native modes are supported. I made some tradeoffs
for
On Thu, 2005-03-17 at 15:25, Michael S. Tsirkin wrote:
Out of curiosity - what is the M_Key protection level currently set by
OpenSm?
PortInfo::M_KeyProtectBits = 0
___
openib-general mailing list
openib-general@openib.org
Quoting r. Hal Rosenstock [EMAIL PROTECTED]:
Subject: Re: [PATCH] agent: Add IB ping server agent
On Thu, 2005-03-17 at 15:25, Michael S. Tsirkin wrote:
Out of curiosity - what is the M_Key protection level currently set by
OpenSm?
PortInfo::M_KeyProtectBits = 0
No mkey issues then
Hal Rosenstock wrote:
ping: Add IB ping server agent (used with ibping diagnostic tool)
{snip}
+ ret = ib_ping_port_open(device, cur_port);
+ if (ret) {
+ printk(KERN_ERR PFX Couldn't open %s port %d
+ for ping
On Thu, 2005-03-17 at 15:55, Sean Hefty wrote:
My preference would still be to keep this a separate module. IMO, we
need to improve the encapsulation of the MAD layer, not weaken it,
possibly removing all MAD agents from mad.c.
OK but I don't see what would bring it in other than manually
On Tue, Mar 01, 2005 at 08:42:47AM -0800, Roland Dreier wrote:
Hi Greg,
It turns out that Mellanox decided to change the device ID at the last
minute. So of course there will be parts with both IDs. Here's an
updated patch that includes both IDs. Please use this instead.
Applied, thanks.
On Wed, Mar 16, 2005 at 08:58:54AM -, Paul Baxter wrote:
From: Troy Benjegerdes [EMAIL PROTECTED]
Once I get it built and tested locally, I'll probably stick some results
and a link up at http://scl.ameslab.gov/Projects/InfiniBand/
Sooo... what's the easiest way for me to test this if I
Thanks for implementing this. You saved me a lot of work and Libor
will be very happy when he gets back next week.
Some comments from my first read through:
This patch implements FMR support. I also rolled into it two fixes
for regular mrs that I posed previously, let me know if its a
Thanks, applied.
___
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
Thanks, applied.
___
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
45 matches
Mail list logo
