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:
> >
most prominent example heading
there
>
> Do you know what other operating systems do with this hardware?
We're not aware of another open source Operating system trying to address
this topic.
>
> In the future, please make an effort to get review from knowledgeable
> people
ore we still need the memory to be "pinned" if ib_umem_get() is
called.
So with the current implementation we don't have much use for a notifier.
"It is difficult to make predictions, especially about the future"
Gruss / Regards
Christoph Raisch + Hoang-Nam Nguyen
-
Greg KH <[EMAIL PROTECTED]> wrote on 07.02.2008 23:17:12:
> On Tue, Jan 29, 2008 at 03:20:20PM +0100, Christoph Raisch wrote:
> What is it? It has to live on some kind of bus, right?
It is a piece of hardware with a firmware/hypervisor abstraction layer on
top.
The hypervi
his structure
/sys/bus/ibmebus/devices/789D.001.XX-P1/port0
/sys/bus/ibmebus/devices/789D.001.XX-P1/port1
So, which way should we try?
Gruss / Regards
Christoph Raisch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
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
Michael Ellerman wrote on 26.11.2007 09:16:28:
> Solutions that might be better:
>
> a) if there are a finite number of handles and we can predict their
> values, just delete them all in the kdump kernel before the driver
> loads.
Guessing the values does not work, because of the handle s
[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 e
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
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 broke
Michael Ellerman <[EMAIL PROTECTED]> wrote on 30.10.2007 23:50:36:
>
> On Tue, 2007-10-30 at 09:39 +0100, Christoph Raisch wrote:
> >
> > Michael Ellerman <[EMAIL PROTECTED]> wrote on 28.10.2007 23:32:17:
> > Hope I didn't miss anything here...
>
>
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
e
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 today
> 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 quit
ed to a different TCP receive side
processing?
In a perfect world we shouldn't see a diffference if this is enabled or
not,
but measurements indicate something completely different at 10gbit.
Gruss / Regards
Christoph Raisch
-
To unsubscribe from this list: send the line "unsubscribe linu
is it possible to figure out if this is what you want or just DoS?
It doesn't change anything compared to a non LRO driver, we process a
certain
maximum amount of frames before waiting for the next interrupt,
the packet filters/DoS should still see all traffic (which is above the
driver).
Any
Hi Hal,
you are correct,
with the current firmware version it will fail later.
Christoph R.
[EMAIL PROTECTED] wrote on 23.04.2007 18:55:59:
> Hi Joachim,
>
> On Mon, 2007-04-23 at 12:23, Joachim Fenkes wrote:
> > Add "Modify Port" verb support to eHCA driver.
> > ib_cm needs this to initialize
ilehandle
usage,
it's shared by ~5 drivers now.
I'd say lets investigate the direction of an own filesystem unless
there's no other clean solution.
We can polish the current version a bit, but that won't change the "magic
offsets".
Roland, could you take this patchset in
nge, because both kernel and userspace
driver have to be in sync again and need a good amount of test.
And beginning next week the christmas holiday season will be over.
Christoph Raisch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
; I'd go as far as saying do_mmap(_pgoff) should not be exported at all,
> but we'd need to fix similar braindamage in drm first.
Maybe we shouldn't have looked at that driver how to use mmap
within the kernel while examining HOW to implement what we needed.
What other methods would you suggest?
Is there already a "proper" usage pattern for what we need in the
kernel?
Christoph Raisch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
21 matches
Mail list logo
