WARNING: vmlinux.o(.text+0x8174): Section mismatch: reference to
.init.text:.prom_init (between '.__boot_from_prom' and '.__after_prom_start')
WARNING: vmlinux.o(.text+0x8498): Section mismatch: reference to
.init.text:.early_setup (between '.start_here_multiplatform' and
'.start_here_common')
W
On Monday 30 July 2007, Valentine Barshak wrote:
> A bootwrapper code for Sequoia.
>
> Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/44x.h |1
> arch/powerpc/boot/Makefile |6
> arch/powerpc/boot/cuboot-sequoia.c | 31
> arch
On Jul 30, 2007, at 8:50 PM, Stephen Rothwell wrote:
> Hi Kumar,
>
> [sorry for the slow reply]
>
> On Wed, 25 Jul 2007 01:49:04 -0500 (CDT) Kumar Gala
> <[EMAIL PROTECTED]> wrote:
>>
>> Paul said you were looking into this issue as well. Wanted to
>> post what I
>> did on ppc32/e500 as a st
Hi Sergei,
I did some further tests and some development work in past several
months,
but due to project schedule and limited bandwidth, no patches can be
submitted
to the list by now. Anyway, I will keep you and the community updated
once there
is some progress.
Thanks.
B.R.
Ebony
> -Orig
Hi Kumar,
[sorry for the slow reply]
On Wed, 25 Jul 2007 01:49:04 -0500 (CDT) Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> Paul said you were looking into this issue as well. Wanted to post what I
> did on ppc32/e500 as a start for you to look at. I think the other ppc32
> head*.S can follow the s
--- Linas Vepstas <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 30, 2007 at 01:17:40PM -0700, Dave Jiang wrote:
> > Arnd Bergmann wrote:
> > > The best solution may be to look at how it's structured at the
> > > register level. If the PCI EDAC registers are implemented separately
> > > from the regula
David Miller wrote:
> From: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Mon, 30 Jul 2007 12:17:58 -0400
>
>> David, thoughts on merging? I'm not We could stick this into your tree
>> or mine. Whether yours or mine, I would like to keep the driver and
>> net-core patches together in the same git tr
Linas Vepstas wrote:
> On Mon, Jul 30, 2007 at 01:17:40PM -0700, Dave Jiang wrote:
>> Arnd Bergmann wrote:
>>> The best solution may be to look at how it's structured at the
>>> register level. If the PCI EDAC registers are implemented separately
>>> from the regular PCI registers, a device tree en
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Mon, 30 Jul 2007 12:17:58 -0400
> David, thoughts on merging? I'm not We could stick this into your tree
> or mine. Whether yours or mine, I would like to keep the driver and
> net-core patches together in the same git tree.
No objections and I'll s
On Mon, Jul 30, 2007 at 01:17:40PM -0700, Dave Jiang wrote:
> Arnd Bergmann wrote:
> > The best solution may be to look at how it's structured at the
> > register level. If the PCI EDAC registers are implemented separately
> > from the regular PCI registers, a device tree entry would be appropriate
Jan-Bernd Themann wrote:
Hi,
this patch set contains the latest generic LRO code, a Kconfig / Makefile
and an eHEA patch demonstrating how the "aggregate SKB" interface has to
to be used.
Drew, could you provide a patch for the myri10ge driver to show how the
"receive in page" interface works?
Arnd Bergmann wrote:
> On Monday 30 July 2007, Dave Jiang wrote:
>> Maybe we are just better off adding entries in the DTS to get around this
>> problem
>
> The best solution may be to look at how it's structured at the
> register level. If the PCI EDAC registers are implemented separately
> f
Could someone add this to:
http://linux-net.osdl.org Wiki?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Monday 30 July 2007, Dave Jiang wrote:
> I don't believe that EDAC core has been loaded at the time of 85xx PCI
> initialization. Plus, the EDAC driver can be loaded as a kernel module. So
> that
> probably won't work
ok, good point.
> Also, instead of having centralized EDAC chip driver,
Kumar Gala wrote:
> Fix the following modpost warning:
>
> WARNING: vmlinux.o(.init.text+0x1aa6c): Section mismatch: reference to
> .exit.text:gfar_mdio_exit (between 'gfar_init' and 'gfar_mdio_init')
>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
> drivers/net/gianfar_mii.c |2 +-
--
Rodrigo Rubira Branco
Software Engineer
Advanced Linux Response Team (ALRT) / Linux on Power Toolchain
IBM Linux Technology Center (IBM/LTC)
[EMAIL PROTECTED]
GPG KeyID: 1FCEDEA1
Attached a patch to add Linux PPC 44x Hardware Watchpoints. It's an updated version of the work done by Michel
Arnd Bergmann wrote:
> On Monday 30 July 2007, Dave Jiang wrote:
>>> What about the other option I mentioned, handling the EDAC stuff from the
>>> fsl_add_bridge() function?
>> I'm not sure I follow your thought on this quite yet. Do you mean the setup
>> of
>> either of_device or platform_device
On Monday 30 July 2007, Dave Jiang wrote:
>
> > What about the other option I mentioned, handling the EDAC stuff from the
> > fsl_add_bridge() function?
>
> I'm not sure I follow your thought on this quite yet. Do you mean the setup of
> either of_device or platform_device or do you mean the actu
Here is a quick reply before something more official can
be written up:
Linas Vepstas wrote:
> -- what is LRO?
Large Receive Offload
> -- Basic principles of operation?
LRO is analogous to a receive side version of TSO. The NIC (or
driver) merges several consecutive segments from the same
Arnd Bergmann wrote:
> On Monday 30 July 2007, Dave Jiang wrote:
>> Arnd Bergmann wrote:
>
>>> I'd suggest either to integrate EDAC into the 85xx specific PCI code,
>>> or to have an extra device in the device tree for this.
>> How about I create a platform device just for EDAC and leave the PCI
On Monday 30 July 2007, Dave Jiang wrote:
> Arnd Bergmann wrote:
> > I'd suggest either to integrate EDAC into the 85xx specific PCI code,
> > or to have an extra device in the device tree for this.
>
> How about I create a platform device just for EDAC and leave the PCI of_device
> to the 85xx P
Jeff Garzik wrote:
> Stephen Hemminger wrote:
>> Why make this a user selectable option at all? Unless you want
>> to deal with out of tree drivers (not my problem), it should be hidden
>> to avoid having to explain an support it.
>
> In this case it's an optional library kernel module. That seem
Hi,
I am running linux-2.6.22.1-rt8 on mpc5200 and on running stress
./stress --cpu 8 --io 4 --vm 2 --vm-bytes 2M --timeout 300s
I get the following stack.But this does not happen with non rt kernel.
LR = 0xff51fcc
BUG: scheduling while atomic: stress/0x0002/739, CPU#0
Call Trace:
[c04fbb
On Mon, Jul 30, 2007 at 05:24:33PM +0200, Jan-Bernd Themann wrote:
>
> Changes to http://www.spinics.net/lists/netdev/msg36912.html
>
> 1) A new field called "features" has been added to the net_lro_mgr struct.
>It is set by the driver to indicate:
>- LRO_F_NAPI:Use NAPI / net
Jan-Bernd Themann wrote:
> Added LRO support using the "SKB aggregate" interface
>
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
>
> ---
> drivers/net/ehea/ehea.h |9 -
> drivers/net/ehea/ehea_ethtool.c | 15 +++
> drivers/net/ehea/ehea_main.c| 82 +++
Arnd Bergmann wrote:
> On Friday 27 July 2007, Dave Jiang wrote:
>> +static struct of_device_id mpc85xx_pci_err_of_match[] = {
>> + {
>> +.type = "pci",
>> +.compatible = "fsl,mpc8540-pci",
>> +},
>> + {},
>> +};
>> +
>> +static struct of_platform_driver mpc85xx_
Stephen Hemminger wrote:
> Why make this a user selectable option at all? Unless you want
> to deal with out of tree drivers (not my problem), it should be hidden
> to avoid having to explain an support it.
In this case it's an optional library kernel module. That seems to be a
common setup for
PPC44x cascade UIC irq handler fix.
According to PPC44x UM, if an interrupt is configured as level-sensitive,
and a clear is attempted on the UIC_SR, the UIC_SR field is not
cleared if the incoming interrupt signal is at the asserted polarity.
This causes us to enter a cascade handler twice, since
On Mon, 30 Jul 2007 17:24:45 +0200
Jan-Bernd Themann <[EMAIL PROTECTED]> wrote:
> Kconfig and Makefile for LRO
>
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
>
> ---
> net/ipv4/Kconfig |8
> net/ipv4/Makefile |1 +
> 2 files changed, 9 insertions(+), 0 deletions(-)
>
Seems pretty good to me, save for one minor detail: patches #1/#2
should be combined together for greater git-bisect happiness. Ditto for
patches #3/#4. Largely harmless in this case, but keeps the git history
pollution to a minimum.
Caveat reviewer: I'm not an expert of net/ipv4/* code, so
Added LRO support using the "SKB aggregate" interface
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |9 -
drivers/net/ehea/ehea_ethtool.c | 15 +++
drivers/net/ehea/ehea_main.c| 82 +++---
3 files chan
Kconfig changes for LRO
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f8a602c..fec4004 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfi
Generic Large Receive Offload for TCP traffic
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
include/linux/inet_lro.h | 173 ++
net/ipv4/inet_lro.c | 590 ++
2 files changed, 763 insertions(+), 0 deletions(-)
create mode 1
Kconfig and Makefile for LRO
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
net/ipv4/Kconfig |8
net/ipv4/Makefile |1 +
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index fb79097..d894f61 100644
--- a/net/ipv4/Kco
Hi,
this patch set contains the latest generic LRO code, a Kconfig / Makefile
and an eHEA patch demonstrating how the "aggregate SKB" interface has to
to be used.
Drew, could you provide a patch for the myri10ge driver to show how the
"receive in page" interface works?
Please check the Kconfig /
Fixed wrongly casted pointers
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c | 25 ++---
1 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 36ca322..9756211 100
Use shorter method to determine whether adapter has configured ports
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_ma
Fix: Workqueue ehea_driver_wq was not destroyed
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
inde
Sequoia defconfig
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/configs/sequoia_defconfig | 783 +
1 files changed, 783 insertions(+)
diff -ruN linux.orig/arch/powerpc/configs/sequoia_defconfig
linux/arch/powerpc/configs/sequoia_defconfig
AMCC Sequoia board DTS
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sequoia.dts | 292 ++
1 files changed, 292 insertions(+)
diff -ruN linux.orig/arch/powerpc/boot/dts/sequoia.dts
linux/arch/powerpc/boot/dts/sequoia.dts
---
The following patches add initial PowerPC 440EPx Sequoia board support.
The code is based mainly on the Bamboo board support by Josh Boyer.
Comments are welcome.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/lin
The patch adds PHY support for the Sequoia board to the new EMAC driver and
enables NEW_EMAC for 440EPx Kconfig.
The phy code has been written by Stefan Roese.
This has been tested with the following version of the EMAC dirver:
http://ozlabs.org/~dgibson/home/emac/powerpc-emac-new-20070516.patch
AMCC 440EPx Sequoia board support.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/cputable.c | 36 +++
arch/powerpc/kernel/head_44x.S |2 -
arch/powerpc/platforms/44x/Kconfig | 17 -
arch/powerpc/platforms/44x/Makefile |
A bootwrapper code for Sequoia.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/boot/44x.h |1
arch/powerpc/boot/Makefile |6
arch/powerpc/boot/cuboot-sequoia.c | 31
arch/powerpc/boot/sequoia.c | 234 ++
This patch adds DCR defines needed for 440EP/440EPx clock initialization.
These defines have been introduced in the Bamboo support by Josh Boyer
and are needed for Sequoia as well.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/
Hello.
Zhu Ebony-r57400 wrote:
>>Did you end up getting testfloat running? I'd like to see some
>>testing results before accepting these patches. I think estfloat is
>>our best bet at this point.
>Hi Kumar,
>I looked into the testfloat suit, and found all the instructions
Hi,
> BTW, does your SRQ-capable hardware support generating the "last WQE
> reached" event? There's not any reliable way to avoid problems when
> destroying QPs attached to an SRQ without it, and the IB spec requires
> CAs that support SRQs to generate it (o11-5.2.5 in chapter 11 of vol 1).
>
>
> Was going to recreate this patch, but then I saw that you
> probably have incorporated it (manually) in your latest git.
> Just want to make sure I'm seeing it right.
Yes, I ended up doing it by hand. Thanks.
___
Linuxppc-dev mailing list
Linuxppc-
Am Sunday 29 July 2007 19:04 schrieb René Rebe:
> Hi all,
>
> looking at the PS3 as one of the few PowerPC workstation options the RAM
> is obviously quite limitted with just 256MB. I wonder if the 256MB of
> video memory can be mapped or at least be used as super-fast SWAP?
look here:
http://foru
Hi Roland!
> the patch looks fine except your mailer seems to have mangled
> it... can you resend so I can apply it?
Was going to recreate this patch, but then I saw that you
probably have incorporated it (manually) in your latest git.
Just want to make sure I'm seeing it right.
Anyway, appreciate
Hi, Arnd,
I can change it as you metioned now.
Thanks!
-zw
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Arnd Bergmann
> Sent: Sunday, July 29, 2007 9:57 PM
> To: linuxppc-dev@ozlabs.org
> Cc: Zhang Wei-r63237; [EMAIL PROTECTED];
> [EMAIL PROTE
51 matches
Mail list logo
