Commit Graph

10 Commits (42cf4a720cb85f71d43739b304cc1f25353f68c4)

Author SHA1 Message Date
Michael Brown 42cf4a720c [infiniband] Add node GUID as distinct from the first port GUID
iPXE currently uses the first port's port GUID as the node GUID,
rather than using the (possibly distinct) real node GUID.  This can
confuse opensm during the handover to a loaded OS: it thinks the port
already belongs to a different node and so discards our port
information with a warning message about duplicate ports.  Everything
is picked up correctly on the second subnet sweep, after opensm has
established that the "old" node no longer exists, but this can delay
link-up unnecessarily by several seconds.

Fix by using the real node GUID.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-09-16 03:30:45 +01:00
Michael Brown 52e54a8c69 [infiniband] Match GID/GUID terminology as used in the IBA
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-09-15 19:25:05 +01:00
Michael Brown ef8452a642 [infiniband] Respond to CM disconnection requests
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-09-12 22:32:02 +01:00
Michael Brown 8406115834 [build] Rename gPXE to iPXE
Access to the gpxe.org and etherboot.org domains and associated
resources has been revoked by the registrant of the domain.  Work
around this problem by renaming project from gPXE to iPXE, and
updating URLs to match.

Also update README, LOG and COPYRIGHTS to remove obsolete information.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-04-19 23:43:39 +01:00
Michael Brown 224ef7f483 [infiniband] Send CM requests to target node's GSI rather than SM's GSI 2009-10-16 23:03:47 +01:00
Michael Brown 0ff5c456cb [infiniband] Disambiguate CM connection rejection reasons
There is diagnostic value in being able to disambiguate between the
various reasons why an IB CM has rejected a connection attempt.  In
particular, reason 8 "invalid service ID" can be used to identify an
incorrect SRP service_id root-path component, and reason 28 "consumer
reject" corresponds to a genuine SRP login rejection IU, which can be
passed up to the SRP layer.

For rejection reasons other than "consumer reject", we should not pass
through the private data, since it is most likely generated by the CM
without any protocol-specific knowledge.
2009-08-10 22:31:55 +01:00
Michael Brown a0d337912e [infiniband] Generate more specific errors in response to failure MADs
Generate errors within individual MAD transaction consumers such as
ib_pathrec.c and ib_mcast.c, rather than within ib_mi.c.  This allows
for more meaningful error messages to eventually be displayed to the
user.
2009-08-10 22:30:06 +01:00
Michael Brown 46073f1239 [infiniband] Handle duplicate Communication Management REPs
We will terminate our transaction as soon as we receive the first CM
REP, since that provides all the state that we need.  However, the
peer may resend the REP if it didn't see our RTU, and if we don't
respond with another RTU we risk being disconnected.  (This protocol
appears not to handle retries gracefully.)

Fix by adding a management agent that will listen for these duplicate
REPs and send back an RTU.
2009-08-09 01:31:07 +01:00
Michael Brown 34bfc04e4c [infiniband] Update all other MAD users to use a management interface 2009-08-08 23:56:28 +01:00
Michael Brown cc2e767b5a [infiniband] Add Communication Manager (CM)
The Communication Manager is responsible for handling the setup and
teardown of RC connections.
2009-07-17 23:06:35 +01:00