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
On Fri, 24 Aug 2007, Kumar Gala wrote:
> 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
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 neede
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, th
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 in
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
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 f
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 ver
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
Linuxppc-dev@ozlab
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 inter
> 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. Since the folks who came up with the
> test c
> 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 so
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:
> ...
>
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_pd
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 enoug
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':
via-pmu.
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 mul
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 desig
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.
>
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 inc
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 n
On Fri, Aug 24, 2007 at 11:11:56PM +0200, Jan-Bernd Themann wrote:
> (when they are available for
> POWER in our case).
hrtimer worked fine on the powerpc cell arch last summer.
I assume they work on p5 and p6 too, no ??
> I tried to implement something with "normal" timers, but the result
> was
From: Jan-Bernd Themann <[EMAIL PROTECTED]>
Date: Fri, 24 Aug 2007 15:59:16 +0200
> 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 instance to the p
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 d
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 n
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 th
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 [Index
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.
On Fri, Aug 24, 2007 at 09:48:37AM -0500, Scott Wood wrote:
> 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.
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
Linuxppc-dev@
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 a
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 i
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
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=11159530601&r=1&w=2
Also, Jamal's paper may be of i
On Sat, Aug 25, 2007 at 11:10:13AM +1000, Paul Mackerras wrote:
> 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?
E.g. PM, PPC32, S
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 tha
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 get_paca()->kst
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
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 fo
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
https://
On Sat, Aug 25, Paul Mackerras wrote:
> 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?
The .config below boots on a wallstreet.
a
42 matches
Mail list logo
