Re: ramdisk size is larger than 4MB

2010-08-04 Thread Shawn Jin
 I did more debugging and something is really weird though. When the
 link address is changed to 0x80, when stepping through the kernel,
 I actually got the kernel boot successfully. However I let the kernel
 run through it would just crash. After crash the BDI2000 shows it
 stopped at __delay().

Well, actually it's nothing to do with gdb.

When the link address is changed to 0x80, if the PPC_EARLY_DEBUG
and PPC_EARLY_DEBUG_CPM are on, the built kernel can boot
successfully. But without these EARLY_DEBUG, the kernel fails to boot.

= bootm 500
## Booting image at 0500 ...
   Image Name:   Linux-2.6.33.5
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:1757354 Bytes =  1.7 MB
   Load Address: 0080
   Entry Point:  00800554
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Memory - 0x0 0x800 (128MB)
ENET0: local-mac-address - 00:09:9b:01:58:64
CPU clock-frequency - 0x7270e00 (120MHz)
CPU timebase-frequency - 0x7270e0 (8MHz)
CPU bus-frequency - 0x3938700 (60MHz)

zImage starting: loaded at 0x0080 (sp: 0x07d1cbd0)
Allocating 0x3a15a4 bytes for kernel ...
gunzipping (0x - 0x0080c000:0x00bd702c)...done 0x3886ec bytes

Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0xbe4300
^^The kernel stopped here.

= bootm 500
## Booting image at 0500 ...
   Image Name:   Linux-2.6.33.5
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:1757742 Bytes =  1.7 MB
   Load Address: 0080
   Entry Point:  00800554
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Memory - 0x0 0x800 (128MB)
ENET0: local-mac-address - 00:09:9b:01:58:64
CPU clock-frequency - 0x7270e00 (120MHz)
CPU timebase-frequency - 0x7270e0 (8MHz)
CPU bus-frequency - 0x3938700 (60MHz)

zImage starting: loaded at 0x0080 (sp: 0x07d1cbd0)
Allocating 0x3a15a4 bytes for kernel ...
gunzipping (0x - 0x0080c000:0x00bd702c)...done 0x3886ec bytes

Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0xbe4300
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
Using My MPC870 machine description
Linux version 2.6.33.5 (sh...@ubuntu) (gcc version 4.2.2) #5 Tue Aug 3
21:24:40 PDT 2010
bootconsole [udbg0] enabled
^The kernel continued booting.

With the EARLY_DEBUG turned on, the link address is changed to
0x100, the built kernel can also boot successfully.

However if the link address is changed to 0x200 or 0x400, the
built kernel fails to boot.

I think the kernel failure may be caused by some memory corruption.
But will the bootwrapper relocation corrupt the kernel code?

Thanks,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Booting MPC8377ERBD from NAND flash

2010-08-04 Thread Ravi Gupta
Hi,

I am trying to boot MPC8377ERBD freescale board from NAND flash. As per its
specifications, it supports NAND boot but it there is no support for NAND
boot in the BSP(confirmed with freescale also). Now I decided to modify BSP
myself to support NAND boot and I am confused that from where should I
start. Please suggest.

Thanks in advance
Ravi Gupta
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: 2.6.35-stable/ppc64/p7: Badness at lib/dma-debug.c:902, Call Trace Instruction Dump during boot

2010-08-04 Thread Roedel, Joerg
On Mon, Aug 02, 2010 at 07:55:03AM -0400, FUJITA Tomonori wrote:
 I guess that this driver does a partial sync with
 dma_sync_single_for_* API. dma-debug can't handle it properly. It's
 likely that this is a false warning.

If this turns out to be true it is not trivial to fix. I prepare a patch
to test for you.

Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries

2010-08-04 Thread Darren Hart

On 07/22/2010 03:25 PM, Benjamin Herrenschmidt wrote:

On Thu, 2010-07-22 at 11:24 -0700, Darren Hart wrote:


1) How can the preempt_count() get mangled across the H_CEDE hcall?
2) Should we call preempt_enable() in cpu_idle() prior to cpu_die() ?


The preempt count is on the thread info at the bottom of the stack.

Can you check the stack pointers ?


Hi Ben, sorry if I didn't get back to you on this already. I checked the 
stack pointer before and after the cede call and they match.


--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: 2.6.35-stable/ppc64/p7: Badness at lib/dma-debug.c:902, Call Trace Instruction Dump during boot

2010-08-04 Thread FUJITA Tomonori
On Wed, 4 Aug 2010 15:16:34 +0200
Roedel, Joerg joerg.roe...@amd.com wrote:

 On Mon, Aug 02, 2010 at 07:55:03AM -0400, FUJITA Tomonori wrote:
  I guess that this driver does a partial sync with
  dma_sync_single_for_* API. dma-debug can't handle it properly. It's
  likely that this is a false warning.
 
 If this turns out to be true it is not trivial to fix. I prepare a patch
 to test for you.

I've not looked at the details of this driver, but there are drivers
that do such. So dma-debug needs to be fixed anyway; you can't assume
that a DMA address that dma_map_single returned is passed to
dma_sync_single_for API.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc: Add vmcoreinfo symbols to allow makdumpfile to filter core files properly

