On Wed, May 18, 2011 at 11:31 AM, Milton Miller milt...@bga.com wrote:
So the real question should be why is x86-32 supplying a broken writeq
instead of letting drivers work out what to do it when needed?
Sounds a lot like what I was asking a couple of years ago :)
;
}
if (!(*handle)) {
ehca_gen_err(Wrong eHCA handle for adapter: %s.,
- dev-node-full_name);
+ dev-dev.of_node-full_name);
return -ENODEV;
}
--
Roland Dreier rola...@cisco.com
How to make better use of the remaining ITLB slots is tricky.
Somehow one would want to map at lest one to modules but I cannot see how.
No. If you use modules, you pay the price. Sane embedded solutions
running in tight environments don't use modules :-) No point pinning
TLB
This isn't a review of this patch -- more a question out of curiousity
about how you actually can do memory remove in practice. Do you have
any coordination between the platform/hypervisor and the kernel to make
sure that a memory region you might want to remove later gets put into
zone_movable
applied, thanks
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
this seems reasonable to me, applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Given that you seem to like the rest of the code and Jason hasn't spoken
up yet, I think we can have Roland merge this patch. Roland, what do you
think?
I don't see any problem with the idea and this does sound like a step
forward, so I am planning on merging this (pending review).
looks good, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
applied...
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
thanks, applied.
-#define HCAD_VERSION 0026
+#define HCAD_VERSION 0027
the driver version was already 0027 (since bde2cfaf), so I dropped this chunk.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Yeah, the notifier code remains untouched as we still do not allow dynamic
memory operations _while_ our module is loaded. The patch allows the driver
to
cope with DMEM operations that happened before the module was loaded, which
might result in a non-contiguous memory layout. When the
The new Nehalems provide 8 logical threads in a single socket. All
those threads share a cache, and they have cmpxchg8b anyway, so this
won't matter.
FWIW, Nehalem EX actually goes to 8 cores/16 threads per socket. But
worrying about 32-bit performance on Nehalem is a little silly --
OK, one major issue with this patch and a few minor nits.
First, the major issue is that I don't see anything in the patch that
changes the code in ehca_mem_notifier() in ehca_main.c:
case MEM_GOING_ONLINE:
case MEM_GOING_OFFLINE:
/* only ok if no hca is attached
looks fine, applied for 2.6.31
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
did you have a chance to take a look at the patchset and will you apply it,
or
are there any outstanding issues we need to address?
I guess it's OK, but definitely 2.6.31 material. I guess I'll stick it
linux-next soon.
- R.
___
Linuxppc-dev
thanks, applied.
From: Anton Blanchard antonb at au1.ibm.com
Signed-off-by: Stefan Roscher stefan.roscher at de.ibm.com
please use '@' signs so these are real email addresses.
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
thanks, applied 2 3.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Because of this fundamental code change we will also increment the version
number.
So this is 2.6.31-targeted stuff I assume? (Too late in the 2.6.30
cycle for fundamental code change of course)
- R.
___
Linuxppc-dev mailing list
+queue-queue_pages = kmalloc(nr_of_pages * sizeof(void *), GFP_KERNEL);
How big might this buffer be? Any chance of allocation failure due to
memory fragmentation?
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Alan did have one valid point though. Determining how long to loop
for is architecture-specific. Using jiffies is bad, because even one
jiffy is too long. Adding a udelay() inside the loop means that it
only checks he condition every microsecond. So the real solution is
to use keep
huge_page_size(page_hstate(page))
That would suit. I assume the intention is for that to be usable by
driver modules on any architecture?
erm, you overestimate the amount of planning and forethought which goes
into these things ;)
The lack of any
Right, but then you need to set that in the VMA's, and thus gone is your
nice fast g_u_p() that doesn't touch VMAs :-)
Registering memory is a slow path thing in the RDMA world. Speeding it
up is nice, so we make userspace do the madvise(VM_DONTCOPY) if it cares
but if it doesn't it can
Forwarding Eli's patch below, since PowerPC guys may have missed it. I
guess the question for Ben et al is whether there is any issue with
exporting HPAGE_SHIFT for modules (can be EXPORT_SYMBOL_GPL if you feel
it's an internal detail). It would probably make sense to roll this
change into the
to a long long integer
type) changed u64 from unsigned long to unsigned long long, which
means that printk formats for printing u64 values should use ll
instead of l to avoid warnings. Fix all the places affected by this
in ehca.
Signed-off-by: Roland Dreier rola...@cisco.com
---
drivers
Sorry to appear picky, but how is that different from the patch powerpc:
cleanup from powerpc l64 to ll64 change: drivers/infiniband that I sent
to you on Jan 7?
Well, I didn't lose my version and forget all about it ;)
Seriously, I must have lost that patch, sorry about that. I'll dig it
Can you double check that the e1000 isn't copying the PCI resources into
a unsigned long before ioremap'ing the result, thus cropping the top
bits ?
as far as I can see, e1000 is using pci_ioremap_bar(), which should do
the right thing as long as resource_size_t is the right type (which it
thanks, applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
If we're going to clean this code up, does it make sense to take it
further? More precisely, your patch does:
@@ -226,7 +226,7 @@ u64 hipz_h_alloc_resource_eq(const struct
ipz_adapter_handle adapter_handle,
u32 *eq_ist)
{
u64 ret;
- u64
are you trying to land the 'typedef unsigned long u64' change for
2.6.28, or can these patches wait for 2.6.29?
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Looks good... I'll add this for 2.6.29, since as far as I can tell this
bug has been there approximately forever already.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
A previous fix introduced a regression where port activation events were
dropped unconditionally if port autodetection was not enabled. Fixed.
Is this a fix to IB/ehca: Remove reference to special QP in case of
port activation failure? Because if so I can roll it into that patch,
since Linus
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied with a slightly expanded changelog.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
: Don't allow creating UC QP with SRQ
This patch prevents a UC QP to be created attached to an SRQ, since
current firmware does not support this feature.
Signed-off-by: Michael Faath [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
diff --git a/drivers
thanks, queued for 2.6.28.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
that was is another bug, since
highmem pages are still RAM.
Reported-by: vb [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Paul, didn't see this in your list... please add for 2.6.28.
arch/powerpc/mm/mem.c |5 ++---
1 files
#ifndef CONFIG_PPC64 /* XXX for now */
- return paddr __pa(high_memory);
+ return pfn max_pfn;
#else
+ unsigned long paddr = (pfn PAGE_SHIFT);
seems like this could be a phys_addr_t
Yes, it could I guess, but that would be an unrelated change, and I'm
not sure
Can someone point me at a simple example of how to demux irqs using
the powerpc irq functions? I have eight devices on a single irq and I
want to turn them into virtual irqs.
Sorry about the previous reply.
Anyway, what are you going to demux based on? Do you have some other
signal you
The muxed interrupts are inside a SOC CPU. For example eight GPIOs
can each individually be enabled to trigger hardware interrupt 7. When
I get hw interrupt 7 i want to demux it into 8 virtual interrupts.
There are eight bit registers for individually acking, enabling, etc
each of the
You should fix 52xx with the same for loop change then, since I
blatantly most of this file from you ;)
Heh, then factor out mpc5200_simple_probe() into a helper and use it
instead of copying it as ppc44x_probe? ;)
If you stick to the NULL-terminated array version, then it becomes easy
to
Except that logically doesn't make much sense. Why would you have a
list of mpc52xx and 44x boards together? They require completely
different kernels because the MMU and drive set is entirely different.
Or am I totally missing what you are saying?
Yeah, I wasn't clear -- I meant to
Yeah, I wasn't clear -- I meant to add a new helper like
of_flat_dt_is_compatible_list() (not sure of the name) that takes a node
and a NULL-terminated array of strings, and then mpc5200_simple_probe()
can become a one-liner, along with mpc5121_generic_probe(),
tqm85xx_probe(),
thanks, applied all 5.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
IMHO, this driver was really rushed in and that was a huge mistake.
If it had gone through linux-next we could have tidied all of this
stuff up in a less rushed manner.
?? This thread *is* about a build failure in linux-next.
- R.
___
thanks, applied 1 and 2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Sorry for the late comments, I missed this when it went by before.
+DMA_ATTR_STRONG_ORDERING
+--
+
+DMA_ATTR_STRONG_ORDERING specifies that previous reads and writes are
+performed in the order in which they're received by the IOMMU; thus
+reads and writes may not
This is all about inbound transfers, i.e. DMAs coming from the I/O bridge
into the CPU, both DMA read and DMA write.
OK -- at a minimum I think the documentation should make that clear. As
it stands the description of what this does is pretty much impossible to
parse and understand.
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ok, I queued this for 2.6.27. thanks everyone
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
During corner case testing, we noticed that some versions of ehca
do not properly transition to interrupt done in special load situations.
This can be resolved by periodically triggering EOI through H_EOI,
if eqes are pending.
Signed-off-by: Stefan Roscher [EMAIL PROTECTED]
---
During corner case testing, we noticed that some versions of ehca
do not properly transition to interrupt done in special load situations.
This can be resolved by periodically triggering EOI through H_EOI,
if eqes are pending.
So just to be clear: this is a workaround for a
So just to be clear: this is a workaround for a hardware/firmware bug?
Yes it is.
OK, so paulus et al... does it seem like a good approach to call H_EOI
from driver code (given that this driver makes tons of other hcalls)?
How critical is this? Since you said corner case testing I suspect
me too. That's the whole basis for readX_relaxed() and its cohorts: we
make our weirdest machines (like altix) conform to the x86 norm. Then
where it really kills us we introduce additional semantics to selected
drivers that enable us to recover I/O speed on the abnormal platforms.
+if (desc-chip desc-chip-eoi)
+desc-chip-eoi(irq);
This doesn't seem like the type of thing a device driver should be
doing. Both patches are rather short on changelog text -- what is the
issue here and how does this fix it?
thanks, applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
The problem is that your two writel's, despite being both issued on
cpu X, due to the spin lock, in your example, can end up with the
first one going through NR 1 and the second one going through NR 2. If
there's contention on NR 1, the write going via NR 2 may hit the PCI
bridge prior
Actually, this specifically should not be. The need for mmiowb on altix
is because it explicitly violates some of the PCI rules that would
otherwise impede performance. The compromise is that readX on altix
contains the needed dma flush but there's a variant operator,
readX_relaxed
Um, OK, you've said write twice now ... I was assuming you meant read.
Even on an x86, writes are posted, so there's no way a spin lock could
serialise a write without an intervening read to flush the posting
(that's why only reads have a relaxed version on altix). Or is there
something
Writes are posted yes, but not reordered arbitrarily.
on standard x86 I mean here...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Writes are posted yes, but not reordered arbitrarily. If I have code like:
spin_lock(mmio_lock);
writel(val1, reg1);
writel(val2, reg2);
spin_unlock(mmio_lock);
then I have a reasonable expectation that if two CPUs run this at the
same time, their writes to
This is a different issue. We deal with it on powerpc by having writel
set a per-cpu flag and spin_unlock() test it, and do the barrier if
needed there.
Cool... I assume you do this for mutex_unlock() etc?
Is there any reason why ia64 can't do this too so we can kill mmiowb and
save
Cool... I assume you do this for mutex_unlock() etc?
That's a good point... I don't think we do. Maybe we should.
I think it's needed -- take a look at 76d7cc03, which came from a real
bug seen on Altix boxes.
___
Linuxppc-dev mailing list
We are not sure if this should be fixed in the driver or in uverbs itself.
Roland, what's your opinion about this?
Would be nice to be able to fix it in uverbs but I don't see how. In
particular a kernel consumer has to have the same guarantee that no
async events will come in after destroy
I agree, that's why I posted the driver fix first.
Glad we agree :)
I thought about it a little more and really convinced myself that there
is no good way for generic code to handle this race.
So, will you apply it next?
Yes, will apply it shortly.
- R.
So I applied this, but thinking about it further, do you (theoretically
at least) have the same problem with CQ and SRQ async events?
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Signed-off-by: Stefan Roscher stefan.roscher at de.ibm.com
Kind of an inadequate changelog ;)
Is this a fix or an enhancement or what?
+if (atomic_read(shca-num_cqs) = ehca_max_cq) {
+if (atomic_read(shca-num_qps) = ehca_max_qp) {
These are racy in the sense that multiple
thanks, makes sense, applied.
fast turnaround too ;)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied 1-2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hm. Katmai is already in-tree. Theoretically I should be able to get
the HW docs and do a new DTS and have it mostly just work. Perhaps
I'll give that a shot and have you give it a quick spin.
Yep, should be pretty easy. A while back I built a Katmai kernel in
arch/ppc based on the
YUCCA
Yucca was what again? 440spe?
Yes, it was the first 440SPe eval board; since replaced by Katmai.
I have a Yucca and can at least test thing; if no one else gets to it,
I may try to port it to arch/powerpc for 2.6.26.
___
Linuxppc-dev
thanks, applied 1-4.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
applied, thanks
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
What is the fix you suggest, to add a device query that tells you for
which verbs the documentation does not apply? or enhance the code of the
map_phys_fmr verb within the ehca driver to return error if called
from non-sleepable context?
I think the right fix for iSER would be to
thanks, applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied.
With your next batch of patches for 2.6.25, could you clean up:
--- a/drivers/infiniband/hw/ehca/hcp_if.c
+++ b/drivers/infiniband/hw/ehca/hcp_if.c
@@ -89,6 +89,7 @@
#define HCALL9_REGS_FORMAT HCALL7_REGS_FORMAT r11=%lx r12=%lx
static
map_phys_fmr
In fact, we do use hCalls there. Our hardware doesn't actually support FMRs,
so we translate a map FMR into a reallocate PMR, which doesn't work
without hCalls. What's more, the hCalls involved (e.g. H_FREE_RESOURCE)
might well return H_LONG_BUSY, so the whole
I think it needs some more inspection. The msleep in there is only called
for hcalls that return H_IS_LONG_BUSY(). In theory, you can call
ehca_plpar_hcall_norets() from inside an interrupt handler if the
hcall in question never returns long busy.
Fair enough... according to
+ ehca_lock_hcalls = !(cur_cpu_spec-cpu_user_features
+ PPC_FEATURE_ARCH_2_05);
We already talked about this yesterday, but I still feel that checking the
instruction set of the CPU should not be used to determine whether a
specific
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied both patches.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
-by and an agreement that this
change can go via the powerpc.git tree from Roland Dreier and Jeff
Garzik.
I don't see anything objectionable in the infiniband parts of the
patch -- I don't have any way to test the changes but it all looks
like a straightforward conversion to a new platform API. So:
Acked
thanks, applied this and the umem patch...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
This looks realy nice to me... a very clean patch.
I'll add this to 2.6.24 unless someone objects soon...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
obviously OK...applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
What happens if someone runs the new driver with older firmware? Or
what if someone upgrades the firmware without updating the driver?
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
-#define HCA_CAP_MR_PGSIZE_4K 1
-#define HCA_CAP_MR_PGSIZE_64K 2
-#define HCA_CAP_MR_PGSIZE_1M 4
-#define HCA_CAP_MR_PGSIZE_16M 8
+#define HCA_CAP_MR_PGSIZE_4K 0x8000
+#define HCA_CAP_MR_PGSIZE_64K 0x4000
+#define HCA_CAP_MR_PGSIZE_1M 0x2000
+#define
I don't understand this patch. rdma/ib_verbs.h says this about
ib_create_qp():
* @qp_init_attr: A list of initial attributes required to create the
* QP. If QP creation succeeds, then the attributes are updated to
* the actual capabilities of the created QP.
So it seems the current code
Was going to recreate this patch, but then I saw that you
probably have incorporated it (manually) in your latest git.
Just want to make sure I'm seeing it right.
Yes, I ended up doing it by hand. Thanks.
___
Linuxppc-dev mailing list
thanks, applied.
BTW, does your SRQ-capable hardware support generating the last WQE
reached event? There's not any reliable way to avoid problems when
destroying QPs attached to an SRQ without it, and the IB spec requires
CAs that support SRQs to generate it (o11-5.2.5 in chapter 11 of vol 1).
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied. I fixed this up myself to work with commit 20c2df83,
which got rid of the destructor argument to kmem_cache_create() -- you
probably want to check my tree to make sure it's OK.
Also the same as I said before about checkpatch.pl's warning:
WARNING: externs should be avoided in
Here's some anecdotal evidence :)
http://lists.openfabrics.org/pipermail/general/2007-May/035758.html
Right, but then we went on to say that we probably want to use
multiple vectors to separate out multiple HCA ports rather than
send/sreceive on the same port. And the current IPoIB
1 - 100 of 108 matches
Mail list logo
