On Aug 24, 2007, at 2:10 AM, Geert Uytterhoeven wrote:
On Thu, 23 Aug 2007, Brad Boyer wrote:
Just as an extra note, the file drivers/macintosh/adb-iop.c is
m68k only,
so you should probably leave that alone as well. It probably
doesn't need
that header, but the change should really
On Thu, 23 Aug 2007, Brad Boyer wrote:
Just as an extra note, the file drivers/macintosh/adb-iop.c is m68k only,
so you should probably leave that alone as well. It probably doesn't need
that header, but the change should really come from the 68k side of things.
Thanks, it's indeed not needed.
On Fri, 2007-08-24 at 16:58 +1000, Michael Neuling wrote:
After talking to an IBM POWER hypervisor design and development (PHYP)
guy, there seems to be no need for memory barriers when updating the SLB
shadow buffer provided we only update it from the current CPU, which we
do.
Also, these
Hi,
when I tried to get the eHEA driver working with the new interface,
the following issues came up.
1) The current implementation of netif_rx_schedule, netif_rx_complete
and the net_rx_action have the following problem: netif_rx_schedule
sets the NAPI_STATE_SCHED flag and adds the NAPI
On Fri, Aug 24, 2007 at 11:01:22AM +1000, David Gibson wrote:
On Thu, Aug 23, 2007 at 12:48:30PM -0500, Scott Wood wrote:
It's likely to be ugly no matter what, though I'll try to come up with
something slightly nicer. If I were doing this code from scratch, I'd
probably liven the tree
Hi,
On Friday 24 August 2007 17:37, [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
...
3) On modern systems the incoming packets are processed very fast.
Especially
on SMP systems when we use multiple queues we process only a few
On Fri, 24 Aug 2007 17:47:15 +0200
Jan-Bernd Themann [EMAIL PROTECTED] wrote:
Hi,
On Friday 24 August 2007 17:37, [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
...
3) On modern systems the incoming packets are processed very fast.
Hi,
I was told Freescale's 8555CDS board is very similar to 8548CDS board. I
just wonder what exactly the differences are. can I just put the 8555CDS BSP
onto the 8548CDS board?
Thanks in advance,
Mike
___
Linuxppc-dev mailing list
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
3) On modern systems the incoming packets are processed very fast. Especially
on SMP systems when we use multiple queues we process only a few packets
per napi poll cycle. So NAPI does not work very well here and the
On Fri, Aug 24, 2007 at 08:52:03AM -0700, Stephen Hemminger wrote:
You need hardware support for deferred interrupts. Most devices have it
(e1000, sky2, tg3)
and it interacts well with NAPI. It is not a generic thing you want done by
the stack,
you want the hardware to hold off interrupts
Just to be clear, in the previous email I posted on this thread, I
described a worst-case network ping-pong test case (send a packet, wait
for reply), and found out that a deffered interrupt scheme just damaged
the performance of the test case.
When splitting rx and tx handler, I found some
James Chapman schrieb:
Stephen Hemminger wrote:
On Fri, 24 Aug 2007 17:47:15 +0200
Jan-Bernd Themann [EMAIL PROTECTED] wrote:
Hi,
On Friday 24 August 2007 17:37, [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
...
3) On modern systems the
On Fri, Aug 24, 2007 at 02:05:31PM +1000, Stephen Rothwell wrote:
On Thu, 23 Aug 2007 13:13:10 -0500 Olof Johansson [EMAIL PROTECTED] wrote:
out:
- pci_dev_put(mac-iob_pdev);
-out_put_dma_pdev:
- pci_dev_put(mac-dma_pdev);
-out_free_netdev:
+ if (mac-iob_pdev)
+
Segher Boessenkool wrote:
address-permutation = 0 1 3 2 4 5 7 6 e f d c a b 9 8;
Yes, I was contemplating something like that.
Let's not define this until we need it though :-)
Let's ot even think of it, since this will end up in a catch all driver,
and yet this may be not enough when
Current Linus tree fails to link on pmac32:
drivers/built-in.o: In function `pmac_wakeup_devices':
via-pmu.c:(.text+0x5bab4): undefined reference to `device_power_up'
via-pmu.c:(.text+0x5bb08): undefined reference to `device_resume'
drivers/built-in.o: In function `pmac_suspend_devices':
On Fri, Aug 24, 2007 at 09:04:56PM +0200, Bodo Eggert wrote:
Linas Vepstas [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
3) On modern systems the incoming packets are processed very fast.
Especially
on SMP systems when we use multiple queues
address-permutation = 0 1 3 2 4 5 7 6 e f d c a b 9 8;
Yes, I was contemplating something like that.
Let's not define this until we need it though :-)
Let's ot even think of it,
It is good to think about it, for the simple reason that it
validates whether the current design is
Linas Vepstas schrieb:
On Fri, Aug 24, 2007 at 09:04:56PM +0200, Bodo Eggert wrote:
Linas Vepstas [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
3) On modern systems the incoming packets are processed very fast.
Especially
on
Stephen Hemminger wrote:
On Fri, 24 Aug 2007 17:47:15 +0200
Jan-Bernd Themann [EMAIL PROTECTED] wrote:
Hi,
On Friday 24 August 2007 17:37, [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
...
3) On modern systems the incoming packets are
From: Jan-Bernd Themann [EMAIL PROTECTED]
Date: Fri, 24 Aug 2007 15:59:16 +0200
It would be nice if it is possible to schedule queues to other CPU's, or
at least to use interrupts to put the queue to another cpu (not nice for
as you never know which one you will hit).
I'm not
From: [EMAIL PROTECTED] (Linas Vepstas)
Date: Fri, 24 Aug 2007 11:45:41 -0500
In the end, I just let it be, and let the system work as a
busy-beaver, with the high interrupt rate. Is this a wise thing to
do?
The tradeoff is always going to be latency vs. throughput.
A sane default should
From: David Stevens [EMAIL PROTECTED]
Date: Fri, 24 Aug 2007 09:50:58 -0700
Problem is if it increases rapidly, you may drop packets
before you notice that the ring is full in the current estimated
interval.
This is one of many reasons why hardware interrupt mitigation
is really
From: James Chapman [EMAIL PROTECTED]
Date: Fri, 24 Aug 2007 18:16:45 +0100
Does hardware interrupt mitigation really interact well with NAPI?
It interacts quite excellently.
There was a long saga about this with tg3 and huge SGI numa
systems with large costs for interrupt processing, and the
This adds code to handle alignment traps generated by the following
SPE (signal processing engine) load/store instructions, by emulating
the instruction in the kernel (as is done for other instructions that
generate alignment traps):
evldd[x] Vector Load Double Word into Double Word
On Fri, Aug 24, 2007 at 02:44:36PM -0700, David Miller wrote:
From: David Stevens [EMAIL PROTECTED]
Date: Fri, 24 Aug 2007 09:50:58 -0700
Problem is if it increases rapidly, you may drop packets
before you notice that the ring is full in the current estimated
interval.
This is
Olaf Hering writes:
So change even more places from PM to PM_SLEEP to allow linking.
What config shows these errors? I presume you need to have CONFIG_PM
but not CONFIG_PM_SLEEP in order to see them?
Paul.
___
Linuxppc-dev mailing list
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
...
3) On modern systems the incoming packets are processed very fast. Especially
on SMP systems when we use multiple queues we process only a few packets
per napi poll cycle. So NAPI does not work very well here and
Stephen Hemminger [EMAIL PROTECTED] wrote on 08/24/2007
08:52:03 AM:
You need hardware support for deferred interrupts. Most devices have it
(e1000, sky2, tg3)
and it interacts well with NAPI. It is not a generic thing you want done
by the stack,
you want the hardware to hold off
Linas Vepstas [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
3) On modern systems the incoming packets are processed very fast. Especially
on SMP systems when we use multiple queues we process only a few packets
per napi poll cycle. So NAPI does
On Fri, Aug 24, 2007 at 02:47:11PM -0700, David Miller wrote:
Someone should reference that thread _now_ before this discussion goes
too far and we repeat a lot of information ..
Here's part of the thread:
http://marc.info/?t=11159530601r=1w=2
Also, Jamal's paper may be of
On Fri, 24 Aug 2007 13:11:04 -0500 Olof Johansson [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 02:05:31PM +1000, Stephen Rothwell wrote:
It is not documented as such (as far as I can see), but pci_dev_put is
safe to call with NULL. And there are other places in the kernel that
This partially reverts edd0622bd2e8f755c960827e15aa6908c3c5aa94.
It turns out that the part of that commit that aimed to ensure that we
created an SLB entry for the kernel stack on secondary CPUs when
starting the CPU didn't achieve its aim, and in fact caused a
regression, because
Jan-Bernd Themann wrote:
Introduces a module parameter to decide whether the physical
port link state is propagated to the network stack or not.
It makes sense not to take the physical port state into account
on machines with more logical partitions that communicate
with each other. This is
Kumar Gala wrote:
The ucc_geth_mii code is based on the gianfar_mii code that use to include
ocp.h. ucc never need this and it causes issues when we want to kill
arch/ppc includes from arch/powerpc.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Jeff, if you issue with this for 2.6.23,
Jan-Bernd Themann wrote:
Userspace DLPAR tool expects decimal numbers to be written to
and read from sysfs entries.
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
applied 1-3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
35 matches
Mail list logo