2010-08-04 Thread Neil Horman
On Tue, Jul 13, 2010 at 09:46:09AM -0400, Neil Horman wrote:
 Hey all-
   About 2 years ago now, I sent this patch upstream to allow makedumpfile
 to properly filter cores on ppc64:
 http://www.mail-archive.com/ke...@lists.infradead.org/msg02426.html
 It got acks from the kexec folks so I pulled it into RHEL, but I never checked
 back here to make sure it ever made it in, which apparently it didn't.  It 
 still
 needs to be included, so I'm reposting it here, making sure to copy all the 
 ppc
 folks this time.  I've retested it on the latest linus kernel and it works 
 fine,
 allowing makedumpfile to find all the symbols it needs to properly strip a
 vmcore on ppc64.
 
 Neil
 
 Signed-off-by: Neil Horman nhor...@tuxdriver.com
 
 
  machine_kexec.c |   12 
  1 file changed, 12 insertions(+)
 
 
 diff --git a/arch/powerpc/kernel/machine_kexec.c 
 b/arch/powerpc/kernel/machine_kexec.c
 index bb3d893..0df7031 100644
 --- a/arch/powerpc/kernel/machine_kexec.c
 +++ b/arch/powerpc/kernel/machine_kexec.c
 @@ -45,6 +45,18 @@ void machine_kexec_cleanup(struct kimage *image)
   ppc_md.machine_kexec_cleanup(image);
  }
  
 +void arch_crash_save_vmcoreinfo(void)
 +{
 +
 +#ifdef CONFIG_NEED_MULTIPLE_NODES
 + VMCOREINFO_SYMBOL(node_data);
 + VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
 +#endif
 +#ifndef CONFIG_NEED_MULTIPLE_NODES
 + VMCOREINFO_SYMBOL(contig_page_data);
 +#endif
 +}
 +
  /*
   * Do not allocate memory (or fail in any way) in machine_kexec().
   * We are past the point of no return, committed to rebooting now.
 
 ___
 kexec mailing list
 ke...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/kexec
 

Ping yet again. Ben, This needs review/acceptance from you or Paul
Neil
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: Booting MPC8377ERBD from NAND flash

2010-08-04 Thread Jenkins, Clive
 I am trying to boot MPC8377ERBD freescale board from NAND flash.
 As per its specifications, it supports NAND boot but it there is
 no support for NAND boot in the BSP(confirmed with freescale also).
 Now I decided to modify BSP myself to support NAND boot and I am
 confused that from where should I start. Please suggest.

Read this
http://www.freescale.com/files/32bit/doc/app_note/AN3201.pdf
and other documentation on the Freescale site
 
Clive 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot

2010-08-04 Thread Subrata Modak
Peter/Li,

Did you get a chance to see this ?

Regards--
Subrata

On Mon, 2010-08-02 at 14:22 +0530, Subrata Modak wrote:
 Hi,
 
 The following suspicious rcu_dereference_check() usage is detected
 during 2.6.35-stable boot on my ppc64/p7 machine:
 
 ==
 [ INFO: suspicious rcu_dereference_check() usage. ]
 ---
 kernel/sched.c:616 invoked rcu_dereference_check() without protection!
 other info that might help us debug this:
 
 rcu_scheduler_active = 1, debug_locks = 0
 1 lock held by swapper/1:
  #0:  (rq-lock){-.}, at: [c07ca2f8] .init_idle+0x78/0x4a8
 stack backtrace:
 Call Trace:
 [c00f392bf990] [c0014f04] .show_stack+0xb0/0x1a0 (unreliable)
 [c00f392bfa50] [c07c87b4] .dump_stack+0x28/0x3c
 [c00f392bfad0] [c0103e1c] .lockdep_rcu_dereference+0xbc/0xe4
 [c00f392bfb70] [c07ca434] .init_idle+0x1b4/0x4a8
 [c00f392bfc30] [c07cad04] .fork_idle+0xa4/0xd0
 [c00f392bfe30] [c0aefaac] .smp_prepare_cpus+0x23c/0x2f4
 [c00f392bfed0] [c0ae1424] .kernel_init+0xec/0x32c
 [c00f392bff90] [c0033f40] .kernel_thread+0x54/0x70
 ==
 
 Please note that this was reported earlier on 2.6.34-rc6:
 http://marc.info/?l=linux-kernelm=127313031922395w=2,
 The issue was fixed with:
   commit 1ce7e4ff24fe338438bc7837e02780f202bf202b
   Author: Li Zefan l...@cn.fujitsu.com
   Date:   Fri Apr 23 10:35:52 2010 +0800
   cgroup: Check task_lock in task_subsys_state()
 
 According to:
   http://lkml.org/lkml/2010/7/1/883,
   commit dc61b1d65e353d638b2445f71fb8e5b5630f2415
   Author: Peter Zijlstra a.p.zijls...@chello.nl
   Date:   Tue Jun 8 11:40:42 2010 +0200
   sched: Fix PROVE_RCU vs cpu_cgroup
 should have fixed this. But this is reproducible on 2.6.35-stable.
 
 Please also see the config file attached.
 
 Regards--
 Subrata
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Booting MPC8377ERBD from NAND flash

2010-08-04 Thread Scott Wood
On Wed, 4 Aug 2010 15:34:59 +0100
Jenkins, Clive clive.jenk...@xerox.com wrote:

  I am trying to boot MPC8377ERBD freescale board from NAND flash.
  As per its specifications, it supports NAND boot but it there is
  no support for NAND boot in the BSP(confirmed with freescale also).
  Now I decided to modify BSP myself to support NAND boot and I am
  confused that from where should I start. Please suggest.
 
 Read this
 http://www.freescale.com/files/32bit/doc/app_note/AN3201.pdf
 and other documentation on the Freescale site

That's a bit outdated on the software side.  Look under the nand_spl
directory in u-boot; you should see several boards to use as examples.

If possible, I suggest working with the latest upstream u-boot rather
than what comes with the BSP.

If you have further questions, ask at u-b...@lists.denx.de.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/3] powerpc/85xx: Fix SWIOTLB initalization for MPC85xxMDS boards

2010-08-04 Thread Kumar Gala

On Jun 8, 2010, at 2:55 PM, Anton Vorontsov wrote:

 The code inside '#ifdef CONFIG_QUICC_ENGINE' makes the
 mpc85xx_mds_setup_arch() return early if no QE nodes present,
 and so SWIOTLB is never initialized.
 
 This patch fixes the issue by moving SWIOTLB code above
 QE.
 
 Signed-off-by: Anton Vorontsov avoront...@mvista.com
 ---
 arch/powerpc/platforms/85xx/mpc85xx_mds.c |   16 
 1 files changed, 8 insertions(+), 8 deletions(-)

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/3] powerpc/85xx: Fix booting for P1021MDS boards

2010-08-04 Thread Kumar Gala

On Jun 8, 2010, at 2:55 PM, Anton Vorontsov wrote:

 P1021 processors have no dedicated ROM to store the QE microcode,
 so the fimrware is stored externally, and it is U-Boot responsibility
 to load it. It might be that the board is booting without QE, e.g.
 currently U-Boot doesn't support QE for P1021MDS boards, which means
 that QE isn't initialized, and so the board hangs early at boot.
 
 This patch fixes the issue by marking QE as disabled and checking the
 state in the probing code. U-Boot should fixup the state if it
 initialized the QE.
 
 Signed-off-by: Anton Vorontsov avoront...@mvista.com
 ---
 arch/powerpc/boot/dts/p1021mds.dts|1 +
 arch/powerpc/platforms/85xx/mpc85xx_mds.c |   43 +
 2 files changed, 38 insertions(+), 6 deletions(-)

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 3/3] powerpc/85xx: Cleanup QE initialization for MPC85xxMDS boards

2010-08-04 Thread Kumar Gala

On Jun 8, 2010, at 2:55 PM, Anton Vorontsov wrote:

 The mpc85xx_mds_setup_arch() function is incomprehensible
 and unmaintainable. Factor out all QE specific stuff into
 mpc85xx_mds_qe_init() and mpc85xx_mds_reset_ucc_phys().
 
 Also move QE stuff out of mpc85xx_mds_pic_init().
 
 The diff is unreadable, but only because the code was so. ;-)
 It should be better now, and less indented.
 
 Signed-off-by: Anton Vorontsov avoront...@mvista.com
 ---
 arch/powerpc/platforms/85xx/mpc85xx_mds.c |  272 +++--
 1 files changed, 143 insertions(+), 129 deletions(-)

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/2] fsl_pci: add quirk for mpc8308 pcie bridge

2010-08-04 Thread Kumar Gala

On Jul 8, 2010, at 3:10 PM, Ilya Yanok wrote:

 This patch adds the quirk for PCIE controller found on Freescale MPC8308.
 The quirk is the same as for other MPC83xx processors.
 
 Signed-off-by: Ilya Yanok ya...@emcraft.com
 ---
 arch/powerpc/sysdev/fsl_pci.c |1 +
 include/linux/pci_ids.h   |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/2] mpc8308rdb: support for MPC8308RDB board from Freescale

2010-08-04 Thread Kumar Gala

On Jul 8, 2010, at 3:10 PM, Ilya Yanok wrote:

 This patch adds support for MPC8308RDB development board from
 Freescale.
 Supported devices:
 DUART
 Dual Ethernet
 NOR and NAND flashes
 I2C
 USB in peripheral mode
 
 PCIE support is broken by the commit 3da34aa (powerpc/fsl: Support
 unique MSI addresses per PCIe Root Complex). Works after revert.
 
 Signed-off-by: Ilya Yanok ya...@emcraft.com
 ---
 arch/powerpc/boot/dts/mpc8308rdb.dts  |  303 +
 arch/powerpc/platforms/83xx/Kconfig   |8 +
 arch/powerpc/platforms/83xx/Makefile  |1 +
 arch/powerpc/platforms/83xx/mpc830x_rdb.c |   94 +
 4 files changed, 406 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/mpc8308rdb.dts
 create mode 100644 arch/powerpc/platforms/83xx/mpc830x_rdb.c

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/2] tqm85xx: update PCI interrupt-map attribute

2010-08-04 Thread Kumar Gala

On Jul 21, 2010, at 3:33 PM, Dmitry Eremin-Solenikov wrote:

 Update PCI IRQ mapping on TQM85xx platforms: include INTC and INTD on PCI-X
 slot and add INTA/INTB mapping for PCMCIA bridge.
 
 Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
 ---
 arch/powerpc/boot/dts/tqm8540.dts  |9 -
 arch/powerpc/boot/dts/tqm8541.dts  |9 -
 arch/powerpc/boot/dts/tqm8548-bigflash.dts |9 -
 arch/powerpc/boot/dts/tqm8548.dts  |9 -
 arch/powerpc/boot/dts/tqm8555.dts  |9 -
 arch/powerpc/boot/dts/tqm8560.dts  |9 -
 6 files changed, 48 insertions(+), 6 deletions(-)

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/2] tqm85xx: add a quirk for ti1520 PCMCIA bridge

2010-08-04 Thread Kumar Gala

On Jul 21, 2010, at 3:33 PM, Dmitry Eremin-Solenikov wrote:

 By default ti1520 bridge expects an input clock on CLOCK pin (to control
 power chip). However on this boards CLOCK should be generated by PCI1520
 itself. Add a quirk that enables internal 16 KHz clock generation on
 this pin.
 
 Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
 ---
 arch/powerpc/platforms/85xx/tqm85xx.c |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] [v2] powerpc: introduce basic support for the Freescale P1022DS reference board

2010-08-04 Thread Kumar Gala

On Jul 2, 2010, at 5:25 PM, Timur Tabi wrote:

 Introduce basic support for the Freescale P1022DS reference board, based on 
 the
 Freescale BSP for this board.  This patch excludes the DIU, SSI, and MMC/SD
 drivers.  Only a 36-bit DTS is provided.
 
 Update mpc86xx_smp_defconfig and mpc85xx_defconfig to support the P1022DS.
 This means enabling 64-bit physical address support, increasing the maximum
 zone order to 12 (to allow the DIU driver to allocate large chunks), and
 clean up the audio options to disable the deprecated OSS support.
 
 Signed-off-by: Timur Tabi ti...@freescale.com
 ---
 
 This patch is for 2.6.36.
 
 arch/powerpc/boot/dts/p1022ds.dts  |  633 
 arch/powerpc/configs/mpc85xx_defconfig |   34 +-
 arch/powerpc/configs/mpc85xx_smp_defconfig |   34 +-
 arch/powerpc/platforms/85xx/Kconfig|8 +
 arch/powerpc/platforms/85xx/Makefile   |1 +
 arch/powerpc/platforms/85xx/p1022_ds.c |  148 +++
 6 files changed, 814 insertions(+), 44 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p1022ds.dts
 create mode 100644 arch/powerpc/platforms/85xx/p1022_ds.c

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/2] tqm85xx: add a quirk for ti1520 PCMCIA bridge

2010-08-04 Thread Kumar Gala

On Jul 21, 2010, at 3:33 PM, Dmitry Eremin-Solenikov wrote:

 By default ti1520 bridge expects an input clock on CLOCK pin (to control
 power chip). However on this boards CLOCK should be generated by PCI1520
 itself. Add a quirk that enables internal 16 KHz clock generation on
 this pin.
 
 Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
 ---
 arch/powerpc/platforms/85xx/tqm85xx.c |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2 1/2] DTS: Change deprecated binding for 85xx-based boards

2010-08-04 Thread Kumar Gala

On Jul 21, 2010, at 5:04 PM, Bradley Hughes wrote:

 The fsl,85... style compatible binding was to be deprecated
 some time ago.  This patch corrects existing occurrences of
 the incorrect binding.  The memory-controller and
 l2-cache-controller are the only affected nodes.
 
 Signed-off-by: Bradley Hughes bhug...@silicontkx.com
 ---
 arch/powerpc/boot/dts/mpc8540ads.dts |4 ++--
 arch/powerpc/boot/dts/mpc8541cds.dts |4 ++--
 arch/powerpc/boot/dts/mpc8544ds.dts  |4 ++--
 arch/powerpc/boot/dts/mpc8548cds.dts |4 ++--
 arch/powerpc/boot/dts/mpc8555cds.dts |4 ++--
 arch/powerpc/boot/dts/mpc8560ads.dts |4 ++--
 arch/powerpc/boot/dts/mpc8568mds.dts |4 ++--
 7 files changed, 14 insertions(+), 14 deletions(-)

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2 0/2] Adding DTS for the STx GP3-SSA MPC8555 board

2010-08-04 Thread Kumar Gala

On Jul 21, 2010, at 5:04 PM, Bradley Hughes wrote:

 This version uses fsl,mpc8555... instead of fsl,85... notation.
 
 There is also an 8541 version of this board so DTS for this board
 is specific to the 8555 processor.
 
 Another patch is coming to fix-up other DTS that use old notation.
 
 Signed-off-by: Bradley Hughes bhug...@silicontkx.com
 ---
 arch/powerpc/boot/dts/stxssa8555.dts |  380 ++
 1 files changed, 380 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/stxssa8555.dts

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: powerpc, 8xx: Add support for the MPC8xx based boards from TQC

2010-08-04 Thread Kumar Gala

On Mar 23, 2010, at 2:57 AM, Heiko Schocher wrote:

 Supported SMC1 (serial console), SCC1 Ethernet (10Mbps HD).
 FEC Ethernet, 8MB NOR CFI Flash.
 
 Tested on STK8xx with TQM860L (with FEC)
 and with TQM855M (without FEC).
 
 Signed-off-by: Heiko Schocher h...@denx.de
 ---
 - based against git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
  commit bca14dd14f3b0c5e3e2d1d314679f85b67871365
 - checked with checkpatch
  $ scripts/checkpatch.pl 
 0001-powerpc-8xx-Add-support-for-the-MPC8xx-based-board.patch
  total: 0 errors, 0 warnings, 1278 lines checked
 
  0001-powerpc-8xx-Add-support-for-the-MPC8xx-based-board.patch has no obvious 
 style problems and is ready for submission.
  $
 
 arch/powerpc/boot/dts/tqm8xx.dts  |  172 ++
 arch/powerpc/configs/tqm8xx_defconfig |  934 +
 arch/powerpc/platforms/8xx/Kconfig|6 +
 arch/powerpc/platforms/8xx/Makefile   |1 +
 arch/powerpc/platforms/8xx/tqm8xx_setup.c |  156 +
 5 files changed, 1269 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/tqm8xx.dts
 create mode 100644 arch/powerpc/configs/tqm8xx_defconfig
 create mode 100644 arch/powerpc/platforms/8xx/tqm8xx_setup.c

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RT,RFC] Hacks allowing -rt to run on POWER7 / Powerpc.

2010-08-04 Thread Will Schmidt
On Sun, 2010-07-11 at 02:49 -0500, Milton Miller wrote:
 On Fri, 09 Jul 2010 about 08:55:01 -, Will Schmidt wrote:
  We've been seeing some issues with userspace randomly SIGSEGV'ing while
  running the -RT kernels on POWER7 based systems.   After lots of
  debugging, head scratching, and experimental changes to the code, the
  problem has been narrowed down such that we can avoid the problems by
  disabling the TLB batching.
  
  After some input from Ben and further debug, we've found that the
  restoration of the batch-active value near the end of __switch_to()
  seems to be the key.( The -RT related  changes within
  arch/powerpc/kernel/processor.c __switch_to()  do the equivalent of a
  arch_leave_lazy_mmu_mode() before calling _switch, use a hadbatch flag
  to indicate if batching was active, and then restore that batch-active
  value on the way out after the call to _switch_to.That particular
  code is in the -RT branch, and not found in mainline  )
  
  Deferring to Ben (or others in the know) for whether this is the proper
  solution or if there is something deeper, but.. 

I believe this is still on Ben's list of things to look at.   Between
then and now, I'll see if I can get Thomas to pick this up for the -RT
tree to keep RT functional on P7 in the mean-time.  

A bit more debug info below.

 
 
 I looked at the patch and noticed 2 changes:
   1) the batch is checked and cleared after local_irq_save
   2) enabling the batch is skipped
 
 I talked to Will and had him try moving the local_irq_save above the
 check for the active batch.  That alone did not seem to be enough.
 However, he confirmed that we are setting batch to active when it is
 already active in lazy_mmu_enter, meaning that batching is being turned
 on recursively.  I suggested debug to check that irqs are off after the
 restore when re-enabling when our debug session timed out.

Based on some of the debug suggestions from Milton:


A WARN_ON for (!irqs_disabled) after local_irq_restore() did not show
any hits.  (while otherwise continuing to suffer from the tlb batching
troubles). 

---

hard_irq_disable();
last = _switch(old_thread, new_thread);

local_irq_restore(flags);

WARN_ON(!irqs_disabled());--


#if defined(CONFIG_PPC64)  defined(CONFIG_PREEMPT_RT)  1
if (hadbatch) {
batch = __get_cpu_var(ppc64_tlb_batch);
batch-active = 1;
}
#endif

 


Another assortment of WARN_ONs in the arch_{enter,leave}_lazy_mmu_mode
functions.  As Milton stated above, the check for batch-active on the
way into the arch_enter_* function did generate lots of hits, the other
warn_ons did not.


static inline void arch_enter_lazy_mmu_mode(void)
{
struct ppc64_tlb_batch *batch = get_cpu_var(ppc64_tlb_batch);

//|-WARN_ON(batch-active); /* lots of hits if enabled */
|---WARN_ON(irqs_disabled()); /* nothing */
|---batch-active = 1;




