On Thu, 08 Apr 2010 16:29:06 -0700
Roland Dreier wrote:
> > I for one would rather not see this die. We have debugged some critical
> > issues using this data. The sysfs entries above are what Mellanox uses.
> > Should those also be changed?
>
> Which sysfs entries? I don't see any likely
On Thu, 2010-04-08 at 16:29 -0700, Roland Dreier wrote:
> > I for one would rather not see this die. We have debugged some critical
> > issues using this data. The sysfs entries above are what Mellanox uses.
> > Should those also be changed?
>
> Which sysfs entries? I don't see any likely loo
On Thu, 2010-04-08 at 13:49 -0700, Roland Dreier wrote:
> Rather than have the device driver call a new function that then calls
> it back, how about if we just add a parameter to the
> ib_register_device() call that is the callback to add the sysfs stuff?
> This would let us avoid the race where t
> I for one would rather not see this die. We have debugged some critical
> issues using this data. The sysfs entries above are what Mellanox uses.
> Should those also be changed?
Which sysfs entries? I don't see any likely looking code in either of
the Mellanox drivers.
- R.
--
Roland D
On Thu, 2010-04-08 at 15:50 -0700, Jason Gunthorpe wrote:
> On Thu, Apr 08, 2010 at 03:26:41PM -0700, Ralph Campbell wrote:
> > On Thu, 2010-04-08 at 15:08 -0700, Jason Gunthorpe wrote:
> > > On Thu, Apr 08, 2010 at 02:29:53PM -0700, Ralph Campbell wrote:
> > >
> > > > One other place that has mul
On Thu, Apr 08, 2010 at 03:26:41PM -0700, Ralph Campbell wrote:
> On Thu, 2010-04-08 at 15:08 -0700, Jason Gunthorpe wrote:
> > On Thu, Apr 08, 2010 at 02:29:53PM -0700, Ralph Campbell wrote:
> >
> > > One other place that has multiple values is dumping the QSFP
> > > data from the IB cable.
> >
On Thu, 2010-04-08 at 15:08 -0700, Jason Gunthorpe wrote:
> On Thu, Apr 08, 2010 at 02:29:53PM -0700, Ralph Campbell wrote:
>
> > One other place that has multiple values is dumping the QSFP
> > data from the IB cable.
>
> I was going to comment that building your own I2C subsystem is kinda
> str
On Thu, 08 Apr 2010 14:33:59 -0700
Roland Dreier wrote:
> > This was for debugging and clearly could use a better method.
> > Some stats are definitely useful and having files per value
> > would make scripting easier too.
> > I could add /sys/class/infiniband/qib0/ports/1/diag_counters/*
>
On Thu, Apr 08, 2010 at 02:29:53PM -0700, Ralph Campbell wrote:
> One other place that has multiple values is dumping the QSFP
> data from the IB cable.
I was going to comment that building your own I2C subsystem is kinda
strange, can't the in-kernel stuff be used?
Jason
--
To unsubscribe from t
> This was for debugging and clearly could use a better method.
> Some stats are definitely useful and having files per value
> would make scripting easier too.
> I could add /sys/class/infiniband/qib0/ports/1/diag_counters/*
>
> One other place that has multiple values is dumping the QSFP
This was for debugging and clearly could use a better method.
Some stats are definitely useful and having files per value
would make scripting easier too.
I could add /sys/class/infiniband/qib0/ports/1/diag_counters/*
One other place that has multiple values is dumping the QSFP
data from the IB ca
> Rather than have the device driver call a new function that then calls
> it back, how about if we just add a parameter to the
> ib_register_device() call that is the callback to add the sysfs stuff?
> This would let us avoid the race where the device is registered but not
> all the sysfs stu
I didn't audit everything (so there may be more problems here too), but
certainly this violates the "one value per sysfs file" rule rather
egregiously:
> +static ssize_t show_stats(struct device *device, struct device_attribute
> *attr,
> + char *buf)
> +{
> +struct
Rather than have the device driver call a new function that then calls
it back, how about if we just add a parameter to the
ib_register_device() call that is the callback to add the sysfs stuff?
This would let us avoid the race where the device is registered but not
all the sysfs stuff is created y
OK. This will be in v3.
On Wed, 2010-03-31 at 16:18 -0700, Roland Dreier wrote:
> > +struct ib_dma_mapping_ops qib_dma_mapping_ops = {
> > + qib_mapping_error,
> > + qib_dma_map_single,
> > + qib_dma_unmap_single,
> > + qib_dma_map_page,
> > + qib_dma_unmap_page,
> > + qib_map_sg,
> >
Hi Yevgeny,
When will this be targeted for mainline?
I'm working on using multiple vectors, and it would be great to see it
there, since I need to work against both OFED and mainline. Otherwise I
need to have my ulp do round robin assignment up to
caps.num_comp_vectors, I guess? VECTOR_LEAST_ATTA
>Maybe use calloc(,1 sizeof(x)); instead?
yes - I'll update the patches, but won't repost for this change.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.h
> It would be great if someone could explain the impact of this issue --
> the impact is not yet clear to me.
Um, it's a one-line patch -- pretty clear if the allocation fails then
we check the wrong value and probably crash.
--
Roland Dreier || For corporate legal information go to:
http://ww
On Thu, Apr 8, 2010 at 4:46 PM, Roland Dreier wrote:
>
> > Have you already had the time to check whether this fix should be
> > backported to already released kernels, and if so, to which kernel
> > versions ? The easiest way to ask for backporting is to add "Cc:
> > " in a patch.
>
> It back
> Have you already had the time to check whether this fix should be
> backported to already released kernels, and if so, to which kernel
> versions ? The easiest way to ask for backporting is to add "Cc:
> " in a patch.
It backports but I don't see it as fixing a big enough problem to be
worth
Added command line argument to dump PathRecord
file and updated the man page.
Signed-off-by: Yevgeny Kliteynik
---
opensm/man/opensm.8.in |8 +++-
opensm/opensm/main.c |9 +
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/opensm/man/opensm.8.in b/opensm/man
Signed-off-by: Yevgeny Kliteynik
---
opensm/opensm/osm_dump.c |3 +++
opensm/opensm/osm_state_mgr.c |2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/opensm/opensm/osm_dump.c b/opensm/opensm/osm_dump.c
index 86e9c00..cedff24 100644
--- a/opensm/opensm/osm_dump.c
Signed-off-by: Yevgeny Kliteynik
---
opensm/include/opensm/osm_subnet.h | 10 ++
opensm/opensm/osm_subnet.c | 14 ++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/opensm/include/opensm/osm_subnet.h
b/opensm/include/opensm/osm_subnet.h
index 3970
Dumping SL, MTU and Rate for all the
non-switch-2-non-switch paths in the subnet.
PRs that are dumped:
for every non-switch source port
for every non-switch target LID in the subnet
dump PR between source port and target LID
This way number of sources is equal to number of phy
Hi Sasha,
One of the major bottlenecks of the OpenSM is handling
SA queries storm. In order to allow all-2-all communication,
SA must process N^2 PathRecord queries.
On large clusters this takes way too much time.
Currently, most of the MPI implementations do not query SA
at all in order to avoid
Hi Sasha,
Small patch that enhances opensm_dump_to_file() function
and allows it to accept full path file names as argument.
Signed-off-by: Yevgeny Kliteynik
---
opensm/opensm/osm_sa.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/opensm/opensm/osm_sa.c b/open
On Wed, Apr 7, 2010 at 11:39 AM, Dan Carpenter wrote:
> The intent here was to check the "mfrpl->mapped_page_list" allocation.
> We checked "mfrpl->ibfrpl.page_list" earlier.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/infiniband/hw/mlx4/mr.c b/drivers/infiniband/hw/mlx4/mr.c
> inde
Call just once all these sed/awk/cut etc. when finding mac addresses.
From 2437e980e6a8f0bcd123ddab077f00908069d379 Mon Sep 17 00:00:00 2001
From: Aleksey Senin
Date: Thu, 8 Apr 2010 11:53:07 +0300
Subject: [PATCH] Optimized when looking ethernet data.
I have two adapters with two ports on each o
28 matches
Mail list logo
