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
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
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 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 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
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote on 16.10.2007
11:01:49:
Christoph, have any of you tried it on powerpc ?
No we didn't try this (yet).
This approach makes a lot of sense.
Why is this not installed by both large distros on PPC by default?
how mature is this for larger SMPs on
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
(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 netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
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 netdev in
the body of a message to [EMAIL PROTECTED
You should really do some measurements to see what the minimal
queue sizes are that can get you optimal throughput.
Arnd
we did.
And as always in performance tuning... one size fits all unfortunately is
not the correct answer.
Therefore we'll leave that open to the user as most other new
Hi,
I asked SO to recount arguments and we've come to a conclusion that
there're in fact 19 args not 18 as the name suggests. 19 args is
I-N-S-A-N-E.
It will be partially cleaned up by:
http://ozlabs.org/pipermail/linuxppc-dev/2006-July/024556.html
However it doesnt fix the fact
Jenkins, Clive wrote on 15.08.2006 12:53:05:
You mean the eHEA has its own concept of page size? Separate from
the
page size used by the MMU?
yes, the eHEA currently supports only 4K pages for queues
In that case, I suggest use the kernel's page size, but add a
compile-time
well, now I'm confused...
2 People, two opinions
Here's a URL for a complete tarball, sharing the download location with
our other driver.
http://prdownloads.sourceforge.net/ibmehcad/ehea_EHEA_0002.tgz
We're waiting for a sourceforge project now since 9 days to put out a tgz,
and it looks
on for example sourceforge?
Gruss / Regards . . . Christoph Raisch
christoph raisch, HCAD teamlead, IODF2 (d/3627), ibm boeblingen lab,
phone: (+49/0)7031-16 4584, fax: -16 2042, loc: 71032-05-003, internet:
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
16 matches
Mail list logo