static inline void arch_leave_lazy_mmu_mode(void)
{
|---struct ppc64_tlb_batch *batch = get_cpu_var(ppc64_tlb_batch);

|---WARN_ON(!batch-active);/* nothing.*/
|---WARN_ON(irqs_disabled());/* nothing */





 
 milton
 
  
  diff -aurp linux-2.6.33.5-rt23.orig/arch/powerpc/kernel/process.c 
  linux-2.6.33.5-rt23.exp/arch/powerpc/kernel/process.c
  --- linux-2.6.33.5-rt23.orig/arch/powerpc/kernel/process.c  2010-06-21 
  11:41:34.402513904 -0500
  +++ linux-2.6.33.5-rt23.exp/arch/powerpc/kernel/process.c   2010-07-09 
  13:15:13.533269904 -0500
  @@ -304,10 +304,6 @@ struct task_struct *__switch_to(struct t
  struct thread_struct *new_thread, *old_thread;
  unsigned long flags;
  struct task_struct *last;
  -#if defined(CONFIG_PPC64)  defined (CONFIG_PREEMPT_RT)
  -   struct ppc64_tlb_batch *batch;
  -   int hadbatch;
  -#endif
   
   #ifdef CONFIG_SMP
  /* avoid complexity of lazy save/restore of fpu
  @@ -401,16 +397,6 @@ struct task_struct *__switch_to(struct t
  new_thread-start_tb = current_tb;
  }
   
  -#ifdef CONFIG_PREEMPT_RT
  -   batch = __get_cpu_var(ppc64_tlb_batch);
  -   if (batch-active) {
  -   hadbatch = 1;
  -   if (batch-index) {
  -   __flush_tlb_pending(batch);
  -   }
  -   batch-active = 0;
  -   }
  -#endif /* #ifdef CONFIG_PREEMPT_RT */
   #endif
   
  local_irq_save(flags);
  @@ -425,16 +411,13 @@ struct task_struct *__switch_to(struct t
   * of sync. Hard disable here.
   */
  hard_irq_disable();
  -   last = _switch(old_thread, new_thread);
  -
  -   local_irq_restore(flags);
   
   #if defined(CONFIG_PPC64)  defined(CONFIG_PREEMPT_RT)
  -   if (hadbatch) {
  -   batch = __get_cpu_var(ppc64_tlb_batch);
  -   batch-active = 1;
  -   }
  +   arch_leave_lazy_mmu_mode();
   #endif
  +   last = _switch(old_thread, new_thread);
  +
  +   local_irq_restore(flags);
   
  return last;

[git pull] Please pull powerpc.git next branch

2010-08-04 Thread Kumar Gala
The following changes since commit e8e5c2155b0035b6e04f29be67f6444bc914005b:
  Matt Evans (1):
powerpc/kexec: Fix orphaned offline CPUs across kexec

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next

Anton Vorontsov (3):
  powerpc/85xx: Fix SWIOTLB initalization for MPC85xxMDS boards
  powerpc/85xx: Fix booting for P1021MDS boards
  powerpc/85xx: Cleanup QE initialization for MPC85xxMDS boards

Bradley Hughes (2):
  powerpc/85xx: Change deprecated binding for 85xx-based boards
  powerpc/85xx: Adding DTS for the STx GP3-SSA MPC8555 board

Dmitry Eremin-Solenikov (2):
  powerpc/tqm85xx: update PCI interrupt-map attribute
  powerpc/tqm85xx: add a quirk for ti1520 PCMCIA bridge

Heiko Schocher (1):
  powerpc/8xx: Add support for the MPC8xx based boards from TQC

Ilya Yanok (2):
  powerpc/fsl_pci: add quirk for mpc8308 pcie bridge
  powerpc/mpc8308rdb: support for MPC8308RDB board from Freescale

Matthew McClintock (1):
  powerpc/85xx: kexec for SMP 85xx BookE systems

Timur Tabi (1):
  powerpc/85xx: Introduce support for the Freescale P1022DS reference board

 arch/powerpc/Kconfig   |   10 +-
 arch/powerpc/boot/dts/mpc8308rdb.dts   |  303 +
 arch/powerpc/boot/dts/mpc8540ads.dts   |4 +-
 arch/powerpc/boot/dts/mpc8541cds.dts   |4 +-
 arch/powerpc/boot/dts/mpc8544ds.dts|4 +-
 arch/powerpc/boot/dts/mpc8548cds.dts   |4 +-
 arch/powerpc/boot/dts/mpc8555cds.dts   |4 +-
 arch/powerpc/boot/dts/mpc8560ads.dts   |4 +-
 arch/powerpc/boot/dts/mpc8568mds.dts   |4 +-
 arch/powerpc/boot/dts/p1021mds.dts |1 +
 arch/powerpc/boot/dts/p1022ds.dts  |  633 +++
 arch/powerpc/boot/dts/stxssa8555.dts   |  380 +++
 arch/powerpc/boot/dts/tqm8540.dts  |9 +-
 arch/powerpc/boot/dts/tqm8541.dts  |9 +-
 arch/powerpc/boot/dts/tqm8548-bigflash.dts |9 +-
 arch/powerpc/boot/dts/tqm8548.dts  |9 +-
 arch/powerpc/boot/dts/tqm8555.dts  |9 +-
 arch/powerpc/boot/dts/tqm8560.dts  |9 +-
 arch/powerpc/boot/dts/tqm8xx.dts   |  172 +
 arch/powerpc/configs/mpc85xx_defconfig |   34 +-
 arch/powerpc/configs/mpc85xx_smp_defconfig |   34 +-
 arch/powerpc/configs/tqm8xx_defconfig  |  934 
 arch/powerpc/platforms/83xx/Kconfig|8 +
 arch/powerpc/platforms/83xx/Makefile   |1 +
 arch/powerpc/platforms/83xx/mpc830x_rdb.c  |   94 +++
 arch/powerpc/platforms/85xx/Kconfig|8 +
 arch/powerpc/platforms/85xx/Makefile   |1 +
 arch/powerpc/platforms/85xx/mpc85xx_mds.c  |  279 +
 arch/powerpc/platforms/85xx/p1022_ds.c |  148 +
 arch/powerpc/platforms/85xx/smp.c  |   63 ++
 arch/powerpc/platforms/85xx/tqm85xx.c  |   21 +
 arch/powerpc/platforms/8xx/Kconfig |6 +
 arch/powerpc/platforms/8xx/Makefile|1 +
 arch/powerpc/platforms/8xx/tqm8xx_setup.c  |  156 +
 arch/powerpc/sysdev/fsl_pci.c  |1 +
 include/linux/pci_ids.h|1 +
 36 files changed, 3185 insertions(+), 186 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/mpc8308rdb.dts
 create mode 100644 arch/powerpc/boot/dts/p1022ds.dts
 create mode 100644 arch/powerpc/boot/dts/stxssa8555.dts
 create mode 100644 arch/powerpc/boot/dts/tqm8xx.dts
 create mode 100644 arch/powerpc/configs/tqm8xx_defconfig
 create mode 100644 arch/powerpc/platforms/83xx/mpc830x_rdb.c
 create mode 100644 arch/powerpc/platforms/85xx/p1022_ds.c
 create mode 100644 arch/powerpc/platforms/8xx/tqm8xx_setup.c
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] arch/powerpc: Drop unnecessary of_node_put

2010-08-04 Thread Grant Likely
On Tue, Aug 3, 2010 at 1:50 PM, Julia Lawall ju...@diku.dk wrote:
 From: Julia Lawall ju...@diku.dk

 for_each_node_by_name only exits when its first argument is NULL, and a
 subsequent call to of_node_put on that argument is unnecessary.

 The semantic patch that makes this change is as follows:
 (http://coccinelle.lip6.fr/)

 // smpl
 @@
 iterator name for_each_node_by_name;
 expression np,E;
 identifier l;
 @@

 for_each_node_by_name(np,...) {
  ... when != break;
      when != goto l;
 }
 ... when != np = E
 - of_node_put(np);
 // /smpl

 Signed-off-by: Julia Lawall ju...@diku.dk

Looks correct to me:

Reviewed-by: Grant Likely grant.lik...@secretlab.ca


 ---
  arch/powerpc/platforms/powermac/feature.c |    1 -
  arch/powerpc/platforms/powermac/pci.c     |    2 --
  2 files changed, 3 deletions(-)

 diff -u -p a/arch/powerpc/platforms/powermac/feature.c 
 b/arch/powerpc/platforms/powermac/feature.c
 --- a/arch/powerpc/platforms/powermac/feature.c
 +++ b/arch/powerpc/platforms/powermac/feature.c
 @@ -2872,7 +2872,6 @@ set_initial_features(void)
                                core99_airport_enable(np, 0, 0);
                        }
                }
 -               of_node_put(np);
        }

        /* On all machines that support sound PM, switch sound off */
 diff -u -p a/arch/powerpc/platforms/powermac/pci.c 
 b/arch/powerpc/platforms/powermac/pci.c
 --- a/arch/powerpc/platforms/powermac/pci.c
 +++ b/arch/powerpc/platforms/powermac/pci.c
 @@ -1155,13 +1155,11 @@ void __init pmac_pcibios_after_init(void
                        pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, nd, 0, 0);
                }
        }
 -       of_node_put(nd);
        for_each_node_by_name(nd, ethernet) {
                if (nd-parent  of_device_is_compatible(nd, gmac)
                     of_device_is_compatible(nd-parent, uni-north))
                        pmac_call_feature(PMAC_FTR_GMAC_ENABLE, nd, 0, 0);
        }
 -       of_node_put(nd);
  }

  void pmac_pci_fixup_cardbus(struct pci_dev* dev)




