This email was generated automatically, please do not reply
Common build parameters: --with-ipoib-mod --with-sdp-mod --with-srp-mod
--with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-core-mod
--with-addr_trans-mod --with-rds-mod --with-cxgb3-mod
Passed:
Passed on i686 with
Report of financial income
RYOZANPAKU CO., LTD
STATEMENT OF OPERATIONS
TWELVE MONTHS ENDED MAY 31,2006
Sales 57 873 948
Cost of sales 2 278 720
---
Gross profit55 595 228
Miscellaneoues expenses 30 937 295
Total operating expenses
On Thu, 2007-04-05 at 07:05, keshetti mahesh wrote:
ya I found that old document here
http://infiniband.sourceforge.net/LinuxSAS.1.0.1.pdf. its dated
8/1/2002 ..pretty
old.
Is there any effort going on to design a latest openSM design document
as such?
Nope; not that I'm aware of.
On Mon, 2007-04-02 at 09:08 +0300, Michael S. Tsirkin wrote:
On Sun, 2007-04-01 at 09:43 +0300, Michael S. Tsirkin wrote:
[...snip...]
I think that if we extend the API, we need to design it carefully
to cover as many use cases as possible.
Tom, could you explain what are you trying to do?
Hey Roland, I cc:ed you directly on this because I'm going to propose
something that involves you ;-)
Right now, in the OFED packaging, there are extra files added to the
overall stack that aren't currently part of any base RPM. I'm mainly
talking about things like the
Hi,
I heard that there is some version of bonding working over ipoib. Moni
Shoua provided some patches from the ipoib side. The latest patch is dated
3/28/2007. Which kernel version is this patch made for? On the other hand,
I haven't seen any changes to the bonding driver. Anyone know where I
The challenge with the current query/request method is that as we've
discussed the advertised max may not work. What makes the adjust/retry
unworkable is that you don't know which of the advertised maxes caused
the request to fail. So when you retry, which qp_attr do you adjust? The
send sge? The
Bugs can now be filed against OFED 1.2rc1.
Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business Unit
Cisco Systems
___
general mailing list
general@lists.openfabrics.org
On Thu, 2007-04-05 at 09:27 -0700, Sean Hefty wrote:
The challenge with the current query/request method is that as we've
discussed the advertised max may not work. What makes the adjust/retry
unworkable is that you don't know which of the advertised maxes caused
the request to fail. So when
Thanks, I applied this for 2.6.21
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
OpenSM/osm_port_info_rcv.c: In __osm_pi_rcv_process_endport,
isSMdisabled also indicates that an SM is present so poll SMInfo
I was getting ready to review the issmdisabled stuff, but now I
realize I don't understand what IsSMDisabled does. I thought that if
IsSMDisabled is set (is enabled?
To aid error messages and port of some applications it would be better
if wc-opcode could at least indicate if the failed CQE was for the RQ
or SQ.
I disagree. The spec is very clear on this point and I don't see any
reason to bloat driver code to work around buggy applications. In
fact I
I just tagged the 1.1-rc2 release of libibverbs and pushed it out to
my git tree on kernel.org:
git://git.kernel.org/pub/scm/libs/infiniband/libibverbs.git
(the name of the tag is libibverbs-1.1-rc2).
[actual I did this yesterday but forgot to send the announcement...]
I've also copied a
Roland,
From: Roland Dreier
I disagree. The spec is very clear on this point and I don't see any
reason to bloat driver code to work around buggy applications. In
fact I would support removing the population of error work completions
from other drivers if it shrinks the code.
I don't
On Thu, 2007-04-05 at 13:20, Roland Dreier wrote:
No; the requirements are that it not send SubnSet/Get but still needs to
respond to them.
IsSMdisabled goes in concert with the behavior above. See IBA 1.2 14.4.8
(p. 879).
OK, I just looked. Doesn't C14-70 say that
[EMAIL PROTECTED] wrote on Thu, 05 Apr 2007 09:45 -0500:
The challenge with the current query/request method is that as we've
discussed the advertised max may not work. What makes the adjust/retry
unworkable is that you don't know which of the advertised maxes caused
the request to fail. So
I don't understand why you are taking such a non-cooperative posture for
a simple request. All hardware models support this capability and it's
a 1 line change for mthca to parallel the other drivers.
Most previous stacks, including VAPI, had this capability.
While I agree
On Thu, 2007-04-05 at 13:48, Roland Dreier wrote:
C14-69 describes one such scenario where the SM is disabled out of band
and the only way other SMs know there is an inactive SM there is via
this capmask bit as it will not respond to SMInfo.
I guess that's the central part of my
Roland Dreier wrote:
Right now, in the OFED packaging, there are extra files added to the
overall stack that aren't currently part of any base RPM. I'm mainly
talking about things like the /etc/udev.d/rules/90-ib.rules,
/etc/init.d/openibd, etc. These files belong to none of the
p.865 C14-53 and C14-54.1.1 state the behavior I originally said (an not
active SM responds to SMInfo gets/sets). I think this superceeds the
first bullet in C14-70 which says incoming SMInfos are dropped.
That's something else -- it's talking about a running SM that is in
the NOT-ACTIVE
On Thu, 2007-04-05 at 14:16, Roland Dreier wrote:
p.865 C14-53 and C14-54.1.1 state the behavior I originally said (an not
active SM responds to SMInfo gets/sets). I think this superceeds the
first bullet in C14-70 which says incoming SMInfos are dropped.
That's something else -- it's
Good point. At a minimum, the spec is unclear about this (if they are
totally separate mechanisms).
When is the spec ever clear? :)
But I think the only interpretation that has a chance at matching the
current spec is to say that IsSMDisabled is not directly related to an
SM in the
Vlad,
Please pull from
git://git.openfabrics.org/~swise/libcxgb3 ofed_1_2
This commit fixes up all known inline issues with mvapich2 and cxgb3.
Also needed is a change to mvapich2 with is coming soon from the
mvapich2 folks. Both need to be pulled into the ofed kit together.
Thanks,
Roland, please review and pull patches from
git.openfabrics.org/~shefty/rdma-dev.git for-roland
This will pull in some patches that I would like queued for 2.6.22.
Sean Hefty (6):
rdma_ucm: simplify ucma_get_event code
ib_ucm: simplify ib_ucm_event code
ib_sa: set
I just tagged the 1.0.4 release of libmthca and pushed it out to
my git tree on kernel.org:
git://git.kernel.org/pub/scm/libs/infiniband/libmthca.git
(the name of the tag is libmthca-1.0.4).
I've also copied a tarball into my home directory on openfabrics.org,
with sha1sum:
HUMAN RESOURCES DEPARTMENT
THE CROWN CRUISE LINERS INTERNATIONA. SDN BHD
Lot Dga Section 44, Kltd Jalan Padungan, Lubuk, Antu,
SARAWAK 93675 MALAYSIA.
Tele/Fax: 00-60-321081455
HOTLINES: + 60176199552
Email : [EMAIL PROTECTED]
GREAT OPPORTUNITY! GREAT
On 4/5/07, Scott Weitzenkamp (sweitzen) [EMAIL PROTECTED] wrote:
Can I access OFED IPoIB and SRP/iSER devices from within a Xen virtual
machine?
I haven't tested SRP/iSER , but IPoIB works only on dom0 kernel.
You can't use any infiniband stuff on the guest OSes .
Gurhan
Scott
From: [EMAIL PROTECTED] on behalf of Michael S. Tsirkin
Quoting Linev Sergei [EMAIL PROTECTED]:
I take latest OFED 1.2 build (OFED-1.2-20070328-0625.tgz) and try to build
on my node:
Dual Opteron, SuSE 9.3, Kernel 2.6.19 with Real Time Preemt patch.
Problem with vnic is still there:
28 matches
Mail list logo
