On Thu, Oct 06, 2005 at 02:14:08PM -0700, Grant Grundler wrote:
> On Thu, Oct 06, 2005 at 11:48:02AM -0600, Todd Bowman wrote:
> > /proc/cpuinfo on PPC64 prints different label for processor speed.
> ...
>
> ISTR the "clock" value in cpuinfo is NOT the same as the CPU MHz.
> Can you remind me if "
Matt wrote,
>Woody, are there plans to update the 2.6.9 backports to svn version
3632
>or more recent to fix this?
I just checked in new 2.6.9 backport patches for SVN rev. 3640 that
should
have this fix.
woody
___
openib-general mailing list
openib-g
On Thu, Oct 06, 2005 at 11:48:02AM -0600, Todd Bowman wrote:
> /proc/cpuinfo on PPC64 prints different label for processor speed.
...
ISTR the "clock" value in cpuinfo is NOT the same as the CPU MHz.
Can you remind me if "clock" value * "mtfb" results in
"wall clock" time units?
If not, then use
On Thu, 6 Oct 2005, Todd Bowman wrote:
> This patch in addition to "PPC64 cpuinfo change" provides udapl support on
> PPC64 platform.
>
> Added PPC64 dependent code to dapl_os_atomic_inc, dapl_os_atomic_dec,
> dapl_os_atomic_assign and DT_Mdep_GetTimeStamp.
> Also added PPC64 to platform checks
On Thu, 6 Oct 2005, Todd Bowman wrote:
twbowm> This patch in addition to "PPC64 atomic function additions" provides
udapl
twbowm> support on PPC64 platform.
twbowm>
twbowm> /proc/cpuinfo on PPC64 prints different label for processor speed.
Committed in revision 3687.
_
Roland,
* On Oct,13 Roland Dreier<[EMAIL PROTECTED]> wrote :
> Sayantan> I noticed that the test re-posts buffers only when the
> Sayantan> outstanding recv count is <= 1. I set a SRQ limit as
> Sayantan> max_recv - 5. So, I should get the event when 5 WQEs are
> Sayantan> consumed
Sayantan> I noticed that the test re-posts buffers only when the
Sayantan> outstanding recv count is <= 1. I set a SRQ limit as
Sayantan> max_recv - 5. So, I should get the event when 5 WQEs are
Sayantan> consumed from the SRQ, right?
Yes, your code is correct. The problem was tha
Roland Dreier wrote:
Sean> Hello, Will openib still supply patches to the 2.6.13 Kernel
Sean> or do I need to upgrade my kernel to 2.6.14?
2.6.14 is not out yet, so the OpenIB subversion repository continues
to be targeted at 2.6.13 (the latest full kernel release). Once
2.6.14 is releas
Sean> Hello, Will openib still supply patches to the 2.6.13 Kernel
Sean> or do I need to upgrade my kernel to 2.6.14?
2.6.14 is not out yet, so the OpenIB subversion repository continues
to be targeted at 2.6.13 (the latest full kernel release). Once
2.6.14 is released, we'll target that
Hello,
Will openib still supply patches to the 2.6.13 Kernel or do I need to
upgrade my kernel to 2.6.14?
Thanks,
Sean Hubbell
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscri
Hal Rosenstock wrote:
What stops the net_device from being pulled from underneath this ? Seems
like a similar issue to me. The difference I see is that only
net_devices need to be tracked rather than perhaps net_devices and
ib_devices.
A reference on the net_device needs to be held while this i
On Thu, 2005-10-06 at 15:20, Nishanth Aravamudan wrote:
> On 06.10.2005 [13:25:35 -0400], Hal Rosenstock wrote:
> > On Thu, 2005-10-06 at 13:11, Nishanth Aravamudan wrote:
> > > On 06.10.2005 [19:40:40 +0300], Dan Bar Dov wrote:
> > > > I've fixed the 2.6.14-rc3 compilation warnings with iSER on x8
On Thu, 2005-10-06 at 15:08, Sean Hefty wrote:
> Roland Dreier wrote:
> > Sean> Is it possible to retrieve the pkey using
> > Sean> net_device->class_dev?
> >
> > Maybe, but even more direct would be taking it from net_device->broadcast.
>
> Okay - this is starting to make more sense to m
On 06.10.2005 [13:25:35 -0400], Hal Rosenstock wrote:
> On Thu, 2005-10-06 at 13:11, Nishanth Aravamudan wrote:
> > On 06.10.2005 [19:40:40 +0300], Dan Bar Dov wrote:
> > > I've fixed the 2.6.14-rc3 compilation warnings with iSER on x86 in
> > > version 3682.
> >
> > Great! Thanks.
> >
> > I'm r
Hal Rosenstock wrote:
The CMA maintains a list of devices. The address translation code takes an IP
address and returns the corresponding GID. The CMA looks up the GID against its
list of devices. All synchronization for device removal is handled by the CMA.
The only way I see is that a use
Roland Dreier wrote:
Sean> Is it possible to retrieve the pkey using
Sean> net_device->class_dev?
Maybe, but even more direct would be taking it from net_device->broadcast.
Okay - this is starting to make more sense to me now:
priv->dev->broadcast[8] = priv->pkey >> 8;
On Thu, 2005-10-06 at 13:01, Sean Hefty wrote:
> Hal Rosenstock wrote:
> >>I didn't see any other way to retrieve the pkey associated with an IP
> >>address
> >>without this.
> >
> > Yes, and I looked at getting the ib_device but there is no easy way so I
> > added them into the structure return
Sean> Is it possible to retrieve the pkey using
Sean> net_device->class_dev?
Maybe, but even more direct would be taking it from net_device->broadcast.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/lis
On Thu, 2005-10-06 at 13:50, Sean Hefty wrote:
> Roland Dreier wrote:
> > Did we ever figure out how to handle the hotplug issues with the
> > lifetime of the struct ib_device pointer? Right now this API is
> > unsafe, because a caller can get a pointer to a device that has
> > already disappeared
Roland,
* On Oct,11 Sayantan Sur<[EMAIL PROTECTED]> wrote :
> I will test out the limit event generation next.
I made some simple modifications to srq_pingpong.c to see if I am able
to generate the IBV_EVENT_SRQ_LIMIT_REACHED event. I have attached my
changes as a patch and the full file (for eas
On 06.10.2005 [13:25:35 -0400], Hal Rosenstock wrote:
> On Thu, 2005-10-06 at 13:11, Nishanth Aravamudan wrote:
> > On 06.10.2005 [19:40:40 +0300], Dan Bar Dov wrote:
> > > I've fixed the 2.6.14-rc3 compilation warnings with iSER on x86 in
> > > version 3682.
> >
> > Great! Thanks.
> >
> > I'm r
Jeff> When I pulled this yesterday, it didn't compile
Jeff> uverbs_main.c. It looks like it's missing from
Jeff> include/rdma/ib_user_verbs.h
Jeff> I'm wondering if I pulled your tree/branch correctly. Can
Jeff> you confirm these would be the right instructions?
Looks reasonab
Roland Dreier wrote:
Did we ever figure out how to handle the hotplug issues with the
lifetime of the struct ib_device pointer? Right now this API is
unsafe, because a caller can get a pointer to a device that has
already disappeared.
Is it possible to retrieve the pkey using net_device->class
This patch in addition to "PPC64 cpuinfo change" provides udapl support on PPC64 platform.
Added PPC64 dependent code to dapl_os_atomic_inc, dapl_os_atomic_dec, dapl_os_atomic_assign and DT_Mdep_GetTimeStamp.
Also added PPC64 to platform checks.
Signed-off-by: Todd Bowman <[EMAIL PROTECTED]>
Ind
This patch in addition to "PPC64 atomic function additions" provides udapl support on PPC64 platform.
/proc/cpuinfo on PPC64 prints different label for processor speed.
Signed-off-by: Todd Bowman <[EMAIL PROTECTED]>
Index: userspace/dapl/test/dapltest/mdep/linux/dapl_mdep_user.c
On Thu, 2005-10-06 at 13:11, Nishanth Aravamudan wrote:
> On 06.10.2005 [19:40:40 +0300], Dan Bar Dov wrote:
> > I've fixed the 2.6.14-rc3 compilation warnings with iSER on x86 in version
> > 3682.
>
> Great! Thanks.
>
> I'm re-running the tests (due to a subtle flaw in my PATH, my cronjobs
> we
On 09/27/2005 09:01 PM, Roland Dreier wrote:
> Linus, please pull from
>
> master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
> for-linus
>
> This tree is also available from kernel.org mirrors at:
>
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.gi
On 06.10.2005 [19:40:40 +0300], Dan Bar Dov wrote:
> I've fixed the 2.6.14-rc3 compilation warnings with iSER on x86 in version
> 3682.
Great! Thanks.
I'm re-running the tests (due to a subtle flaw in my PATH, my cronjobs
weren't running) now and will post the latest results.
Thanks,
Nish
_
Hal Rosenstock wrote:
I didn't see any other way to retrieve the pkey associated with an IP address
without this.
Yes, and I looked at getting the ib_device but there is no easy way so I
added them into the structure returned. Is CMA keeping a list of
ib_devices that it walks for this ?
The C
Did we ever figure out how to handle the hotplug issues with the
lifetime of the struct ib_device pointer? Right now this API is
unsafe, because a caller can get a pointer to a device that has
already disappeared.
Also if we do decide to add an API like this, the struct ipoib_info
and ipoib_get_i
On Thu, 2005-10-06 at 12:34, Sean Hefty wrote:
> Hal Rosenstock wrote:
> > IPoIB: Add API to retrieve ib device, port, and pkey
> >
> > (I'm also attaching my patch to at.c which uses this; If this is
> > accepted, I will make up a patch for SDP as well.)
>
> I didn't see any other way to retriev
I've fixed the 2.6.14-rc3 compilation warnings with iSER on x86 in version 3682.
Dan
On 10/4/05, Nishanth Aravamudan <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Here are the build results for 2.6.14-rc3 with and without the latest
> gen2 trunk.
>
> Looks like all the builds were successful, with some
Hal Rosenstock wrote:
IPoIB: Add API to retrieve ib device, port, and pkey
(I'm also attaching my patch to at.c which uses this; If this is
accepted, I will make up a patch for SDP as well.)
I didn't see any other way to retrieve the pkey associated with an IP address
without this.
For SDP,
IPoIB: Add API to retrieve ib device, port, and pkey
(I'm also attaching my patch to at.c which uses this; If this is
accepted, I will make up a patch for SDP as well.)
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: ipoib.h
==
On Thu, 6 Oct 2005, Todd Bowman wrote:
> Here is a patch for dtest.c to remove the qualifier from the sdp range.
Thanks. Committed revision in 3683.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-gen
On Thu, 2005-10-06 at 10:28, Roland Dreier wrote:
> Hal> IPoIB: Backoff on send only joins as well (as full member
> Hal> ones) (This was part of the original patch but somehow
> Hal> doesn't appear to have made it in).
>
> I left this part out intentionally because I don't see how it
Hal> IPoIB: Backoff on send only joins as well (as full member
Hal> ones) (This was part of the original patch but somehow
Hal> doesn't appear to have made it in).
I left this part out intentionally because I don't see how it makes a
difference. Maybe I'm missing something, but where
On 10/5/05, James Lentini <[EMAIL PROTECTED]> wrote:
On Wed, 5 Oct 2005, Todd Bowman wrote:> Here is a patch for dtest.c to remove the qualifier from the sdp range.>> Index: userspace/dapl/test/dtest/dtest.c> ===
> --- userspace/dapl/t
* On Oct,10 Roland Dreier<[EMAIL PROTECTED]> wrote :
> Sayantan> I am getting a segmentation fault after a couple of
> Sayantan> thousand messages are sent over SRQ (using ping-pong
> Sayantan> latency test). Here is a snippet from the core
> Sayantan> generated.
>
> Is it possible
IPoIB: Backoff on send only joins as well (as full member ones)
(This was part of the original patch but somehow doesn't appear to have
made it in).
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: ipoib_multicast.c
===
---
On Wed, 2005-10-05 at 17:25, Roland Dreier wrote:
> It seems that there is a bug in ib_mad_init_device(): if
> ib_agent_port_open() fails for a given port, then the current code
> doesn't call ib_mad_port_close() for that port. I think something
> like the patch below is needed.
Yup, it missed ca
On Thu, 2005-10-06 at 08:14, Heiko J Schick wrote:
> Hello,
>
> during (some) test with libibat I found out that the example programs
> include a little/big endian problem.
> Below you will find the patch for ats.c and att.c which will solve
> this problem on PPC64:
>
> Signed-off-by: Heiko Joerg
Hello,
during (some) test with libibat I found
out that the example programs include a little/big endian problem.
Below you will find the patch for ats.c
and att.c which will solve this problem on PPC64:
Signed-off-by: Heiko Joerg Schick <[EMAIL PROTECTED]>
--- /home/source/trunk_3615_orig/src/
Quoting Sean Hubbell <[EMAIL PROTECTED]>:
> Michael,
>
> Would you like me to add autogen.sh and configure scripts to build
> mstflint? The reason is that to compile this on my system (Dell
> PowerEdge 2850 (2) 3.2 GHz running cAos 2.0 (with Patches) is not
> resolving some of the require inclu
44 matches
Mail list logo