-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/3 v2] dts: Add sdhci, auto-cmd12 field for p4080 device tree

2010-08-04 Thread Grant Likely
On Mon, Aug 2, 2010 at 9:11 PM, Roy Zang tie-fei.z...@freescale.com wrote:
 Signed-off-by: Roy Zang tie-fei.z...@freescale.com
 ---
  Documentation/powerpc/dts-bindings/fsl/esdhc.txt |    2 ++
  arch/powerpc/boot/dts/p4080ds.dts                |    1 +
  2 files changed, 3 insertions(+), 0 deletions(-)

 diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt 
 b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
 index 8a00407..64bcb8b 100644
 --- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
 +++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
 @@ -14,6 +14,8 @@ Required properties:
     reports inverted write-protect state;
   - sdhci,1-bit-only : (optional) specifies that a controller can
     only handle 1-bit data transfers.
 +  - sdhci,auto-cmd12: (optional) specifies that a controller can
 +    only handle auto CMD12.

I read this, but I still don't understand what it means.  What does
auto CMD12 mean?  Are there other kinds of CMD12?  Part of this
might be my ignorance about how eSDHC works, but it could be clearer.

Also, you can feel free to merge this patch with patch 1 in your
series.  I makes sense to update the documentation and the driver at
the same time.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver

