On Thu, Nov 02, 2006 at 02:30:26PM -0800, Ralph Campbell wrote:
+static dma_addr_t ipath_dma_map_single(struct ib_device *dev,
+void *cpu_addr, size_t size,
+enum dma_data_direction direction)
+{
+ BUG_ON(direction
On Fri, Oct 27, 2006 at 11:15:40AM -0700, Roland Dreier wrote:
I must be misusing dma_map_single(). What I'm doing is allocating a
verb message reply queue for the adapter to DMA verb replies into. It
never gets unmapped. I kmalloc() it, then map it. I could use
dma_alloc_coherent()
On Sat, Oct 28, 2006 at 10:03:07PM +0200, Sasha Khapyorsky wrote:
node_desc.description buffer is received from the network and should
not be NULL-terminated. In such cases using it as regular string in
functions like printf() leads to segmentation faults. This patch fixes
such usages.
On Sat, Oct 28, 2006 at 10:04:25PM +0200, Sasha Khapyorsky wrote:
node_desc.description buffer is received from the network and should
not be NULL-terminated. In such cases using it as regular string in
functions like strcmp() or printf() leads to segmentation faults.
This patch fixes such
On Sat, Oct 28, 2006 at 01:10:54PM -0700, Roland Dreier wrote:
I guess the requirement for userspace RDMA to work is that no
further action is required after the dma_map_sg() for both the
device and the CPU to touch the region. Because userspace has no
way for calling dma_sync_xxx or
.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
Looks good,
Acked-by: Muli Ben-Yehuda [EMAIL PROTECTED]
Cheers,
Muli
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please
On Wed, Aug 09, 2006 at 10:04:35AM +0300, Michael S. Tsirkin wrote:
diff --git a/drivers/infiniband/hw/mthca/mthca_doorbell.h
b/drivers/infiniband/hw/mthca/mthca_doorbell.h
index dd9a44d..e5f0ad6 100644
--- a/drivers/infiniband/hw/mthca/mthca_doorbell.h
+++
On Wed, Aug 09, 2006 at 10:37:20AM +0300, Michael S. Tsirkin wrote:
Quoting r. Muli Ben-Yehuda [EMAIL PROTECTED]:
+enum {
+ MTHCA_SEND_DOORBELL_FENCE = 1 5
+};
Does anonymous enum have any benefit over define for this?
Not really, no.
Good, because I think #define
On Wed, Jul 12, 2006 at 05:40:13PM -0700, David Miller wrote:
From: Roland Dreier [EMAIL PROTECTED]
Date: Wed, 12 Jul 2006 17:11:26 -0700
A cleaner solution would be to make the dma_ API really use the device
it's passed anyway, and allow drivers to override the standard PCI
stuff
On Mon, May 22, 2006 at 03:20:29PM +0300, Ishai Rabinovitz wrote:
+ case IB_CM_DREQ_RECEIVED:
+ printk(KERN_WARNING PFX
+IB_CM_DREQ_RECEIVED received - connection closed\n);
+ if (ib_send_cm_drep(cm_id, NULL, 0))
+
On Mon, May 01, 2006 at 02:25:46PM +0300, Ishai Rabinovitz wrote:
Move the destruction of the host and the removal from a list to a function.
Signed-off-by: Ishai Rabinovitz [EMAIL PROTECTED]
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
On Mon, May 01, 2006 at 02:27:39PM +0300, Ishai Rabinovitz wrote:
Do not add the same target twice.
Signed-off-by: Ishai Rabinovitz [EMAIL PROTECTED]
Index: last_stable/drivers/infiniband/ulp/srp/ib_srp.c
===
---
On Mon, May 01, 2006 at 05:04:58PM +0300, Michael S. Tsirkin wrote:
why _irq and not _irqsave? Are you sure this code can't ever be called
with interrupts off via some other path?
Given the mutex_lock above, this better be true.
Good point, but _irq instinctively makes me worried.
you __get_module on it? what's keeping the
module from disappearing between those two points?
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
___
openib-general mailing list
openib-general@openib.org
http
On Thu, Apr 06, 2006 at 04:38:33PM +0300, Michael S. Tsirkin wrote:
No, since we are keeping a callback pointer into that module.
Sorry if I'm being dense but I don't see it in this patch. Point me at
it?
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com
. By the way, shouldn't __get_module be
try_module_get(), with proper error handling if it fails?
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
___
openib-general mailing list
openib-general@openib.org
http://openib.org
?
+ case MTHCA_EVENT_TYPE_CLIENT_REREGIST:
+ client_reregister_event(dev,
+
(be32_to_cpu(eqe-event.port_change.port) 28) 3);
+ break;
80 columns per line please.
Cheers,
Muli
--
Muli Ben-Yehuda
http
On Sun, Apr 02, 2006 at 03:49:43PM +0300, Michael S. Tsirkin wrote:
Quoting r. Muli Ben-Yehuda [EMAIL PROTECTED]:
80 columns per line please.
Roland's actually pretty lax on this.
It's not exactly critical, but it's good kernel manners are to stay
below 80 columns. The limit on the length
can build an ia64 (or almost any other arch) toolchain using
crosstool and compile test with
it. http://www.kegel.com/crosstool/#download
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
___
openib-general mailing list
or the authors, but there are perfectly
reasonable reasons to ask someone else to post a patch on your behalf
- including but not limited to to only being able to use Lotus Notes
with one's IBM email. I'm sure you've all seen the travesties that
Notes inflicts on inline patches.
Cheers,
Muli
--
Muli Ben
, and close() frees them? no
ioctl necessary.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe
a constantly changing constantly evolving
process. This stuff is usually discussed on the kernel mailing
list, and summarized or one of the many summaries (kerneltraffic,
lwn.net's weekly kernel page).
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com
specifically about try_module_get().
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please
and will fail. If it doesn't matter that it
succeeds or fails, why call it at all?
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo
in the
kernel use do { ... } while(0)?)
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please
In total, these 22 files come to about 3.4GB - roughly 850M addresses.
However, the function crashes and gives out the message ENOMEM after
mapping
about 2.6GB.
On 32 bit x86 machines, with the stock Linux kernel address space
arrangement, you have only 3GB of usable address space (because
26 matches
Mail list logo
