I think that the patch is specific for srp initiator using Mellanox
FMR. It tried to avoid indirect desc with Mellanox FMR having
first-byte-offset != 0. Since the low level implementation of
mlx4/mthca_map_phys_fmr() did not create + setup MPT for FMR with
first_byte_offset != 0. The
Maybe we can use MST's current email to ask him... Michael, do you have
any memory of the issue we worked around here?
I have question regarding workaround introduced in commit 559ce8f1 of
the mainline tree:
IB/srp: Work around data corruption bug on Mellanox targets
I'm sure this was tested and shown to fix the problem; I'm just confused
as to what the problem really was and if this is still relevant. Can
someone please enlighten me?
At this point I'm afraid it's all lost in the mists of time, but the
original patch seems to have come from
This may be due to the fact that the IB MTU is 2048. Every 1500 bytes
packet
is padded to 2048 bytes before being sent through the wire, so you're loosing
roughly 25% bandwidth compared to an IPoIB MTU which is a multiple of 2048.
This isn't true. IB packets are only padded to a
suspect for these patches most won't be).
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg@lists.openfabrics.org
http
(the same approach we
use for the COW protection itself).
seems like a reasonable alternative.
Thanks,
Roland
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
for
each node in the tree. Then for the registration of MR B above, we
would find the node for MR A covered MR B and we should be able to get
the ref counting right.
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business
the _ETY enum? Maybe it doesn't break anything serious but
why risk it?
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg
steaming. How about if OFED developers take a little time to think
things through?
/rant
In other words, can someone explain the plan for this raw QP stuff to me?
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal
Thanks, nice work. I like this approach. Alex (Vainman) any comments
on this?
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
IB_MGMT_MAD_STATUS_INVALID_ATTRIB_VALUE 0x001c
The indentation of values seems pretty crazy here. Also I'm not sure
what most of these defines are for? They seem unused in this patch.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com
more dangerous.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman
- parsing if the first madvise fails.
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg@lists.openfabrics.org
http
. If you want it
applied to an OFED tree, send it to ewg.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg@lists.openfabrics.org
http
I thought you were referring to the changes made by this patch
920d706. Should I re-send this patch?
Yes, please work out what changes are still required and send a new patch.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about
locking assumptions.
It would be nice if we didn't have this reference counting sometimes
used and sometimes not used. I'll have to think about whether this can
be made cleaner.
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about
Also keep in mind that mlx4_en patches typically go through Davem and
netdev, not my tree.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing
it shouldn't be in multicast.c. I'm just
wondering why you don't have the same thing for sa_query.c.
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg
= ib_get_client_data(device, sa_client);
if (!sa_dev)
return 0x7f;
so if we never add the sa_client structure it just returns.
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Right, it's already applied.
Doesn't seem to be all there... eg there is nothing for ethernet headers.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
performance impact from
reading /proc/pid/maps line-by-line. (And by the way, as a trivial
optimization, it would make sense to me to check the address of each map
before doing the strstr).
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about
? Seems we just crash on uninitialized
structures. I guess we're assuming that the kernel is smart enough not
to do that?
Also I'm wondering why you did the count stuff to ignore IBoE-only
devices in multicast.c but not sa_query.c?
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal
, could we just have this function look at
the link layer, and if it's ethernet, then always set the GRH flag?
Seems simpler than requiring the upper layers to do this and then pass
the result in?
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web
munging and reference counting, and just call things directly.
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg
2. Fix wrong implementation of ib_ud_header_init(). A different patch was
sent
to Roland.
This patch no longer applies, I guess because you already sent me this
fix (which is now upstream since 2.6.34-rc1).
--
Roland Dreier rola...@cisco.com || For corporate legal information go
is does addressing via
the CMA mapping to GIDs followed by an unspecified mapping from GIDs to
Ethernet addresses).
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
, since a
device-driver shouldn't allow this method unless it actually implements
it.
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
we get rid of this and just
rename mlx4_find_get_prot_dev() to mlx4_get_prot_dev()?
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg
+u8 mac_0_1[2];
+u8 mac_2_5[4];
This looks a bit odd. Any reason why you don't just have u8 mac[6];
in this structure?
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri
OK, I applied this with just the first chunk.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg@lists.openfabrics.org
http
that only work
for libhugetlbfs or can we recognize direct mmap of hugetlb pages?
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg
if there genuinely are CPUs
that are available for hotplug.
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg@lists.openfabrics.org
http
Why do we not allow umad for IBoE ports? I understand there's no QP0
but why can't userspace use QP1 just like for IB link layer ports?
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
() better.
In any case as I add patches to my branch, you can stop worrying about
them, which should make keeping this series updated easier.
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
)
+continue;
Why do we need this chunk here? How could a netdev get on our list if
we never create IPoIB interfaces for IBoE ports?
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri
+
+sa_dev = kzalloc(sizeof *sa_dev +
Do you happen to remember why you needed these kmalloc - kzalloc conversions?
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
the upstream kernel
is nonsense -- RHEL6 is getting RDMA drivers from the upstream kernel.
So asking what version of OFED will be in RHEL6 is a bit like asking
what version of SLES will be in RHEL6.
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web
-- the rest of the world
deals with that just fine, without having to tie RHEL's versioning to
someone else's distribution.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
100 work completions enqueued on the CQ eventually.
In any case, it is certainly fine to do poll(), epoll, SIGIO, whatever
on the completion channel file descriptor. You can do fcntl to set it
to nonblocking mode too.
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go
good debugging, applied thanks.
I do worry (as Moni mentioned) that this doesn't explain why you would
get send failures in this case, but the patch itself is well-explained
and looks obviously correct so I think we should apply it.
--
Roland Dreier rola...@cisco.com
For corporate legal
Sorry, I was referring to my patch not Eli's.
Heh, I never would have said anything about your patch was obvious.
I skimmed yours once but I do want to read it more carefully.
Did you ever say what test case you are using to provoke the problem you're
fixing?
--
Roland Dreier rola
thanks, applied.
--
Roland Dreier rola...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman
OK, I'm planning on sending this upstream later today. Looks very small
and simple, and then we can figure our what if anything we want to do
for 2.6.34.
Make sense for everyone?
- R.
--
Roland Dreier rola...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about
this approach. Then re-submit once we come to consensus...
That makes sense to me. Someone please send me a tested revert.
--
Roland Dreier rola...@cisco.com
Cisco.com - http://www.cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Is this only an iwarp issue? IE do all IB devices support hw
loopback? And will all future devices support it (IE is it an IBTA
requirement)?
I do think IBA requires loopback to work. Can't quote chapter verse
off the top of my head.
--
Roland Dreier rola...@cisco.com
Cisco.com - http
- Add - uMMU notifier kernel module - In general we wish to add it,
Tziporet will try to find someone that can do it soon
Please do *NOT* add ummunotify to OFED. The upstream kernel has
explicitly rejected it (at least for the moment). It adds a huge
maintenance and compatibility headache
I haven't installed any drivers on this system as my understanding was
that they are already included in the newer kernels, and although I
don't have a lot of linux knowledge, it does appear that mlx4_core is
running:
You also need to load mlx4_ib, either modprobe mlx4_ib or add a line
I'm trying to install OFED on Ubuntu 9.10 without much success. OFED
1.5 is failing with an error:
Why do you want to install OFED? Ubuntu 9.10 already has pretty
up-to-date IB/RDMA support included natively (eg aptitude install
libibverbs1 etc). What are you missing?
- R.
#define IB_USER_VERBS_MIN_ABI_VERSION 1
-#define IB_USER_VERBS_MAX_ABI_VERSION 6
+#define IB_USER_VERBS_MAX_ABI_VERSION 7
Whats this about? That seems like it needs a much bigger review,
changing the kernel ABI version instantly breaks every existing
libibverbs, shouldn't
This bug doesn't seem to ever have been present in the upstream
kernel -- what are you generating this patch against?
- R.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
When calling del_timer_sync on priv-poll_timer, it is necessary to prevent
farther arming of the timer which can be done by a completion handler. Though
it is harmless since the timer will eventually stop being rearmed, it is
better
practice to avoid calling the timer function after it
This bug doesn't seem to ever have been present in the upstream
kernel -- what are you generating this patch against?
I think it came from your for-next branch.
I don't see anything touching this code there. The patch that
introduced this code upstream, 521e575b (IB/mlx4: Add support
RFC 4291, Appendix A.
Thanks for the pointer. As far as I can tell from reading some IPv6
stuff, it really is broken to try to go from a link-local IPv6 address
back to a L2 ethernet address. For example, RFC 2464 (pointed to by RFC
4291) says:
Ethernet Address
The 48 bit
In any case, this is not a correctness issue that prohibits
experimentation with rdmaoe multicast on any network today.
I agree -- nothing prevents experimentation. I am just leery about
making invasive changes to the core stack in the absence of any
documented design for IBoE (that I've
How can 1500 lines out of 240k lines be a big change.. do I have these
numbers right - is the
big change you are referring too?
If there are significant changes to the core APIs -- and IBoE has
exactly this impact -- then yes it can be a big change even if the line
count is small.
What
WinOF has asynchronous interfaces for modify QP, and limited testing has
shown
that it can improve connection times. QP transitions are probably the second
largest component of connection setup after the SA. Since the RDMA CM
already
provides an asynchronous interface, even
Having lots of testing exposure can help in validating that all the
edge cases are handled..
To some extent -- but there also needs to be some thinking involved to
make sure that the interface can actually handle future cases.
Are there a set of cases that you have in mind ?
For example
+ *blh = unlikely(halign 64) ? 1 : 0;
This idiom of (boolean condition) ? 1 : 0 looks odd to me... doesn't
(halign 64) already evaluate to 1 or 0 anyway? Does the unlikely()
actually affect code generation here?
True, (halign 64) is the same and is cleaner. As for the
+*blh = unlikely(halign 64) ? 1 : 0;
This idiom of (boolean condition) ? 1 : 0 looks odd to me... doesn't
(halign 64) already evaluate to 1 or 0 anyway? Does the unlikely()
actually affect code generation here?
With that said, see below...
+int blh = 0;
I assume this
I have been testing rping with ipv6 address on OFED 1.5. I am seeing a
problem with ipv6 address resolution. rping is not always sending
neighbor solicitation out the correct interface. Running tcpdumps I
discovered that the neighbor solicitation is being sent out the first
interface
applied, thanks
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
this seems reasonable to me, applied, thanks.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Given that you seem to like the rest of the code and Jason hasn't spoken
up yet, I think we can have Roland merge this patch. Roland, what do you
think?
I don't see any problem with the idea and this does sound like a step
forward, so I am planning on merging this (pending review).
Thanks, applied with a few cleanups:
ilog2(roundup_pow_of_two()) - order_base_2()
xxx * (1 yy) - xxx yy
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
And I don't think the upstream kernel has that limit on kmalloc size
either (at least with SLUB, not sure about SLAB).
This patch was actually written as an emulation of the upstream SLUB
behavior, which is exactly the same thing: on large allocations
forward to __g_f_p(). See
This will fix the 2^20 bits limit on our bitmaps once and for all.
Not really... since getting 128KB of contiguous memory is likely to
fail anyway.
And I don't think the upstream kernel has that limit on kmalloc size
either (at least with SLUB, not sure about SLAB).
Really the long-term fix
looks good, applied
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
This patch installs the qib driver which replaces the ipath driver
in OFED-1.5.
Maybe I missed some discussion of this.
But what is the QIB driver? What are you planning to do to support
qlogic HCAs for the mainline kernel?
- R.
___
ewg mailing
applied...
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
thanks, applied.
-#define HCAD_VERSION 0026
+#define HCAD_VERSION 0027
the driver version was already 0027 (since bde2cfaf), so I dropped this chunk.
___
ewg mailing list
ewg@lists.openfabrics.org
on top of which trees would like me to rebase the patches on and update
the ABI version?
I guess you could base it on my xrc branch but as I said I'm not
planning on merging this until I'm done with the XRC stuff.
___
ewg mailing list
Hum, This is a very tricky subject. Co-mingling the IB GID address
space and the IPv6 address space like this is not really something
that was envisioned from the IBA side.
Doesn't the IB spec say that an IB GID *is* an IPv6 address? So in
theory it should be OK; however I don't think in
It is like an IPv6 address but it was expressly envisioned to be a
seperate space. The IBA authors copied many of the conventions from
IPv6 for numbering this new space, like link local, and multicast
prefixes, but it was not intended to be co-mingled.
Well (I've quoted this many times):
Hmm, murky indeed. Your point about IGMPv6 is well made. The problem
is that IB GRHs are not IPv6 headers and have different numerology for
the Next Header field. Ie in IPv6 Next Header 0x1B is RFC 908, while
in GRH it is a BTH. Labeling GRHs with an IPv6 ethertype is
fundamentally
Yeah, the notifier code remains untouched as we still do not allow dynamic
memory operations _while_ our module is loaded. The patch allows the driver
to
cope with DMEM operations that happened before the module was loaded, which
might result in a non-contiguous memory layout. When the
I think that in any case, OFA needs to have a consistent policy, and
if we allow something that is not a standard for one member, it
should be allowed for all members.
Agreed; I think that this is my central point -- thanks for saying it
succinctly! Regardless of whether OF asked
If I might chime in here...I've been working to actively squash the
expression 'IBoE' or any variation that includes IB in the name. The reason
is because the InfiniBand Architecture is defined as a cohesive solution
that includes five layers of the OSI stack. Hence using the expression
OK, one major issue with this patch and a few minor nits.
First, the major issue is that I don't see anything in the patch that
changes the code in ehca_mem_notifier() in ehca_main.c:
case MEM_GOING_ONLINE:
case MEM_GOING_OFFLINE:
/* only ok if no hca is attached
looks fine, applied for 2.6.31
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Sigh... unfortunate to add a tunable that people have to mess with
rather than just making things work automatically somehow. Anyway,
applied these.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
did you have a chance to take a look at the patchset and will you apply it,
or
are there any outstanding issues we need to address?
I guess it's OK, but definitely 2.6.31 material. I guess I'll stick it
linux-next soon.
- R.
___
ewg mailing
thanks, applied.
From: Anton Blanchard antonb at au1.ibm.com
Signed-off-by: Stefan Roscher stefan.roscher at de.ibm.com
please use '@' signs so these are real email addresses.
- R.
___
ewg mailing list
ewg@lists.openfabrics.org
thanks, applied 2 3.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Because of this fundamental code change we will also increment the version
number.
So this is 2.6.31-targeted stuff I assume? (Too late in the 2.6.30
cycle for fundamental code change of course)
- R.
___
ewg mailing list
+queue-queue_pages = kmalloc(nr_of_pages * sizeof(void *), GFP_KERNEL);
How big might this buffer be? Any chance of allocation failure due to
memory fragmentation?
- R.
___
ewg mailing list
ewg@lists.openfabrics.org
thanks, applied.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
I see... you're right - no need to stick the address into struct
ib_umem. Following this email is a new patch for mlx4_ib only. I
excluded support for both powerpc and ia64 since I could not find a
way to get HPAGE_SIZE (or HPAGE_SHIFT) for them.
#include asm/page.h ?
- R.
It does not help. The problem with powerpc is that HPAGE_SHIFT is an
unexported variable and for ia64 it's hpage_shift.
I see. hpage_shift is exported on ia64, so that should be OK. And I
guess for powerpc it is just a matter of adding an export so we can use
it in a module.
- R.
add address field to struct ib_umem so low level drivers will have this
information which may be needed in order to correctly calculate the number of
huge pages.
seems like a really strange thing to do:
+ umem-address = addr;
this value addr is coming from the low-level driver, so
+n = PAGE_ALIGN(umem-length + (umem-address ~HPAGE_MASK))
HPAGE_SHIFT;
This is still wrong I think. What if the user, say, registers 1MB that
is aligned exactly at a 2MB huge page start? Then wouldn't this
expression set n to 0? I think that PAGE_ALIGN() needs to be a
HPAGE_ALIGN(),
It is has to be saved either at the low level driver's mr object,
e.g. struct mlx4_ib_mr, or at a common place like struct ib_umem. Do
you prefer that it will be saved in struct mlx4_ib_mr?
I don't see why it has to be saved anywhere? The only place you use
umem-address is in
OK, looks better. However the patch had a bunch of whitespace problems
(run checkpatch.pl to see them). Also:
+static int handle_hugetlb_user_mr(struct ib_pd *pd, struct mlx4_ib_mr *mr,
+ u64 virt_addr, int access_flags)
+{
+#ifdef CONFIG_HUGETLB_PAGE
+
Since Linux does not merge adjacent pages into a single scatter entry through
calls to dma_map_sg(), we do this for huge pages which are guaranteed to be
comprised of adjacent natural pages of size PAGE_SIZE. This will result in a
significantly lower number of MTT segments used for
- I've added a print of the skb-data_len and skb-len sizes right
before the BUG_ON line.
skb-data_len was always 0, so I don't understand why there is a kernel
panic.
A race of two CPUs doing an skb_pull or something like that?
- R.
___
ewg
By the way, I don't seem to be able to reproduce this easily in my
setup. What kind of HCA/system are you using?
- R.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
We've discovered that sometimes we get a kernel panic while using
ipoib with lro enabled.
You can find all the details here:
https://bugs.openfabrics.org/show_bug.cgi?id=1473
This bug is reproduced both in kernel 2.6.27 and OFED 1.4.
I'll try to reproduce it myself, but in the
ipoib_mcast_free() dequeues SKBs pending on the pkt_queue but needs to do
that
with netif_tx_lock_bh() acquired.
I don't see why this would be required. When ipoib_mcast_free() runs,
the mcast structure has been removed from all lists and I don't see how
any other context could
The error message printed when the eHCA driver prevents memory hotplug is
misleading -- the user might think that hot-removing the lhca, hotplugging
memory, then hot-adding the lhca again will work, but it doesn't.
That's too bad... I applied this patch but out of curiousity, why
doesn't
Looks good... I'll add this for 2.6.29, since as far as I can tell this
bug has been there approximately forever already.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
1 - 100 of 217 matches
Mail list logo
