On Sun, Aug 27, 2006 at 06:41:08PM -0700, Robert Walsh wrote:
> Roland Dreier wrote:
> > Michael> Looks like your devices are all single-port. With a multi
> > Michael> port device it is quite common to have one port down.
> >
> > My reading of the patch is that it warns if the link is up
On Sun, Aug 27, 2006 at 03:30:56PM -0700, Roland Dreier wrote:
> glebn> So, before touching the data that was RDMAed into the
> glebn> buffer application should cache invalidate the buffer, is
> glebn> this even possible from user space? (Not on x86, but it
> glebn> isn't needed the
Roland Dreier wrote:
> Michael> Looks like your devices are all single-port. With a multi
> Michael> port device it is quite common to have one port down.
>
> My reading of the patch is that it warns if the link is up physically
> but does not come up logically. Which would still be reaso
glebn> So, before touching the data that was RDMAed into the
glebn> buffer application should cache invalidate the buffer, is
glebn> this even possible from user space? (Not on x86, but it
glebn> isn't needed there.)
Yes, on any architecture that is not cache-coherent with PCI DMA,
On Sun, 2006-08-20 at 20:18 +0300, Sasha Khapyorsky wrote:
> On 13:01 Sun 20 Aug , Hal Rosenstock wrote:
> > Hi Sasha,
> >
> > On Sun, 2006-08-20 at 12:05, Sasha Khapyorsky wrote:
> > > In case when OpenSM log file overflows filesystem and write() fails with
> > > 'No space left on device' try
Michael> Looks like your devices are all single-port. With a multi
Michael> port device it is quite common to have one port down.
My reading of the patch is that it warns if the link is up physically
but does not come up logically. Which would still be reasonable for a
multi-port device.
Robert> The command size passed to ibv_cmd_create_cq is the size
Robert> of the mthca command wrapper which is larger than what is
Robert> most likely expected.
No, that is the whole point of passing the size into that function: it
lets low-level drivers pass extra device-specific data
Title: MasterCard SecureCode - Introduction
Dear valued MasterCard customer,MasterCard is proud to announce the new online safe shopping solution, the MasterCard SecureCode program. This service is totally free, and it will keep you safe and secure, and protect you from unauthorized p
Quoting r. Doug Ledford <[EMAIL PROTECTED]>:
> Subject: Re: [openfabrics-ewg] OFED 1.1-rc2 is ready
>
> On Sun, 2006-08-27 at 20:59 +0300, Michael S. Tsirkin wrote:
>
> > I get the idea now, but that's exactly what we tried to do.
> > I went over the patches, and here's what I found:
>
> Great.
On Sun, 2006-08-27 at 20:59 +0300, Michael S. Tsirkin wrote:
> I get the idea now, but that's exactly what we tried to do.
> I went over the patches, and here's what I found:
Great. I don't have the u4 patches you guys have made, so I didn't see
that you had taken those things out (I've been goi
Quoting r. Doug Ledford <[EMAIL PROTECTED]>:
> Subject: Re: [openfabrics-ewg] OFED 1.1-rc2 is ready
>
> On Sat, 2006-08-26 at 22:42 +0300, Michael S. Tsirkin wrote:
> > Quoting r. Doug Ledford <[EMAIL PROTECTED]>:
> > > IOW, make use of the infrastructure
> > > provided in U4 instead of working ar
On Sat, 2006-08-26 at 22:24 +0300, Michael S. Tsirkin wrote:
> This looks much better than the monolitic patch that sits in the ofed fixes
> directory. Does this cover all the fixes there, and if so can
> it be replaced with this?
I'll check on Monday. I have a split-up series of backport patche
Quoting r. Doug Ledford <[EMAIL PROTECTED]>:
> Subject: Re: [openfabrics-ewg] OFED 1.1-rc2 is ready
>
> On Sat, 2006-08-26 at 22:42 +0300, Michael S. Tsirkin wrote:
> > Quoting r. Doug Ledford <[EMAIL PROTECTED]>:
> > > IOW, make use of the infrastructure
> > > provided in U4 instead of working ar
On Sun, 2006-08-27 at 17:31 +0300, Tziporet Koren wrote:
>
> Doug Ledford wrote:
>
> >
> > Not supporting ppc is a problem to a certain extent. I can't speak for
> > SuSE, but at least for Red Hat, ppc is the default and over rides ppc64.
> > The ppc64 arch is less efficient than the ppc arch o
Hi Hal.
This is a resubmission of the patch that addresses
the comments that I got on the first version - using
osm-log.conf file instead of opensmlog.conf and osm
man page update.
Yevgeny
Signed-off-by: Yevgeny Kliteynik <[EMAIL PROTECTED]>
Index: include/opensm/osm_subnet.h
==
On Sat, 2006-08-26 at 22:42 +0300, Michael S. Tsirkin wrote:
> Quoting r. Doug Ledford <[EMAIL PROTECTED]>:
> > IOW, make use of the infrastructure
> > provided in U4 instead of working around it.
>
> Sorry, I don't really understand what you suggest here.
> Could you give us an example please?
S
Doug Ledford wrote:
>
> Not supporting ppc is a problem to a certain extent. I can't speak for
> SuSE, but at least for Red Hat, ppc is the default and over rides ppc64.
> The ppc64 arch is less efficient than the ppc arch on ppc64 processors
> except when large memory footprints are involved.
Hi Hal.
> > By default, the OSM will use the following file: /etc/opensmlog.conf
>
> Nit: For consistency in naming, this would be better as osmlog.conf
> (or
> osm-log.conf) rather than opensmlog.conf
Right - will use osm-log.conf
> Rather than remove osm_log and osm_log_raw, these should be
Hi Hal
This patch just makes the error message more informative for user,
since another instance of running SM is most probably the reason
why osm_opensm_bind failed.
Yevgeny
Signed-off-by: Yevgeny Kliteynik <[EMAIL PROTECTED]>
Index: opensm/main.c
=
19 matches
Mail list logo
