generation and handling perspective,
so yes, could be an issue there as well.
Gruss / Regards
Christoph Raisch
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Dave Hansen [EMAIL PROTECTED] wrote on 14.02.2008 18:12:43:
On Thu, 2008-02-14 at 09:46 +0100, Christoph Raisch wrote:
Dave Hansen [EMAIL PROTECTED] wrote on 13.02.2008 18:05:00:
On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
Constraints imposed by HW / FW:
- eHEA has
.
So we're glad we finally found the right person who takes responsibility
for this topic!
-- Dave
Gruss / Regards
Christoph Raisch + Jan-Bernd Themann
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo
Or Gerlitz [EMAIL PROTECTED] wrote on 12.12.2007 13:14:25:
Joachim Fenkes wrote:
Roland Dreier [EMAIL PROTECTED] wrote on 10.12.2007 22:47:37:
It's an optional device feature, so this should be OK
(although the iSER driver currently seems to depend on a device
supporting FMRs, which is
[EMAIL PROTECTED] wrote on 06.11.2007 23:31:19:
We should cut this down to the bare necessary and fold it into the
libhugetlbfs testsuite.
Well, this testcase is already pretty close to the bare minimum
what's needed to run IB/RDMA queues.
You can compare this to for example ibv_rc_pingpong
Hello,
if get_user_pages is used on a hugetlb vma, and there was no previous write
to the pages,
follow_hugetlb_page will call
ret = hugetlb_fault(mm, vma, vaddr, 0),
although the page should be used for write access in get_user_pages.
We currently see this when testing Infiniband on ppc64 with
Michael Neuling [EMAIL PROTECTED] wrote on 03.11.2007 07:06:31:
DD allocates HEA resources and gets firmware_handles for these
resources.
To free the resources DD needs to use exactly these handles.
There's no generic firmware call clean out all resources.
Allocating the same resources
Michael Ellerman [EMAIL PROTECTED] wrote on 02.11.2007 07:30:08:
On Wed, 2007-10-31 at 20:48 +0100, Christoph Raisch wrote:
Michael Ellerman [EMAIL PROTECTED] wrote on 30.10.2007 23:50:36:
If that's really the way it works then eHEA is more or less broken for
kdump I'm afraid.
We think we
Michael Ellerman [EMAIL PROTECTED] wrote on 28.10.2007 23:32:17:
How do you plan to support kdump?
When kexec is fully supported kdump should work out of the box
as for any other ethernet card (if you load the right eth driver).
There's nothing specific to kdump you have to handle in
Roland Dreier wrote on 13.09.2007 06:33:45:
Also if someone runs a kernel with 64K pages on a machine where they
end up being simulated from 4K pages, do you have the same issue with
the hypervisor ganging together non-contiguous pages?
With todays hypervisor and todays pagesizes and todays
on powerpc platforms which is totally
broken in these cases.
This is definitely not something we can change in the HEA device driver
alone.
It could also affect any other networking cards on POWER (e1000,s2io...).
Paul, Michael, Arndt, what is your opinion here?
Gruss / Regards
Christoph Raisch
What decides if a QP is LL or not?
- R.
Currently we use a high bit in the QP type, which is not how we want to
keep it permanently.
What would you suggest, add two additional LL QP types, or change something
more fundamental
in libibverbs and kernel ib core?
We think we can get along quite
12 matches
Mail list logo
