Jason Gunthorpe wrote:
> Has anyone been able to use ipath with the current latest git
> everything?
We're working on getting this up to date right now. Give us a couple of
days and we'll have some new patches ready.
Regards,
Robert.
___
openib-gen
Roland Dreier wrote:
> > Indeed, it makes much sense, do you any idea what would it take to
> > expose this capability also by libibverbs?
>
> I think the biggest problem would be libipathverbs, which is copying
> work completion structures directly out of the kernel (which looks
> pretty fragil
Robert Walsh wrote:
> Roland Dreier wrote:
>> > Is there are registration authority for multicast GIDs? Or at
>> least a > safe way of assigning a range of GIDs to a vendor?
>>
>> I don't think so. Perhaps RFC 3307 would be of some use...
>
> Ah
Roland Dreier wrote:
> > Is there are registration authority for multicast GIDs? Or at least a
> > safe way of assigning a range of GIDs to a vendor?
>
> I don't think so. Perhaps RFC 3307 would be of some use...
Ah - looks exactly like what I was looking for. Thanks.
_
Hi all,
Is there are registration authority for multicast GIDs? Or at least a
safe way of assigning a range of GIDs to a vendor?
Regards,
Robert.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-ge
Michael Ellerman wrote:
> Hi,
>
> Just a heads-up, drivers/infiniband/hw/ipath/ipath_keys.c doesn't build
> on powerpc because we have don't have bus_to_virt().
>
> (Actually you can't select CONFIG_INFINIBAND_IPATH on mainline because
> powerpc doesn't enable PCI_MSI, but we will real soon now,
> Of note is that both ipath and ipoib modules required minor tweaks to
> work with the inode-diet patch set which could effect their operation (I
> suspect the patch is correct, but haven't tested it).
Can you send a patch for this, please?
___
openib-
QLogic have tests OFED 1.1pre1 and are happy with the results. We have
tests UD, UC, RC, IPoIB, SDP and uDAPL.
Regards,
Robert.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscri
Steve Smaldone wrote:
> Hi,
>
> I have been trying to run dapltest with trunk rev 9717 with linux kernel
> 2.6.18 and I get an error. The error and configuration is shown below.
> Basically, the rdma_cm device is not created under /dev/infiniband. I
> am wondering if this is a known problem an
Hi all,
I've a question about one of the gen2_basic tests. The test is test 3
of the QP test collection. There's a piece of code in this test that
does a modify_qp, followed by a query_qp. The query QP bit checks that
the modify_qp did what was expected of it. One check looks like this:
only
Don't attempt to set up the diagpkt device in the module init code.
Instead, wait until a piece of hardware is initted. Fixes a problem
when loading the ib_ipath module when no InfiniPath hardware is present:
modprobe would go into the D state and stay there.
Signed-off-by: Rober
Roland Dreier wrote:
> Robert> This was without the patch, though, right? Cause if
> Robert> you've applied the patch and you're still getting this
> Robert> message, I'm confused.
>
> Yes, I was trying to debug the root cause of the problem, so I was
> just running the mainline kerne
> Sigh. Yeah. Code go boom. I'll roll it again. We had been ignoring
> the failure anyway before this patch. I'll just make sure we do a
> dev_warn and atomic_dec if ipath_cdev_init fails.
Scrub that - I'm going to roll all this into ipath_diag_add and make it
all a bit simpler. I'll send
Roland Dreier wrote:
> I tried loading ib_ipath on one of my systems without an ipath device,
> and I got the message
>
> ib_ipath: Could not create class_dev for minor 127, ipath_diagpkt (err 19)
>
> but I couldn't reproduce the hang of modprobe.
This was without the patch, though, right?
t attempt to set up the diagpkt device in the module init code.
Instead, wait until a piece of hardware is initted. Fixes a problem
when loading the ib_ipath module when no InfiniPath hardware is present:
modprobe would go into the D state and stay there.
Signed-off-by: Robert Walsh <[EMAIL PROTECT
Roland Dreier wrote:
> Robert> Well, it needs to be refcounted, as we need to create it
> Robert> on first add_one and remove it on the last remove_one. If
> Robert> I put a spinlock around it, would that suffice?
>
> Yes, that should be fine, although I assume you'll need to set a fl
> This seems dangerous, especially now that we have PCI_MULTITHREAD_PROBE:
> nothing prevents ipath_cdev_init() from being called twice. Better to
> use something like test_and_set_bit() to make sure this is done
> exactly once.
Well, it needs to be refcounted, as we need to create it on first
ad
Michael S. Tsirkin wrote:
> Quoting r. Robert Walsh <[EMAIL PROTECTED]>:
>> Subject: Re: [openfabrics-ewg] OFED Status
>>
>> The attached patch fixes this problem by deferring creation of our
>> diagpkt device until at least one piece of hardware has been found.
The attached patch fixes this problem by deferring creation of our
diagpkt device until at least one piece of hardware has been found.
Michael: this will fix the OFED testing problem you were seeing.
Roland: please queue for 2.6.19.
Regards,
Robert.
Robert Walsh wrote:
> The attached patch fixes this problem by deferring creation of our
> diagpkt device until at least one piece of hardware has been found.
Of course, if I'd actually attached the patch, it might have been a bit
more useful :-)
IB/ipath - initialize diagpkt file on
Thierry Delaitre wrote:
> I get the following when loading lustre o2ib module. I'm using ofed-1.1
> rc6 on sles10 and i'm sure the ib modules are the ones recompiled for the
> kernel i'm using and lustre too. I don't understand why i get the
> following as i only have one version of the ib modules
> All the rest of the attributes (for example: is_global) are being set
> with 0.
Oh, OK - I wasn't sure that you wanted it set that way or randomly like
it used to be. No biggie.
Regards,
Robert.
___
openib-general mailing list
openib-general@ope
gen2_basic - handle other vendor devices for max QP count
When choosing the actual max QP number, handle non-Mellanox devices too.
Make sure we only clean up the QPs we actually created.
Signed-off by: Robert Walsh <[EMAIL PROTECTED]>
diff -rNu a/gen2_basic/test_qp.c b/gen2_basic/tes
gen2_basic - fix static_rate check
Make sure we're comparing apples to apples in the static_rate check.
Signed-off by: Robert Walsh <[EMAIL PROTECTED]>
diff -rNu a/gen2_basic/test_qp.c b/gen2_basic/test_qp.c
--- a/gen2_basic/test_qp.c 2006-09-13 19:17:17.835923000 -0700
+++ b
gen2_basic - handle auto path migration properly
Signed-off by: Robert Walsh <[EMAIL PROTECTED]>
diff -rNu a/gen2_basic/test_qp.c b/gen2_basic/test_qp.c
--- a/gen2_basic/test_qp.c 2006-09-13 19:15:59.829006000 -0700
+++ b/gen2_basic/test_qp.c 2006-08-14 14:16:57.911621000
gen2_basic - choose illegal max_qp_init_rd_atom values correctly
Signed-off by: Robert Walsh <[EMAIL PROTECTED]>
diff -rNu a/gen2_basic/test_qp.c b/gen2_basic/test_qp.c
--- a/gen2_basic/test_qp.c 2006-09-13 19:09:47.419791000 -0700
+++ b/gen2_basic/test_qp.c 2006-08-14
Another quick question: I noticed that in the latest changes your
pushed, including my patches, you removed the following check in test_qp.c:
@@ -1702,7 +1700,6 @@
CHECK_VALUE("qp_type", query_init_attr.qp_type,
attr.qp_type, goto cleanup);
CHECK_VALUE_PTR("recv_cq"
Hi Dotan,
I just noticed that you didn't apply one of my patch hunks that called
get_is_global(). I know why you didn't do it (the dlid is always 0: see
line 218 of test_av.c), but should you still be setting the is_global
field in the ah_attr structure to some value? Right now, it will just
be
Dotan Barak wrote:
> Dotan Barak wrote:
>> Robert Walsh wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Hi all,
>>>
>>> We've got some patches to gen2_basic to fix some problems with the tes
> Its easy to get linux running on a switch, so why not? You just
> need to write a low level driver that cn send/receve MADs.
> We did run a gen1 port on a switch at some point, and someone might want to
> do it again.
OK - that's a fine project idea, but I'm not about to start coding it up
any
Hal Rosenstock wrote:
> On Tue, 2006-09-19 at 20:28, Robert Walsh wrote:
>> gen2_basic - select a valid port number
>>
>> Port numbers start at 1, not 0.
>
> True for CA and routers but not switches.
Yeah. Does anyone run gen2_basic on switches, though? I assumed i
gen2_basic - handle case where max_sge > 100
When choosing an illegal number of maximum SGEs, handle the case where
the device allows more than 100 SGEs.
Signed-off by: Robert Walsh <[EMAIL PROTECTED]>
diff -rNu a/gen2_basic/test_poll_post.c b/gen2_basic/test_poll_post.c
--- a/g
gen2_basic - select a valid port number
Port numbers start at 1, not 0.
Signed-off by: Robert Walsh <[EMAIL PROTECTED]>
diff -rNu a/gen2_basic/test_poll_post.c b/gen2_basic/test_poll_post.c
--- a/gen2_basic/test_poll_post.c 2006-09-13 19:09:47.410808000 -0700
+++ b/gen2
gen2_basic - make sure the DLID is valid
For valid address handles, make sure the DLID is not a multicast LID.
You can't modify a QP to use a multicast DLID using ib_modify_qp().
Signed-off by: Robert Walsh <[EMAIL PROTECTED]>
diff -rNu a/gen2_basic/test_cq.c b/gen2_basic/test
gen2_basic - fix is_global settings for AH attributes
For valid address handles, the is_global field of the AH attribute should
not be a random number if the dlid is a multicast LID.
Signed-off by: Robert Walsh <[EMAIL PROTECTED]>
diff -rNu a/gen2_basic/main.h b/gen2_basic/main.h
gen2_basic - fix up some compiler warnings
Create a new CHECK_PVALUE macro for checking pointers and use it where
appropriate. This makes a bunch of compiler printf warnings go away.
Signed-off by: Robert Walsh <[EMAIL PROTECTED]>
diff -rNu a/gen2_basic/test_cq.c b/gen2_basic/test_cq.c
gen2_basic - fix some minor typos
Signed-off by: Robert Walsh <[EMAIL PROTECTED]>
diff -rNu a/gen2_basic/test_cq.c b/gen2_basic/test_cq.c
--- a/gen2_basic/test_cq.c 2006-07-27 13:42:44.857603000 -0700
+++ b/gen2_basic/test_cq.c 2006-08-14 14:17:17.352167000 -0700
@@ -1,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
We've got some patches to gen2_basic to fix some problems with the test
suite. Some are trivial (fix typos, etc.) and some are more serious
(handle max_qp counts correctly, etc.) I'm going to be sending them out
piecemeal as we review them i
> Changes are expected to be tested before you commit.
> This is really maintainer's responsibility, please take it seriously.
I have to take exception here. It's only possible for us to make a
serious attempt at doing something like this if OFED takes a more
serious approach to the idea of wha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Woodruff, Robert J wrote:
> Robert Walsh wrote,
>> [EMAIL PROTECTED] bin]$ ./ib_rdma_bw -n 1 -t 1000 -s 200 rkl-12
>> 4730: | port=18515 | ib_port=1 | size=200 | tx_depth=1000 |
>> iters=1 | duplex=0 | cma=0 |
&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I installed RC5 and now it just hangs,
Wow - we can't even get RC5 to build here. What distro are you running?
I've tried this on RC4 + a fixed libipathverbs package and it runs OK
(although it does take a while, which might explain the hang you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I installed RC5 and now it just hangs,
>
> [EMAIL PROTECTED] bin]$ ./ib_rdma_bw -n 1 -t 1000 -s 200 rkl-12
> 4702: | port=18515 | ib_port=1 | size=200 | tx_depth=1000 |
> iters=1 | duplex=0 | cma=0 |
> 4702: Local address: LID 0x03
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I don't think you can do symbol versioning here.
Right - probably being a little more verbose about finding the file but
not the symbol would be a good idea, though. It took me a bit of gdb
work to track the problem down: not really a big deal, but
Somewhere between OFED-1.1-RC3 and -RC4, the ibv_driver_init function
was renamed to openib_driver_init. We at QLogic were aware this change
was being made and so now our user verbs support does not work at all in
RC4. Why did something like this happen between two release candidates?
Regards
> Could be a library function in core so that ipath etc can reuse it.
> But note how there's no dependency between drivers here - no
> reason to block change in mthca until ipath/ehca implement this functionality,
> too.
True. But FWIW, we (QLogic) could probably spin something like this
pretty
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Woodruff, Robert J wrote:
> Robert Walsh wrote,
>> I'll give it a spin this afternoon: it looks quite a bit more
>> comprehensive than the small patch I did.
>
> I also just tried running the ib_rdma_bw test and it seems t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I spoke with our MPI team lead and it is very likely that the fix that
> is in 2.0.1-refresh did not make it into 3.0 beta, but it should be
> in the 3.0 release schedule to be completed in a couple of weeks.
OK then - I'll wait for that.
Regards,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tziporet Koren wrote:
> Robert Walsh wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>>> Here is a slightly modified patch for your attributes issue. Can you
>>> give it a try?
>&g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Here is a slightly modified patch for your attributes issue. Can you give it
> a try?
I rebuilt OFED from scratch with the patch, and ran successfully on
Intel MPI 2.0.1 with the refresh patch. I could not get it to run on
Intel MPI 3.0b. If you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Woodruff, Robert J wrote:
> Robert Walsh wrote,
>> I'll give it a spin this afternoon: it looks quite a bit more
>> comprehensive than the small patch I did.
>
> I also just tried running the ib_rdma_bw test and it seems t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> Oddly enough, I'm back to the same problem with your new patch as I saw
>> with the unpatched version:
>
> Hmmm. We ran this with OFED 1.1 RC3 and MPI 3.0b on an EM64T server with your
> adapter and it worked.
Weird - it's not working for me at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arlin Davis wrote:
> Robert,
>
> Here is a slightly modified patch for your attributes issue. Can you give it
> a try?
Oddly enough, I'm back to the same problem with your new patch as I saw
with the unpatched version:
$ mpiexec -n 2 ./a.out
I_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Just added all appropriate RDMA in/out fields and some code to zero out
> the structure to avoid uninitialized data fields.
Yup. By "comprehensive", I meant "better" :-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arlin Davis wrote:
> Robert,
>
> Here is a slightly modified patch for your attributes issue. Can you give it
> a try?
>
I'll give it a spin this afternoon: it looks quite a bit more
comprehensive than the small patch I did.
Regards,
Robert.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Hmm, if you have a debug version of the DAPL library, can you enable
> debug messages,
> export DAPL_DBG_TYPE=0x
>
> That may give us more information. I will also have Arlin take a look
> at this when returns on Tues.
I've been using the stuff
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Walsh wrote:
>> Hi all, I installed the RC3 package on my Xeon/Lindenhurst platforms
>> and with the pathscale card I have the following problem
>> when trying to run Intel MPI and NetPipe.
>
> Actually, I've
Woodruff, Robert J wrote:
> Robert Walsh wrote,
>> [0][rdma_iba_priv_intel.c:429] error(0x60029): OpenIB-cma: Could not
>> create DAPL endpoint: DAT_INVALID_PARAMETER(DAT_INVALID_ARG6)
>> [1][rdma_iba_priv_intel.c:429] error(0x60029): OpenIB-cma: Could not
&g
> Hi all, I installed the RC3 package on my Xeon/Lindenhurst platforms
> and with the pathscale card I have the following problem
> when trying to run Intel MPI and NetPipe.
Actually, I've been trying to run Intel MPI myself, but haven't gotten
very far yet. My attempts die like this:
$ mpie
J> Why not copy what most ethernet drivers do and just log a message on
> link negotiation state changes? ie like the:
>
> eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
>
> Maybe something like:
>
> ib0: link up, 10Gbps, port active, lid 0x10/16
That's a neat idea.
__
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland Dreier wrote:
> 1) What makes ipath special so that we want this warning for ipath
> devices but not other IB hardware?
There's nothing special about our hardware that requires this. We just
wanted that in there so we could direct customers to
Roland Dreier wrote:
> Sean> Why not remove your code from SVN?
>
> Along those lines, how would people feel if I removed the mthca kernel
> code from svn, and just maintained mthca in kernel.org git trees? I
> am getting heartily sick of double checkins for every mthca change...
I think thi
On Mon, 2006-06-26 at 15:53 -0700, Robert Walsh wrote:
> On Mon, 2006-06-26 at 17:53 -0400, Pete Wyckoff wrote:
> > Using stock 2.6.17.1, with verbs 1.0.3-1.fc4 and mthca 1.0.2-1.fc4
> > with MT25204, this line:
> >
> > ret = ibv_query_device(ctx, &h
ract 1 from the reported
> max on the send side? Just for this hardware?
Probably something else has a QP allocated? Like the SMA, maybe?
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierli
On Fri, 2006-06-16 at 15:07 -0700, Roland Dreier wrote:
> Robert, can you confirm that the new uverbs locking scheme helps the
> performance problems you're having?
Yup - that was a big help. Thanks!
Regards,
Robert.
--
Robert Walsh Email: [EMAI
On Fri, 2006-06-16 at 15:07 -0700, Roland Dreier wrote:
> Robert, can you confirm that the new uverbs locking scheme helps the
> performance problems you're having?
Sure - I'll take a look on Monday.
Regards,
Robert.
--
Robert Walsh Email:
have a similar problem in resource checking - we were relying on the
idr lock to keep us safe. I'll fix that up, too.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin
On Mon, 2006-06-12 at 12:36 -0700, Roland Dreier wrote:
> IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
This looks good - I had started something similar but your solution
solves some problems mine had (by using the live flag, even if it is
kind of bleh.)
Regards,
Robert.
--
> It does seem to be a scalability problem for some devices/workloads,
> and Robert Walsh from qlogic was planning on looking at this
> (replacing the mutex with a reference counting scheme). I don't know
> if he's started on this or not.
Not yet, but I'll be starti
yet. I'll get around to
it hopefully by the middle of next week and do the appropriate updates
from the libipathverbs end.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Sti
esting, etc.
* We very briefly considered using Subversion when we got involved
in OpenFabrics, but just about every developer here shot the
idea down as a step backwards, development-wise. Chalk that one
up to religion.
Regards,
Robert.
--
Robert Wals
On Tue, 2006-04-11 at 15:31 -0700, Robert Walsh wrote:
> Do we have any CentOS 4.2 or 4.3 machines?
People on openib-general can ignore this :-) I meant to send it to an
internal alias. Sorry for the bother.
Regards,
Robert.
--
Robert Walsh Email: [EM
Do we have any CentOS 4.2 or 4.3 machines?
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043
or us
at PathScale, and we've been using it for ages.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
QLogic Corporation Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200
;
> 2.6.17 still has IB_NODE_CA. The svn tree has some iWARP-related
> changes that make it RDMA_NODE_IB_CA, but those haven't been merged
> upstream and won't be in 2.6.17.
Would an ifdef be OK?
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale,
> - dev->node_type = IB_NODE_CA;
> + dev->node_type = RDMA_NODE_IB_CA;
Which of these #defines is valid in 2.6.17? Just curious. What we have
in svn matches what you put in your git tree, you see... Perhaps an
#ifdef until 2.6.17 goes through?
Regards,
Robert.
--
right now but might be used by the ipath_ether driver. That
> would be a good cleanup too but I'll leave that for another day.
>
> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Thanks, Roland. I'll merge them in as appropriate.
Regards,
Robert.
--
Robert Walsh
e kernel; and 2) deal with the IB stack. Even if we ripped out the
guts of ipath_mad.c and had it pass the requests to the userspace SMA,
we'd still have to have the diversion path in there for cases where the
IB stack isn't around.
--
Robert Walsh
u have any suggestions?
Actually, I've been mounting it on /ipathfs. Not that the difference is
terribly important. But if you do have suggestions on where this kind
of thing should go, I'd love to hear it.
Regards,
Robert.
--
Robert Walsh
t have guessed, I kind of forgot about this (I was swamped
with unrelated stuff.) I'll try get someone else here at PathScale to
get these numbers.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone:
> libsysfs is unmaintained, and the main user of it (udev) has stopped
> using it. So it's going to bitrot and get dropped from distros. And
> libsysfs kind of sucks too.
Fair enough - that's a good reason.
Regards,
Robert.
signature.asc
Description: This is a digitally signed message part
_
> * Eliminate the dependency on libsysfs by implementing the required
>sysfs handling directly.
Any particular reason why, other than just minimizing external
dependencies?
Regards,
Robert.
signature.asc
Description: This is a digitally signed message part
On Fri, 2006-02-10 at 16:51 -0800, Roland Dreier wrote:
> Here is a series of patches that adds a new function ib_modify_qp_is_ok(),
> which low-level drivers can use to replace boilerplate logic for
> validating the parameters to the modify_qp method.
>
> In addition to getting rid of duplicated
y
shipped InfiniPath software (1.2, which went live today.) We're still
working on incorporating all the feedback from lkml.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 S
Hmm, well, nothing else in the infiniband directory uses this, probably
because of the dual GPL/BSD license that all files in there have. For
consistency, I'll leave it as EXPORT_SYMBOL, but I don't have any real
problems with it either way.
Regards,
Robert
by userland programs. Unless we
put in magic typedef for s32 and friends in userland, that won't work,
hence we use the C standard typedefs.
Is this a problem?
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc.
= ...
>
> Use of -y let you do better Kconfig selection in the makefile, and is
> preferred compared to -objs
No problem.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stie
"
Good question. I'll take a closer look.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650
; > library function do not attempt to build this driver. To avoid breaking
> > `make allmodconfig'.
>
> How about we implement a portable version in C that you get
> by default if you don't implement the assembler routine?
> Pretty please? :-)
Sure. :-)
--
On Sun, 2005-12-18 at 04:27 +0100, Andi Kleen wrote:
> Robert Walsh <[EMAIL PROTECTED]> writes:
> >
> > Any chance we could get these moved into the x86_64 arch directory,
> > then? We have to do double-word copies, or our chip gets unhappy.
>
> Standard mem
a suitably-equipped motherboard. On some machines, it's
available on the motherboard itself (e.g. the Linux Networx LS/X.)
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierli
On Sat, 2005-12-17 at 19:10 -0800, Andrew Morton wrote:
> Robert Walsh <[EMAIL PROTECTED]> wrote:
> >
> > > > +int ipath_mlock(unsigned long start_page, size_t num_pages, struct
> > > > page **p)
> > > OK. It's perhaps not a very well name
;
> Can you send numbers comparing -Os/-O2/-O3 (without -g3, preferable with
> gcc 4.0) including a description what and how you are measuring?
I'll try get around to this after my vacation and after we've had time
to absorb and address all the other feedback we received.
Reg
_ipath_idstr)' -DIPATH_KERN_TYPE=0
> >...
>
> Please move the _IPATH_IDSTR revision tag to a header file and remove
> IPATH_KERN_TYPE.
I'll see what I can do.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc.
then you need to use readl() and family most like; they already take
> care of this anyway.
Oh, OK then.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200
$1,%ecx
> > + andl $1,%edx
> > + cld
> > + rep
> > + movsq
> > + movl %edx,%ecx
> > + rep
> > + movsd
> > + ret
>
> err, we have a portability problem.
Any chance we could get these moved into the x86_64 arch directory,
then
'll ask around. We don't support the hardware in 32-bit
anyway, so...
> > +static __inline__ uint64_t ipath_kget_kreg64(const ipath_type stype,
> > +ipath_kreg regno)
> > +{
> > + if (!devdata[stype].ipath_kregbase)
> > +
addr) writel(val, addr)
> > +#define ipath_writeq(val, addr) writeq(val, addr)
> > +#endif
>
> Please use the proper functions directly. Your simulator can override
> them if nessecary.
Fine.
> > +static __inline__ uint32_t ipath_kget_kreg32(const ipath_type stype,
&g
; INFINIPATH_I_VERS_SHIFT) \
> > +& INFINIPATH_I_VERS_MASK)
>
> Please use static inlines instead for readability.
OK.
Regards,
Robert.
--
Robert Walsh Email: [EMAIL PROTECTED]
PathScale, Inc. Phone: +1 650 934 8117
On Sat, 2005-12-17 at 14:38 +0200, Pekka Enberg wrote:
> On 12/17/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> > +#define TRUE 1
> > +#define FALSE 0
>
> Please kill these.
OK.
--
Robert Walsh Email: [EMAI
1 - 100 of 126 matches
Mail list logo
