On Wed, May 18, 2011 at 11:31 AM, Milton Miller 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 :)
http://lkml.org/lkml/2009/4/19/164
But Ing
gt; 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
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
> > 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
>
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 so
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
https://lists.ozlabs.org/listinfo
> 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 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 -- t
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 t
looks fine, applied for 2.6.31
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied 2 & 3.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied.
> From: Anton Blanchard
> Signed-off-by: Stefan Roscher
please use '@' signs so these are real email addresses.
- R.
___
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
> +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
https://ozlabs.org/m
> 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
Linuxppc-dev
> 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 ke
> 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 lea
> Note that g_u_p() has all sort of shortcommings... we were discussing
> some of that recently due to bugs reported from the field.
>
> The problem mostly is that you cannot guarantee that the physical page
> will remain mapped to that virtual address in the process. For example,
> if your
> You should be able to find the head of a compound page using the
> compound_head() inline, so try
> PAGE_SIZE << compound_order(compound_head(page))
Thanks! Looks like that should be exactly what we need.
- R.
___
Linuxppc-dev mailing list
> > > 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 EXPORT_SYMBOL
> I think it's something like
>
> 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?
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozl
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 ml
> 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 di
Change u64/s64 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
> 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 i
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 outs[PLPAR_HCAL
thanks, applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
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
> The error message printed when the eHCA driver prevents memory hotplug is
> misleading -- the user might think that hot-removing the lhca, hotplugging
> memory, then hot-adding the lhca again will work, but it doesn't.
That's too bad... I applied this patch but out of curiousity, why
doesn't
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 Li
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
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
700
IB/ehca: 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
thanks, queued for 2.6.28.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
> > #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'
However, I think 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
> 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 t
> 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
> > 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_prob
> 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
> 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
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.
___
Linux
thanks, applied 1 and 2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 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.
> Str
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
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]>
> 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.
E
> > 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 sus
> 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 hardware/
> +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 fi
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 pri
> > 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
Linux
> 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 ever
> > 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 tim
> 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
> 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
> somet
> 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_relaxe
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
> 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.
_
> 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
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, makes sense, applied.
fast turnaround too ;)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
> Signed-off-by: Stefan Roscher
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 simultaneous calls to
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied all 5.
___
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
thanks, applied
___
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-d
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
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 DEFINE_SPINLOCK(hcal
thanks, applied.
___
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
> > 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 wh
> 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 Documentat
> > + 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
> spe
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
thanks, applied 1-5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
gt;
> If not, then you need to get an Acked-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
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
> If the rest of this patchset is okay with you, could you apply it and
> leave out this one patch? The patchset will apply cleanly without it.
Yes, no problem, I'll drop this patch for now.
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
1 - 100 of 123 matches
Mail list logo