2010-08-04 Thread Grant Likely
On Mon, Aug 2, 2010 at 9:11 PM, Roy Zang tie-fei.z...@freescale.com wrote:
 From: Jerry Huang chang-ming.hu...@freescale.com

 Add auto CMD12 command support for eSDHC driver.
 This is needed by P4080 and P1022 for block read/write.
 Manual asynchronous CMD12 abort operation causes protocol violations on
 these silicons.

 Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
 Signed-off-by: Roy Zang tie-fei.z...@freescale.com
 ---
  drivers/mmc/host/sdhci-of-core.c |    4 
  drivers/mmc/host/sdhci.c         |   14 --
  drivers/mmc/host/sdhci.h         |    2 ++
  3 files changed, 18 insertions(+), 2 deletions(-)

 diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
 index c6d1bd8..a92566e 100644
 --- a/drivers/mmc/host/sdhci.c
 +++ b/drivers/mmc/host/sdhci.c
 @@ -817,8 +817,12 @@ static void sdhci_set_transfer_mode(struct sdhci_host 
 *host,
        WARN_ON(!host-data);

        mode = SDHCI_TRNS_BLK_CNT_EN;
 -       if (data-blocks  1)
 -               mode |= SDHCI_TRNS_MULTI;
 +       if (data-blocks  1) {
 +               if (host-quirks  SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
 +                       mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_ACMD12;
 +               else
 +                       mode |= SDHCI_TRNS_MULTI;

nit:
+   mode |= SDHCI_TRNS_MULTI;
+   if (host-quirks  SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
+   mode |= SDHCI_TRNS_ACMD12;

Clearer, no?

 +       }
        if (data-flags  MMC_DATA_READ)
                mode |= SDHCI_TRNS_READ;
        if (host-flags  SDHCI_REQ_USE_DMA)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[git pull] Please pull powerpc.git next branch

2010-08-04 Thread Benjamin Herrenschmidt
Hi Linus !

Here's the batch of powerpc stuff for this merge window. Not major highlight,
some work on 64-bit Book3E (embedded) by myself, and the powerpc part of the
HW breakpoint stuff by Mohan Kumar and Paulus, and the usual batch of embedded
bits and pieces.

This does -not- include my memblock rework, which is in a separate branch
that I'm still sorting out due to clashes with ARM and some typos breaking
sh and microblaze. I'm not sure whether I'll send that this merge window
or just stick it into -next as soon as it's over. Peter Anvin also has some
interesting ideas to rewrite the memblock core into something more suitable
for handling allocations and take over the world :-)

Cheers,
Ben.

The following changes since commit 3a09b1be53d23df780a0cd0e4087a05e2ca4a00c:
  Linus Torvalds (1):
Merge git://git.kernel.org/.../steve/gfs2-2.6-nmw

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next

Adrian Alonso (1):
  of/xilinxfb: update tft compatible versions

Albrecht Dreß (2):
  powerpc/5200: improve uart baud rate calculation (reach high baud rates, 
better accuracy)
  powerpc/5200/i2c: improve i2c bus error recovery

Anatolij Gustschin (8):
  powerpc/512x: Group mpc512x board's selection menu
  powerpc/5121: add initial support for PDM360NG board
  powerpc/512x: add clock structure for Video-IN (VIU) unit
  powerpc/5121: fsl-diu-fb: fix issue with re-enabling DIU area descriptor
  powerpc/5121: move fsl-diu-fb.h to include/linux
  powerpc/5121: shared DIU framebuffer support
  powerpc/5121: doc/dts-bindings: update doc of FSL DIU bindings
  powerpc/fsl-diu-fb: Support setting display mode using EDID

Anton Blanchard (2):
  powerpc: Optimise per cpu accesses on 64bit
  powerpc/numa: Use form 1 affinity to setup node distance

Anton Vorontsov (4):
  powerpc: Fix GENERIC_ISA_DMA dependency
  powerpc/85xx: Fix SWIOTLB initalization for MPC85xxMDS boards
  powerpc/85xx: Fix booting for P1021MDS boards
  powerpc/85xx: Cleanup QE initialization for MPC85xxMDS boards

Becky Bruce (1):
  powerpc/fsl-booke: Fix comments in mmu code that mention BATS

Benjamin Herrenschmidt (17):
  Merge commit 'paulus-perf/master' into next
  powerpc/book3e: mtmsr should not be mtmsrd on book3e 64-bit
  powerpc/book3e: Hack to get gdb moving along on Book3E 64-bit
  powerpc/book3e: Move doorbell_exception from traps.c to dbell.c
  powerpc/book3e: More doorbell cleanups. Sample the PIR register
  powerpc/book3e: Don't re-trigger decrementer on lazy irq restore
  powerpc/book3e: Hookup doorbells exceptions on 64-bit Book3E
  powerpc/book3e: Add generic 64-bit idle powersave support
  powerpc/book3e: Fix single step when using HW page tables
  powerpc/book3e: Add TLB dump in xmon for Book3E
  powerpc/book3e: Adjust the page sizes list based on MMU config
  powerpc/oprofile: Don't build server oprofile drivers on 64-bit BookE
  Merge commit 'jwb/next' into next
  powerpc/pseries: Increase cpu die timeout
  powerpc/powermac: Add PowerMac10,2 machine descriptor
  Merge commit 'gcl/next' into next
  Merge commit 'kumar/next' into next

Bradley Hughes (2):
  powerpc/85xx: Change deprecated binding for 85xx-based boards
  powerpc/85xx: Adding DTS for the STx GP3-SSA MPC8555 board

Brian King (3):
  powerpc/pseries: Migration code reorganization / hibernation prep
  powerpc/pseries: Partition hibernation support
  powerpc: Remove redundant xics badness warning

Chris Metcalf (1):
  hvc_console: use *_console nomenclature to avoid modpost warning.

Christian Dietrich (1):
  Remove REDWOOD_[456] config options and conditional code

Christoph Egger (1):
  powerpc: Removing dead CONFIG_SMP_750

David Gibson (1):
  powerpc/book3e: Use set_irq_regs() in the msgsnd/msgrcv IPI path

Denis Kirjanov (1):
  powerpc/iseries: Fix constant warning

Dmitry Eremin-Solenikov (2):
  powerpc/tqm85xx: update PCI interrupt-map attribute
  powerpc/tqm85xx: add a quirk for ti1520 PCMCIA bridge

Heiko Schocher (1):
  powerpc/8xx: Add support for the MPC8xx based boards from TQC

Ilya Yanok (2):
  powerpc/fsl_pci: add quirk for mpc8308 pcie bridge
  powerpc/mpc8308rdb: support for MPC8308RDB board from Freescale

Joe Perches (1):
  powerpc: Remove unnecessary casts of private_data

Julia Lawall (2):
  powerpc/iseries: Use kstrdup
  powerpc/pseries: Use kstrdup

K.Prasad (5):
  hw_breakpoints: Allow arch-specific cleanup before breakpoint 
unregistration
  powerpc, hw_breakpoints: Implement hw_breakpoints for 64-bit server 
processors
  powerpc, hw_breakpoint: Handle concurrent alignment interrupts
  powerpc, hw_breakpoint: Enable hw-breakpoints while handling intervening 
signals
  powerpc, hw_breakpoint: Discard extraneous interrupt due to accesses 
outside symbol 

Re: [PATCH] powerpc: Add vmcoreinfo symbols to allow makdumpfile to filter core files properly

2010-08-04 Thread Benjamin Herrenschmidt
On Wed, 2010-08-04 at 10:49 -0400, Neil Horman wrote:
 Ping yet again. Ben, This needs review/acceptance from you or Paul
 Neil 

Isn't it already in powerpc-next about to be pulled by Linus ?

In general, I recommend you check the status of your patches on
patchwork. I'm nagging Jeremy to add a feature so it emails the
submitter when the patch status changes :-)

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver

2010-08-04 Thread Zang Roy-R61911
 

 -Original Message-
 From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On 
 Behalf Of Grant Likely
 Sent: Thursday, August 05, 2010 9:03 AM
 To: Zang Roy-R61911
 Cc: linux-...@vger.kernel.org; linuxppc-...@ozlabs.org; 
 a...@linux-foundation.org
 Subject: Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for 
 eSDHC driver
 
 On Mon, Aug 2, 2010 at 9:11 PM, Roy Zang 
 tie-fei.z...@freescale.com wrote:
  From: Jerry Huang chang-ming.hu...@freescale.com
 
  Add auto CMD12 command support for eSDHC driver.
  This is needed by P4080 and P1022 for block read/write.
  Manual asynchronous CMD12 abort operation causes protocol 
 violations on
  these silicons.
 
  Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
  Signed-off-by: Roy Zang tie-fei.z...@freescale.com
  ---
   drivers/mmc/host/sdhci-of-core.c |    4 
   drivers/mmc/host/sdhci.c         |   14 --
   drivers/mmc/host/sdhci.h         |    2 ++
   3 files changed, 18 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
  index c6d1bd8..a92566e 100644
  --- a/drivers/mmc/host/sdhci.c
  +++ b/drivers/mmc/host/sdhci.c
  @@ -817,8 +817,12 @@ static void 
 sdhci_set_transfer_mode(struct sdhci_host *host,
         WARN_ON(!host-data);
 
         mode = SDHCI_TRNS_BLK_CNT_EN;
  -       if (data-blocks  1)
  -               mode |= SDHCI_TRNS_MULTI;
  +       if (data-blocks  1) {
  +               if (host-quirks  
 SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
  +                       mode |= SDHCI_TRNS_MULTI | 
 SDHCI_TRNS_ACMD12;
  +               else
  +                       mode |= SDHCI_TRNS_MULTI;
 
 nit:
 +   mode |= SDHCI_TRNS_MULTI;
 +   if (host-quirks  SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
 +   mode |= SDHCI_TRNS_ACMD12;
 
 Clearer, no?
why?
Roy

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [Patch v2] kexec: increase max of kexec segments and use dynamic allocation

2010-08-04 Thread Cong Wang

(Ping Milton...)

On 07/29/10 14:42, Cong Wang wrote:

On 07/27/10 18:00, Milton Miller wrote:

[ Added kexec at lists.infradead.org and linuxppc-dev@lists.ozlabs.org ]



Currently KEXEC_SEGMENT_MAX is only 16 which is too small for machine
with
many memory ranges. When hibernate on a machine with disjoint memory
we do
need one segment for each memory region. Increase this hard limit to 16K
which is reasonably large.

And change -segment from a static array to a dynamically allocated
memory.

Cc: Neil Hormannhor...@redhat.com
Cc: huang yinghuang.ying.cari...@gmail.com
Cc: Eric W. Biedermanebied...@xmission.com
Signed-off-by: WANG Congamw...@redhat.com

---
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index ed31a29..f115585 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -131,10 +131,7 @@ static void copy_segments(unsigned long ind)
void kexec_copy_flush(struct kimage *image)
{
long i, nr_segments = image-nr_segments;
- struct kexec_segment ranges[KEXEC_SEGMENT_MAX];
-
- /* save the ranges on the stack to efficiently flush the icache */
- memcpy(ranges, image-segment, sizeof(ranges));
+ struct kexec_segment range;


I'm glad you found our copy on the stack and removed the stack overflow
that comes with this bump, but ...



/*
* After this call we may not use anything allocated in dynamic
@@ -148,9 +145,11 @@ void kexec_copy_flush(struct kimage *image)
* we need to clear the icache for all dest pages sometime,
* including ones that were in place on the original copy
*/
- for (i = 0; i nr_segments; i++)
- flush_icache_range((unsigned long)__va(ranges[i].mem),
- (unsigned long)__va(ranges[i].mem + ranges[i].memsz));
+ for (i = 0; i nr_segments; i++) {
+ memcpy(range,image-segment[i], sizeof(range));
+ flush_icache_range((unsigned long)__va(range.mem),
+ (unsigned long)__va(range.mem + range.memsz));
+ }
}


This is executed after the copy, so as it says,
we may not use anything allocated in dynamic memory.

We could allocate control pages to copy the segment list into.
Actually ppc64 doesn't use the existing control page, but that
is only 4kB today.

We need the list to icache flush all the pages in all the segments.
The as the indirect list doesn't have pages that were allocated at
their destination.

Or maybe the icache flush should be done in the generic code
like it does for crash load segments?



I don't get the point here, according to the comments,
it is copied into stack because of efficiency.




--
The opposite of love is not hate, it's indifference.
 - Elie Wiesel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port

2010-08-04 Thread Michael Neuling


In message 0ce8b6be3c4ad74ab97d9d29bd24e55201143...@corpexch1.na.ads.idt.com 
you wrote:
 Yang Li pointed to these patches in his post from July 23, 2010.
 It would be nice to have these patches in mainline code.=20

This is still broken in Kumar's latest tree.  Do you guys wanna repost
them so Kumar can pick them up easily?

Mikey

 
  -Original Message-
  From: timur.t...@gmail.com [mailto:timur.t...@gmail.com] On Behalf Of
 Timur Tabi
  Sent: Tuesday, August 03, 2010 9:02 AM
  To: Bounine, Alexandre
  Cc: Michael Neuling; Alexandre Bounine; linuxppc-dev@lists.ozlabs.org;
 linux-ker...@vger.kernel.org;
  thomas.m...@sysgo.com; Kumar Gala
  Subject: Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO
 port
 =20
  On Tue, Aug 3, 2010 at 7:17 AM, Bounine, Alexandre
  alexandre.boun...@idt.com wrote:
   This happened after change to book-e definitions.
   There are patches that address this issue.
 =20
  And those patches should have been applied before 2.6.35 was released.
   Someone dropped the ball.  2.6.35 is broken for a number of PowerPC
  boards:
 =20
  $ make mpc85xx_defconfig
  
  $ make
  
CC  arch/powerpc/sysdev/fsl_rio.o
  arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception':
  arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared
  (first use in this function)
  arch/powerpc/sysdev/fsl_rio.c:248: error: (Each undeclared identifier
  is reported only once
  arch/powerpc/sysdev/fsl_rio.c:248: error: for each function it appears
 in.)
  make[1]: *** [arch/powerpc/sysdev/fsl_rio.o] Error 1
 =20
  --
  Timur Tabi
  Linux kernel developer at Freescale
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Relocating bootwrapper causes kernel panic

2010-08-04 Thread Shawn Jin
Hi,

I'm trying to relocate the bootwrapper from the default address
(0x40) to a higher address (e.g. 0x80) in order to support a
larger than 4MB initramfs. However the kernel panic when trying to
access the device tree blob which was relocated accordingly to a
higher address. The kernel message from __log_buf is shown below.

The flat tree located at 0xbe4300 as the kerne message showed. Why
cannot the kernel access this area? No TLB set for this area?

1Unable to handle kernel paging request for data at address 0xc0be4308
1Faulting instruction address: 0xc01fdabc
4Oops: Kernel access of bad area, sig: 11 [#1]
4
4NIP: c01fdabc LR: c01fdc38 CTR: 
4REGS: c0383ee0 TRAP: 0300   Not tainted  (2.6.33.5)
4MSR: 1032 ME,IR,DR  CR: 28558922  XER: 0504
4DAR: c0be4308, DSISR: c000
4TASK = c0375328[0] 'swapper' THREAD: c0382000
4GPR00: c01fdc38 c0383f90 c0375328 c01fd4c8  
00be4300 0010
4GPR08: c01dbd94 c0be4300 0400   
07fff000 0001
4GPR16: 007fff0d 00800554 0001 007fff00 07ff9d78 
 07d5d2a0
4GPR24: 0891  c039 c01fd4c8  00be4300
 00be4300
4NIP [c01fdabc] of_scan_flat_dt+0x20/0x174
4LR [c01fdc38] early_init_devtree+0x28/0x288
4Call Trace:
4[c0383fb0] [c01fdc38] early_init_devtree+0x28/0x288
4[c0383fd0] [c01fe9c0] machine_init+0x20/0x5c
4[c0383ff0] [c0002244] start_here+0x48/0xc4
4Instruction dump:
47fe5fb78 4bfff899 90610008 4bfffeb4 9421ffe0 7c0802a6 bf410008 90010024
47c7b1b78 7c9c2378 3f40c039 813a9070 80090008 7fe90214 3860 3ba0
4---[ end trace 31fd0ba7d8756001 ]---
0Kernel panic - not syncing: Attempted to kill the idle task!
4Call Trace:
4[c0383dd0] [c0006c90] show_stack+0x40/0x168 (unreliable)
4[c0383e10] [c001cbfc] panic+0x8c/0x178
4[c0383e60] [c00209b0] do_exit+0x5c4/0x5d0
4[c0383ea0] [c000bb08] kernel_bad_stack+0x0/0x4c
4[c0383ec0] [c000ede8] bad_page_fault+0x90/0xd8
4[c0383ea0] [c000bb08] kernel_bad_stack+0x0/0x4c
4[c0383ec0] [c000ede8] bad_page_fault+0x90/0xd8
4[c0383ed0] [c000e2b8] handle_page_fault+0x7c/0x80
4[c0383f90] [] (null)
4[c0383fb0] [c01fdc38] early_init_devtree+0x28/0x288
4[c0383fd0] [c01fe9c0] machine_init+0x20/0x5c
4[c0383ff0] [c0002244] start_here+0x48/0xc4

The kernel message from uboot and the bootwrapper is shown below.
= bootm 500
## Booting image at 0500 ...
   Image Name:   Linux-2.6.33.5
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:1757351 Bytes =  1.7 MB
   Load Address: 0080
   Entry Point:  00800554
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Memory - 0x0 0x800 (128MB)
ENET0: local-mac-address - 00:09:9b:01:58:64
CPU clock-frequency - 0x7270e00 (120MHz)
CPU timebase-frequency - 0x7270e0 (8MHz)
CPU bus-frequency - 0x3938700 (60MHz)

zImage starting: loaded at 0x0080 (sp: 0x07d1cbd0)
Allocating 0x3a15a4 bytes for kernel ...
gunzipping (0x - 0x0080c000:0x00bd702c)...done 0x3886ec bytes

Linux/PowerPC load: root=/dev/ram
Finalizing device tree... flat tree at 0xbe4300

Thanks,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


kernel panic on MPC8323 custom board

2010-08-04 Thread Youngjin Na
Hi.. all

I'm porting the linux 2.6.27 kernel to the custom board with Freescale8270.
The base is the pq2fads board. The board is noproblem with linux-2.6.17.1
and linux-2.6.25.

When booting this machine, a crash takes place such as :



-

Using FCC1 ETHERNET device
TFTP from server 192.168.0.12; our IP address is 192.168.0.161
Filename 'cuImage.pq2fads'.
Load address: 0x10
Loading: #
done
Bytes transferred = 822097 (c8b51 hex)
[codec]$ bootm 10
## Booting kernel from Legacy Image at 0010 ...
   Image Name:   Linux-2.6.27
   Created:  2010-08-05   1:35:22 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:822033 Bytes = 802.8 kB
   Load Address: 0040
   Entry Point:  00400ba0
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
   Booting using board info...
Memory - 0x0 0x1000 (256MB)
CPU clock-frequency - 0x1ad27480 (450MHz)
CPU timebase-frequency - 0x17d7840 (25MHz)
CPU bus-frequency - 0x5f5e100 (100MHz)

zImage starting: loaded at 0x0040 (sp: 0x0ff65ac8)
Allocating 0x1e4924 bytes for kernel ...
gunzipping (0x - 0x0040d000:0x005da9f0)...done 0x1b3224 bytes

Linux/PowerPC load: root=/dev/nfs rw
nfsroot=192.168.0.12:/project/target/target_nadatel
ip=192.168.0.161:192.168.0.12:192.168.0.1::h264codec:eth0:off
Finalizing device tree... flat tree at 0x40c038
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
[0.00] Using Freescale PQ2FADS machine description
[0.00] Linux version 2.6.27 (v...@alinux) (gcc version 3.3.1
(MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #55 Thu Aug 5 10:35:18 KST
2010
[0.00] console [udbg0] enabled
setup_arch: bootmem
pq2fads_setup_arch()
pq2fads_setup_arch(), finish
arch: exit
[0.00] Top of RAM: 0x1000, Total RAM: 0x1000
[0.00] Memory hole size: 0MB
[0.00] Zone PFN ranges:
[0.00]   DMA  0x - 0x0001
[0.00]   Normal   0x0001 - 0x0001
[0.00]   HighMem  0x0001 - 0x0001
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[1] active PFN ranges
[0.00] 0: 0x - 0x0001
[0.00] On node 0 totalpages: 65536
[0.00] free_area_init_node: node 0, pgdat c01adb3c, node_mem_map
c01e7000
[0.00]   DMA zone: 65024 pages, LIFO batch:15
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total
pages: 65024
[0.00] Kernel command line: root=/dev/nfs rw
nfsroot=192.168.0.12:/project/target/target_nadatel
ip=192.168.0.161:192.168.0.12:192.168.0.1::h264codec:eth0:off
[0.00] PID hash table entries: 1024 (order: 10, 4096 bytes)
[0.00] time_init: decrementer frequency = 25.00 MHz
[0.00] time_init: processor frequency   = 450.00 MHz
[0.00] clocksource: timebase mult[a00] shift[22] registered
[0.038127] Dentry cache hash table entries: 32768 (order: 5, 131072
bytes)
[0.060153] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.134314] High memory: 0k
[0.141880] Memory: 257792k/262144k available (1648k kernel code, 4204k
reserved, 76k data, 194k bss, 124k init)
[0.172857] Calibrating delay loop... 49.79 BogoMIPS (lpj=24896)
[0.207709] Mount-cache hash table entries: 512
[0.234059] Unable to handle kernel paging request for data at address
0x0032
[0.255641] Faulting instruction address: 0xc0183c50
[0.270489] Oops: Kernel access of bad area, sig: 11 [#1]
[0.286545] Freescale PQ2FADS
[0.295392] Modules linked in:
[0.304504] NIP: c0183c50 LR: c0183ef4 CTR: 
[0.319345] REGS: cf821db0 TRAP: 0300   Not tainted  (2.6.27)
[0.336514] MSR: 9032 EE,ME,IR,DR  CR: 82004024  XER: 
[0.355515] DAR: 0032, DSISR: 2000
[0.367750] TASK = cf81f8a0[1] 'swapper' THREAD: cf82
[0.383362] GPR00: c0183ef4 cf821e60 cf81f8a0  c015e5e0 cf821ec0
0024 013f
[0.408348] GPR08: 3860ffda c01a 0002 8124000c 24004024 
0fffe000 11fc6000
[0.44] GPR16: fffb fcfd feff   0fff8c94
0002 0ff65e80
[0.458319] GPR24:    c01b cf821ec0 c01b
c01b cf821eb8
[0.483863] NIP [c0183c50] find_section32+0x14/0xb8
[0.498409] LR [c0183ef4] vdso_do_find_sections+0x28/0xc8
[0.514537] Call Trace:
[0.521839] [cf821e60] [c00f5ce8] kobject_uevent_env+0x2f4/0x318
(unreliable)
[0.543176] [cf821e90] [c0183ef4] vdso_do_find_sections+0x28/0xc8
[0.561394] [cf821eb0] [c01841b4] vdso_setup+0x2c/0xb8
[0.576749] [cf821f10] [c0184308] vdso_init+0x64/0x1dc
[0.592113] [cf821f30] [c0003904] do_one_initcall+0x54/0x184
[0.609022] [cf821fb0] [c017d848] do_initcalls+0x34/0x58
[0.624897] [cf821fd0] [c017d92c] kernel_init+0x40/0x94
[0.640528] [cf821ff0] 

[PATCH 0/4] powerpc: cpu offline/online fixes for CONFIG_PREEMPT

2010-08-04 Thread Darren Hart
The following patch series addresses several issues detected during intense CPU
offline/online testing on the mainline kernel with CONFIG_PREEMPT=y. These
patches require the following patch from Brian King:

http://patchwork.ozlabs.org/patch/59645/

Tested against linux-2.6.git master with and without CONFIG_DEBUG_PREEMPT.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 1/3] powerpc-enable-preemption-before-cpu_die

2010-08-04 Thread Darren Hart
From: Signed-off-by: Darren Hart dvh...@us.ibm.com

start_secondary() is called shortly after _start and also via

cpu_idle()-cpu_die()-pseries_mach_cpu_die()

start_secondary() expects a preempt_count() of 0. pseries_mach_cpu_die() is
called via the cpu_idle() routine with preemption disabled, resulting in the
following repeating message during rapid cpu offline/online tests
with CONFIG_PREEMPT=y:

BUG: scheduling while atomic: swapper/0/0x0002
Modules linked in: autofs4 binfmt_misc dm_mirror dm_region_hash dm_log [last 
unloaded: scsi_wait_scan]
Call Trace:
[c0010e7079c0] [c00133ec] .show_stack+0xd8/0x218 (unreliable)
[c0010e707aa0] [c06a47f0] .dump_stack+0x28/0x3c
[c0010e707b20] [c006e7a4] .__schedule_bug+0x7c/0x9c
[c0010e707bb0] [c0699d9c] .schedule+0x104/0x800
[c0010e707cd0] [c0015b24] .cpu_idle+0x1c4/0x1d8
[c0010e707d70] [c06aa1b4] .start_secondary+0x398/0x3d4
[c0010e707e30] [c0008278] .start_secondary_resume+0x10/0x14

Move the cpu_die() call inside the existing preemption enabled block of
cpu_idle(). This is safe as the idle task is affined to a single CPU so the
debug_smp_processor_id() tests (from cpu_should_die()) won't trigger as we are
in a migration disabled region.

Signed-off-by: Darren Hart dvh...@us.ibm.com
Acked-by: Will Schmidt will_schm...@vnet.ibm.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Nathan Fontenot nf...@austin.ibm.com
Cc: Robert Jennings r...@linux.vnet.ibm.com
Cc: Brian King brk...@linux.vnet.ibm.com
---
 arch/powerpc/kernel/idle.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index 049dda6..39a2baa 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -94,9 +94,9 @@ void cpu_idle(void)
HMT_medium();
ppc64_runlatch_on();
tick_nohz_restart_sched_tick();
+   preempt_enable_no_resched();
if (cpu_should_die())
cpu_die();
-   preempt_enable_no_resched();
schedule();
preempt_disable();
}
-- 
1.7.0.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 2/3] powerpc-silence-__cpu_up-under-normal-operation

2010-08-04 Thread Darren Hart
From: Signed-off-by: Darren Hart dvh...@us.ibm.com

During CPU offline/online tests __cpu_up would flood the logs with
the following message:

Processor 0 found.

This provides no useful information to the user as there is no context
provided, and since the operation was a success (to this point) it is expected
that the CPU will come back online, providing all the feedback necessary.

Change the Processor found message to DBG() similar to other such messages in
the same function. Also, add an appropriate log level for the Processor is
stuck message.

Signed-off-by: Darren Hart dvh...@us.ibm.com
Acked-by: Will Schmidt will_schm...@vnet.ibm.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Nathan Fontenot nf...@austin.ibm.com
Cc: Robert Jennings r...@linux.vnet.ibm.com
Cc: Brian King brk...@linux.vnet.ibm.com
---
 arch/powerpc/kernel/smp.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 5c196d1..cc05792 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -429,11 +429,11 @@ int __cpuinit __cpu_up(unsigned int cpu)
 #endif
 
if (!cpu_callin_map[cpu]) {
-   printk(Processor %u is stuck.\n, cpu);
+   printk(KERN_ERR Processor %u is stuck.\n, cpu);
return -ENOENT;
}
 
-   printk(Processor %u found.\n, cpu);
+   DBG(Processor %u found.\n, cpu);
 
if (smp_ops-give_timebase)
smp_ops-give_timebase();
-- 
1.7.0.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 3/3] powerpc-silence-xics_migrate_irqs_away-during-cpu-offline

2010-08-04 Thread Darren Hart
From: Signed-off-by: Darren Hart dvh...@us.ibm.com

All IRQs are migrated away from a CPU that is being offlined so the
following messages suggest a problem when the system is behaving as
designed:

IRQ 262 affinity broken off cpu 1
IRQ 17 affinity broken off cpu 0
IRQ 18 affinity broken off cpu 0
IRQ 19 affinity broken off cpu 0
IRQ 256 affinity broken off cpu 0
IRQ 261 affinity broken off cpu 0
IRQ 262 affinity broken off cpu 0

Don't print these messages when the CPU is not online.

Signed-off-by: Darren Hart dvh...@us.ibm.com
Acked-by: Will Schmidt will_schm...@vnet.ibm.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Nathan Fontenot nf...@austin.ibm.com
Cc: Robert Jennings r...@linux.vnet.ibm.com
Cc: Brian King brk...@linux.vnet.ibm.com
---
 arch/powerpc/platforms/pseries/xics.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/xics.c 
b/arch/powerpc/platforms/pseries/xics.c
index f19d194..8d0b0b1 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -930,8 +930,10 @@ void xics_migrate_irqs_away(void)
if (xics_status[0] != hw_cpu)
goto unlock;
 
-   printk(KERN_WARNING IRQ %u affinity broken off cpu %u\n,
-  virq, cpu);
+   /* This is expected during cpu offline. */
+   if (cpu_online(cpu))
+   printk(KERN_WARNING IRQ %u affinity broken off cpu 
%u\n,
+  virq, cpu);
 
/* Reset affinity to all cpus */
cpumask_setall(irq_to_desc(virq)-affinity);
-- 
1.7.0.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Request review of device tree documentation

2010-08-04 Thread David Gibson
On Fri, Jun 11, 2010 at 04:59:46PM -0600, Grant Likely wrote:
 I've been doing a bit of work on some introductory level documentation
 of the flattened device tree.  I've got a rough copy up on the
 devicetree.org wiki, and I could use some feedback.  If anyone has
 some time to look at it, you can find it here:
 
 http://devicetree.org/Device_Tree_Usage

Sorry I haven't replied sooner, I've been away, then sick and
generally preoccupied.  Still here are some comments now.

How Addressing Works:

 * Small inconsistency you use address1, address2 then unit-address3.

 * Perhaps re-emphasise that a parent's #*-cells properties govern the
   children's reg properties, not its own, since this is a common
   misunderstanding..

Non Memory Mapped Devices:

 * Your phrasing here suggests that non-memory-maped == zero
   size-cells, which is not always true.

Ranges (Address Translation):

 * Third paragraph, first sentence is a grammatical dogs' breakfast,

How Interrupts Work:

 * Bogus paragraph break partway through first sentence.

 * At the end you say the second cell indicates the interrupt's
   polarity, but you don't specify how this is encoded.  It might be
   worth emphasising that while most interrupt specifiers do include
   trigger and polarity type information, the encoding of it can and
   does vary between interrupt controllers.

Advanced Sample Machine:

 * The unit address in the name shouldn't have a 0x prefix

Advanced Interrupt Mapping:

 * Perhaps worth noting that while a PCI *card* will use INTA..INTD,
   on-board PCI devices can, and frequently do, have interrupts wired
   side-band to the PCI bus, directly to the main interrupt
   controller.

 * In your example, you're muddying the waters of your previous usage
   of interrupt-parent.  The PCI child nodes have the PCI top-level
   node as their implicit interrupt parent, because its their first
   ancestor with an interrupt-map, and we hit that before the
   interrupt-parent property specified at the very top level.  This
   means amongst other things that if there are PCI devices with
   seperately wired interrupts, they must explicitly set
   interrupt-parent to bypass the normal PCI interrupt mapping.


-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries

2010-08-04 Thread Darren Hart

On 07/23/2010 12:07 AM, Vaidyanathan Srinivasan wrote:

* Benjamin Herrenschmidtb...@kernel.crashing.org  [2010-07-23 15:11:00]:


On Fri, 2010-07-23 at 10:38 +0530, Vaidyanathan Srinivasan wrote:

Yes.  extended_cede_processor() will return with interrupts enabled in
the cpu. (This is done by the hypervisor).  Under normal cases we
cannot be interrupted because no IO interrupts are routed to us after
xics_teardown_cpu() and since the CPU is out of the map, nobody will
send us IPIs.


What about decrementer ?


Decrementer expiry event handling is bit complex.  The event as such
may not bring back the extended_cede_processor() cpu, but may be
marked pending when we get out of this state eventually.  I will find
more information on this event and update.


Hi Vaidy, have you been able to dig anything up about the decrementer 
expiry?


Thanks,

--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team





Though H_CEDE will return with interrupts enabled, it is unlikely that
an interrupt can be delivered in this context.


Well, if interrupts are soft-disabled, even if one occurs, we will just
mask and return, so that at least should be ok.


Yes.  We will immediately return to the extended_cede_processor() in
the while loop until the preferred_offline_state is changed.

--Vaidy



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/9] v4 Move the find_memory_block() routine up

2010-08-04 Thread KAMEZAWA Hiroyuki
On Tue, 03 Aug 2010 08:36:39 -0500
Nathan Fontenot nf...@austin.ibm.com wrote:

 Move the find_memory_block() routine up to avoid needing a forward
 declaration in subsequent patches.
 
 Signed-off-by: Nathan Fontenot nf...@austin.ibm.com

Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/9] v4 Add new phys_index properties

2010-08-04 Thread KAMEZAWA Hiroyuki
On Tue, 03 Aug 2010 08:37:31 -0500
Nathan Fontenot nf...@austin.ibm.com wrote:

 Update the 'phys_index' properties of a memory block to include a
 'start_phys_index' which is the same as the current 'phys_index' property.
 The property still appears as 'phys_index' in sysfs but the memory_block
 struct name is updated to indicate the start and end values.
 This also adds an 'end_phys_index' property to indicate the id of the
 last section in th memory block.
 
 Signed-off-by: Nathan Fontenot nf...@austin.ibm.com

Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com

nitpick. After this patch, end_phys_index is added but contains 0.
It's better to contain the same value with phys_index..

But, ok. Following patch will fix it.

Thanks,
-Kame

 ---
  drivers/base/memory.c  |   28 
  include/linux/memory.h |3 ++-
  2 files changed, 22 insertions(+), 9 deletions(-)
 
 Index: linux-2.6/drivers/base/memory.c
 ===
 --- linux-2.6.orig/drivers/base/memory.c  2010-08-02 13:32:21.0 
 -0500
 +++ linux-2.6/drivers/base/memory.c   2010-08-02 13:33:27.0 -0500
 @@ -109,12 +109,20 @@ unregister_memory(struct memory_block *m
   * uses.
   */
  
 -static ssize_t show_mem_phys_index(struct sys_device *dev,
 +static ssize_t show_mem_start_phys_index(struct sys_device *dev,
   struct sysdev_attribute *attr, char *buf)
  {
   struct memory_block *mem =
   container_of(dev, struct memory_block, sysdev);
 - return sprintf(buf, %08lx\n, mem-phys_index);
 + return sprintf(buf, %08lx\n, mem-start_phys_index);
 +}
 +
 +static ssize_t show_mem_end_phys_index(struct sys_device *dev,
 + struct sysdev_attribute *attr, char *buf)
 +{
 + struct memory_block *mem =
 + container_of(dev, struct memory_block, sysdev);
 + return sprintf(buf, %08lx\n, mem-end_phys_index);
  }
  
  /*
 @@ -128,7 +136,7 @@ static ssize_t show_mem_removable(struct
   struct memory_block *mem =
   container_of(dev, struct memory_block, sysdev);
  
 - start_pfn = section_nr_to_pfn(mem-phys_index);
 + start_pfn = section_nr_to_pfn(mem-start_phys_index);
   ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
   return sprintf(buf, %d\n, ret);
  }
 @@ -191,7 +199,7 @@ memory_block_action(struct memory_block
   int ret;
   int old_state = mem-state;
  
 - psection = mem-phys_index;
 + psection = mem-start_phys_index;
   first_page = pfn_to_page(psection  PFN_SECTION_SHIFT);
  
   /*
 @@ -264,7 +272,7 @@ store_mem_state(struct sys_device *dev,
   int ret = -EINVAL;
  
   mem = container_of(dev, struct memory_block, sysdev);
 - phys_section_nr = mem-phys_index;
 + phys_section_nr = mem-start_phys_index;
  
   if (!present_section_nr(phys_section_nr))
   goto out;
 @@ -296,7 +304,8 @@ static ssize_t show_phys_device(struct s
   return sprintf(buf, %d\n, mem-phys_device);
  }
  
 -static SYSDEV_ATTR(phys_index, 0444, show_mem_phys_index, NULL);
 +static SYSDEV_ATTR(phys_index, 0444, show_mem_start_phys_index, NULL);
 +static SYSDEV_ATTR(end_phys_index, 0444, show_mem_end_phys_index, NULL);
  static SYSDEV_ATTR(state, 0644, show_mem_state, store_mem_state);
  static SYSDEV_ATTR(phys_device, 0444, show_phys_device, NULL);
  static SYSDEV_ATTR(removable, 0444, show_mem_removable, NULL);
 @@ -476,16 +485,18 @@ static int add_memory_block(int nid, str
   if (!mem)
   return -ENOMEM;
  
 - mem-phys_index = __section_nr(section);
 + mem-start_phys_index = __section_nr(section);
   mem-state = state;
   mutex_init(mem-state_mutex);
 - start_pfn = section_nr_to_pfn(mem-phys_index);
 + start_pfn = section_nr_to_pfn(mem-start_phys_index);
   mem-phys_device = arch_get_memory_phys_device(start_pfn);
  
   ret = register_memory(mem, section);
   if (!ret)
   ret = mem_create_simple_file(mem, phys_index);
   if (!ret)
 + ret = mem_create_simple_file(mem, end_phys_index);
 + if (!ret)
   ret = mem_create_simple_file(mem, state);
   if (!ret)
   ret = mem_create_simple_file(mem, phys_device);
 @@ -507,6 +518,7 @@ int remove_memory_block(unsigned long no
   mem = find_memory_block(section);
   unregister_mem_sect_under_nodes(mem);
   mem_remove_simple_file(mem, phys_index);
 + mem_remove_simple_file(mem, end_phys_index);
   mem_remove_simple_file(mem, state);
   mem_remove_simple_file(mem, phys_device);
   mem_remove_simple_file(mem, removable);
 Index: linux-2.6/include/linux/memory.h
 ===
 --- linux-2.6.orig/include/linux/memory.h 2010-08-02 13:23:49.0 
 -0500
 +++ linux-2.6/include/linux/memory.h  2010-08-02 13:33:27.0 -0500
 @@ -21,7 +21,8 @@
  #include 

Re: [PATCH 3/9] v4 Add section count to memory_block

2010-08-04 Thread KAMEZAWA Hiroyuki
On Tue, 03 Aug 2010 08:38:37 -0500
Nathan Fontenot nf...@austin.ibm.com wrote:

 Add a section count property to the memory_block struct to track the number
 of memory sections that have been added/removed from a memory block. This
 allows us to know when the last memory section of a memory block has been
 removed so we can remove the memory block.
 
 Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 4/9] v4 Add mutex for add/remove of memory blocks

2010-08-04 Thread KAMEZAWA Hiroyuki
On Tue, 03 Aug 2010 08:39:50 -0500
Nathan Fontenot nf...@austin.ibm.com wrote:

 Add a new mutex for use in adding and removing of memory blocks.  This
 is needed to avoid any race conditions in which the same memory block could
 be added and removed at the same time.
 
 Signed-off-by: Nathan Fontenot nf...@austin.ibm.com

Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com

But a nitpick (see below)

 ---
  drivers/base/memory.c |9 +
  1 file changed, 9 insertions(+)
 
 Index: linux-2.6/drivers/base/memory.c
 ===
 --- linux-2.6.orig/drivers/base/memory.c  2010-08-02 13:35:00.0 
 -0500
 +++ linux-2.6/drivers/base/memory.c   2010-08-02 13:45:34.0 -0500
 @@ -27,6 +27,8 @@
  #include asm/atomic.h
  #include asm/uaccess.h
  
 +static struct mutex mem_sysfs_mutex;
 +

For static symbol of mutex, we usually do
static DEFINE_MUTEX(mem_sysfs_mutex);

Then, extra calls of mutex_init() is not required.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Help with an odd problem sharing memory on the ppc460ex

2010-08-04 Thread Ayman El-Khashab
 I've got custom boards that have been running for a while on rev A 
460ex parts but when the rev B parts became available some problems 
surfaced.  We are trying to work around the issues in software.  To make 
this simple, I've got 2 460exs connected together via PCI and PCIe so i 
can switch the transport.  For now, I am using PCI.  I've setup the PIMs 
and POMs to map one CPUs DRAM across the bus to the other CPU.  So they 
have a sort of shared memory scheme.  This works fine in many cases.


I think I have a caching problem though even though I think the cache is 
disabled via u-boot.  What happens is that CPU0 will write into CPU1's 
memory.  CPU1 will still see a stale value though ... I can't figure out 
how this happens.  If CPU0 comes back and reads from CPU1's memory 
though, it gets the correct value.   Now if I reduce the frequency of 
the reads/writes to something low (maybe 1 or 2 per second), then very 
often CPU1 will see the change.  I continue to think it is a cache 
issue, but I am not sure.  Also not sure how to work around that.  Is 
that something I need to do via the TLBs?  Is the cache really disabled 
or does Linux mess with the TLB/cache settings?  When I boot Linux I 
reserve the upper 16Mb of memory (from 112-128Mb space) and then mmap 
that entire region into CPU1's space.  Not sure if when it is reserved 
if it is treated differently by Linux or not.


Any help is greatly appreciated.

Thanks
Ayman
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 5/9] v4 Allow memory_block to span multiple memory sections

2010-08-04 Thread KAMEZAWA Hiroyuki
On Tue, 03 Aug 2010 08:40:49 -0500
Nathan Fontenot nf...@austin.ibm.com wrote:

 Update the memory sysfs code that each sysfs memory directory is now
 considered a memory block that can contain multiple memory sections per
 memory block.  The default size of each memory block is SECTION_SIZE_BITS
 to maintain the current behavior of having a single memory section per
 memory block (i.e. one sysfs directory per memory section).
 
 For architectures that want to have memory blocks span multiple
 memory sections they need only define their own memory_block_size_bytes()
 routine.
 
 Signed-off-by: Nathan Fontenot nf...@austin.ibm.com

Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
(But maybe it's better to get ppc guy's Ack.)


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 6/9] v4 Update the find_memory_block declaration

2010-08-04 Thread KAMEZAWA Hiroyuki
On Tue, 03 Aug 2010 08:41:45 -0500
Nathan Fontenot nf...@austin.ibm.com wrote:

 Update the find_memory_block declaration to to take a struct mem_section *
 so that it matches the definition.
 
 Signed-off-by: Nathan Fontenot nf...@austin.ibm.com

Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com

Hmm...my mmotm-0727 has this definition in memory.h...

extern struct memory_block *find_memory_block(struct mem_section *);

What patch makes it unsigned long ?

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 7/9] v4 Update the node sysfs code

2010-08-04 Thread KAMEZAWA Hiroyuki
On Tue, 03 Aug 2010 08:42:35 -0500
Nathan Fontenot nf...@austin.ibm.com wrote:

 Update the node sysfs code to be aware of the new capability for a memory
 block to contain multiple memory sections.  This requires an additional
 parameter to unregister_mem_sect_under_nodes so that we know which memory
 section of the memory block to unregister.
 
 Signed-off-by: Nathan Fontenot nf...@austin.ibm.com

Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 9/9] v4 Update memory-hotplug documentation

2010-08-04 Thread KAMEZAWA Hiroyuki
On Tue, 03 Aug 2010 08:44:16 -0500
Nathan Fontenot nf...@austin.ibm.com wrote:

 Update the memory hotplug documentation to reflect the new behaviors of
 memory blocks reflected in sysfs.
 
 Signed-off-by: Nathan Fontenot nf...@austin.ibm.com

Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com

A request from me:

 Could you clarify what happens if there are memory hole in [start 
end)_phys_index.
 in Documentation ? (Or add TODO list.)

Thanks,
-Kame


 ---
  Documentation/memory-hotplug.txt |   40 
 +++
  1 file changed, 24 insertions(+), 16 deletions(-)
 
 Index: linux-2.6/Documentation/memory-hotplug.txt
 ===
 --- linux-2.6.orig/Documentation/memory-hotplug.txt   2010-08-02 
 14:09:28.0 -0500
 +++ linux-2.6/Documentation/memory-hotplug.txt2010-08-02 
 14:10:36.0 -0500
 @@ -126,36 +126,44 @@ config options.
  
  4 sysfs files for memory hotplug
  
 -All sections have their device information under /sys/devices/system/memory 
 as
 +All sections have their device information in sysfs.  Each section is part of
 +a memory block under /sys/devices/system/memory as
  
  /sys/devices/system/memory/memoryXXX
 -(XXX is section id.)
 +(XXX is the section id.)
  
 -Now, XXX is defined as start_address_of_section / section_size.
 +Now, XXX is defined as (start_address_of_section / section_size) of the first
 +section contained in the memory block.
  
  For example, assume 1GiB section size. A device for a memory starting at
  0x1 is /sys/device/system/memory/memory4
  (0x1 / 1Gib = 4)
  This device covers address range [0x1 ... 0x14000)
  
 -Under each section, you can see 4 files.
 +Under each section, you can see 5 files.
  
 -/sys/devices/system/memory/memoryXXX/phys_index
 +/sys/devices/system/memory/memoryXXX/start_phys_index
 +/sys/devices/system/memory/memoryXXX/end_phys_index
  /sys/devices/system/memory/memoryXXX/phys_device
  /sys/devices/system/memory/memoryXXX/state
  /sys/devices/system/memory/memoryXXX/removable
  
 -'phys_index' : read-only and contains section id, same as XXX.
 -'state'  : read-write
 -   at read:  contains online/offline state of memory.
 -   at write: user can specify online, offline command
 -'phys_device': read-only: designed to show the name of physical memory 
 device.
 -   This is not well implemented now.
 -'removable'  : read-only: contains an integer value indicating
 -   whether the memory section is removable or not
 -   removable.  A value of 1 indicates that the memory
 -   section is removable and a value of 0 indicates that
 -   it is not removable.
 +'phys_index'  : read-only and contains section id of the first section
 + in the memory block, same as XXX.
 +'end_phys_index'  : read-only and contains section id of the last section
 + in the memory block.
 +'state'   : read-write
 +at read:  contains online/offline state of memory.
 +at write: user can specify online, offline command
 +which will be performed on al sections in the block.
 +'phys_device' : read-only: designed to show the name of physical memory
 +device.  This is not well implemented now.
 +'removable'   : read-only: contains an integer value indicating
 +whether the memory block is removable or not
 +removable.  A value of 1 indicates that the memory
 +block is removable and a value of 0 indicates that
 +it is not removable. A memory block is removable only if
 +every section in the block is removable.
  
  NOTE:
These directories/files appear after physical memory hotplug phase.
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Relocating bootwrapper causes kernel panic

2010-08-04 Thread Shawn Jin
 I'm trying to relocate the bootwrapper from the default address
 (0x40) to a higher address (e.g. 0x80) in order to support a
 larger than 4MB initramfs. However the kernel panic when trying to
 access the device tree blob which was relocated accordingly to a
 higher address. The kernel message from __log_buf is shown below.

 The flat tree located at 0xbe4300 as the kerne message showed. Why
 cannot the kernel access this area? No TLB set for this area?

 1Unable to handle kernel paging request for data at address 0xc0be4308
 1Faulting instruction address: 0xc01fdabc
 4Oops: Kernel access of bad area, sig: 11 [#1]

Before the flat tree was accessed, I checked the DTLB and didn't find
any entry related to 0xc0be4300. After the exception, I found the
following DTLBs.

30 : 02  c0be4000   4KB -- - 
31 : 00  fa00   8MB VI-S-M - fa00

The DTLB#30 doesn't seem right. Why would it map to 0x0? I think this
should be something like 00be4000?

Thanks,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[linux-next] build failure

2010-08-04 Thread divya

Yestersday's linux-next(2.6.35_next_20100802) build fails with the following 
error on both system p and x.


  drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_select_queue':
  drivers/net/ixgbe/ixgbe_main.c:6159: error: 'struct ixgbe_fcoe' has no member 
named 'up'
  drivers/net/ixgbe/ixgbe_main.c: In function 'ixgbe_xmit_frame':
  drivers/net/ixgbe/ixgbe_main.c:6221: error: 'struct ixgbe_fcoe' has no member 
named 'up'
  make[3]: *** [drivers/net/ixgbe/ixgbe_main.o] Error 1
  make[2]: *** [drivers/net/ixgbe] Error 2
  make[2]: *** Waiting for unfinished jobs
  make[1]: *** [drivers/net] Error 2
  make: *** [drivers] Error 2

Thanks
Divya



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev