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:
> >
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
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 about these kinds of things before using them in your driver.
> Your company has many,
.
So we're glad we finally found the right person who takes responsibility
for this topic!
-- Dave
Gruss / Regards
Christoph Raisch + Jan-Bernd Themann
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
ill 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
--
To unsubscribe fro
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
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
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 hypervisor provides
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
try?
Gruss / Regards
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/
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
> >>
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
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
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
[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
[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
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
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
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 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...
>
> Perha
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...
Perhaps. When we kdump the kernel does not call the reboot
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
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
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
> 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
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
nt 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 linux-kernel" in
th
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 sugge
(which is above the
driver).
Any suggestions how to handle this better/different?
--
Stephen Hemminger
Gruss / Regards
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
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 linux-kernel in
the body of a message to [EMAIL
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
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
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 into your tree?
We hope it adresses the major security co
offsets.
Roland, could you take this patchset into your tree?
We hope it adresses the major security concern and vm_insert_page.
We're preparing the next patch for the yield deadlock topic with this
patchset as prereq.
Gruss / Regards . . . Christoph Raisch
-
To unsubscribe from this list: send
ecause 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 [EMAIL PR
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 [EMAIL PROTECTED]
More majordomo info at http
hen does
> a remap_pfn_range into that anonymous vma.
We want to map bus adresses into userspace in this case...
...just as mmap from userspace... ?
> This is definitly not
> how the mmap infrastructure should be used.
>
> I'd go as far as saying do_mmap(_pgoff) should not be exporte
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
42 matches
Mail list logo
