Re: checkpatch nits ...

2008-08-28 Thread Andy Whitcroft 
On Wed, Aug 27, 2008 at 09:49:44AM +0200, Wolfram Sang wrote:
 On Sat, Aug 23, 2008 at 10:57:21AM +0200, Arnd Bergmann wrote:
 
  On Saturday 23 August 2008, Kevin Diggs wrote:
   WARNING: externs should be avoided in .c files
   #1137: FILE: powerpc/kernel/cpu/pll_if.c:369:
   +       __asm__ __volatile__ (
   
   ??? I don't know what this is?
   
   The entire block is:
   
   __asm__ __volatile__ (
   addi %0,%3,-1\n
   andc %1,%3,%0\n
   cntlzw %1,%1\n
   subfic %1,%1,31\n
   cntlzw %0,%2\n:
   =r(cntlz), =r(cnttz):
   r(tmp), b(cnttz)
   );
   
  
  It's a bug in checkpatch, your code is correct (although I would write
  asm volatile, not __asm__ __volatile__, and add \t after each \n).
  Can you explain why you need that inline assembly? All you do in there
  are arithmetic operations, so you should be able to express that using
  C, or at least using the helpers we already have.
  
  Checkpatch thinks that what you wrote is a declaration for a function
  named __volatile__ returning a variable of type __asm__, and complains
  that this declaration belongs into a header file.
 
 I wonder if checkpatch-maintainers read this list, so I put Andy
 Whitcroft to CC.

Thanks for the Cc:, even if you do read the lists you can easily miss
something of direct interest.

I actually think I saw a previous patch flow past showing this issue and
there appears to be a specific exception for __asm__ never being a type.
Cirtainly this fragment does not throw the error with the latest
checkpatch in my tree.  That fix appears to have gone in in 0.20.  Could
you check which version you have, the version number appears in the
usage message when checkpatch is invoked without parameters.  Also give
the version at the URL below a go, it represents the current development
copy.

  
http://www.kernel.org/pub/linux/kernel/people/apw/checkpatch/checkpatch.pl-testing

Thanks for the report.

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

[PATCH 1/1] powerpc: add 64 bit version of huge_ptep_set_wrprotect

2008-06-26 Thread Andy Whitcroft 
The implementation of huge_ptep_set_wrprotect() directly calls
ptep_set_wrprotect() to mark a hugepte write protected.  However this
call is not appropriate on ppc64 kernels as this is a small page only
implementation.  This can lead to the hash not being flushed correctly
when a mapping is being converted to COW, allowing processes to continue
using the original copy.

Currently huge_ptep_set_wrprotect() unconditionally calls
ptep_set_wrprotect().  This is fine on ppc32 kernels as this call is
generic.  On 64 bit this is implemented as:

pte_update(mm, addr, ptep, _PAGE_RW, 0);

On ppc64 this last parameter is the page size and is passed directly on
to hpte_need_flush():

hpte_need_flush(mm, addr, ptep, old, huge);

And this directly affects the page size we pass to flush_hash_page():

flush_hash_page(vaddr, rpte, psize, ssize, 0);

As this changes the way the hash is calculated we will flush the wrong
pages, potentially leaving live hashes to the original page.

Move the definition of huge_ptep_set_wrprotect() to the 32/64 bit specific
headers.

Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
---
 include/asm-powerpc/hugetlb.h   |6 --
 include/asm-powerpc/pgtable-ppc32.h |6 ++
 include/asm-powerpc/pgtable-ppc64.h |9 +
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/include/asm-powerpc/hugetlb.h b/include/asm-powerpc/hugetlb.h
index 649c6c3..be32ff0 100644
--- a/include/asm-powerpc/hugetlb.h
+++ b/include/asm-powerpc/hugetlb.h
@@ -49,12 +49,6 @@ static inline pte_t huge_pte_wrprotect(pte_t pte)
return pte_wrprotect(pte);
 }
 
-static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
-  unsigned long addr, pte_t *ptep)
-{
-   ptep_set_wrprotect(mm, addr, ptep);
-}
-
 static inline int huge_ptep_set_access_flags(struct vm_area_struct *vma,
 unsigned long addr, pte_t *ptep,
 pte_t pte, int dirty)
diff --git a/include/asm-powerpc/pgtable-ppc32.h 
b/include/asm-powerpc/pgtable-ppc32.h
index c08e714..eddad35 100644
--- a/include/asm-powerpc/pgtable-ppc32.h
+++ b/include/asm-powerpc/pgtable-ppc32.h
@@ -652,6 +652,12 @@ static inline void ptep_set_wrprotect(struct mm_struct 
*mm, unsigned long addr,
 {
pte_update(ptep, (_PAGE_RW | _PAGE_HWWRITE), 0);
 }
+static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
+  unsigned long addr, pte_t *ptep)
+{
+   ptep_set_wrprotect(mm, addr, ptep);
+}
+
 
 #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
 static inline void __ptep_set_access_flags(pte_t *ptep, pte_t entry, int dirty)
diff --git a/include/asm-powerpc/pgtable-ppc64.h 
b/include/asm-powerpc/pgtable-ppc64.h
index cc6a43b..9f7dbc2 100644
--- a/include/asm-powerpc/pgtable-ppc64.h
+++ b/include/asm-powerpc/pgtable-ppc64.h
@@ -313,6 +313,15 @@ static inline void ptep_set_wrprotect(struct mm_struct 
*mm, unsigned long addr,
return;
old = pte_update(mm, addr, ptep, _PAGE_RW, 0);
 }
+static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
+  unsigned long addr, pte_t *ptep)
+{
+   unsigned long old;
+
+   if ((pte_val(*ptep)  _PAGE_RW) == 0)
+   return;
+   old = pte_update(mm, addr, ptep, _PAGE_RW, 1);
+}
 
 /*
  * We currently remove entries from the hashtable regardless of whether
-- 
1.5.6.205.g7ca3a

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

Re: [PATCH] Discourage use of __initcall() in favour of device_initcall()

2008-05-16 Thread Andy Whitcroft 
On Fri, May 16, 2008 at 11:49:14AM +1000, Michael Ellerman wrote:
 Add a comment above the definition of __initcall(), just in case
 someone looks here.
 
 And add a checkpatch warning for new uses of __initcall().
 
 Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
 ---
 
 How's this? My perl skills are not good, but this seems to work.
 
  include/linux/init.h  |1 +
  scripts/checkpatch.pl |4 
  2 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/include/linux/init.h b/include/linux/init.h
 index 21d658c..6390e22 100644
 --- a/include/linux/init.h
 +++ b/include/linux/init.h
 @@ -193,6 +193,7 @@ extern void (*late_time_init)(void);
  #define late_initcall(fn)__define_initcall(7,fn,7)
  #define late_initcall_sync(fn)   __define_initcall(7s,fn,7s)
  
 +/* Please use device_initcall() directly in new code */
  #define __initcall(fn) device_initcall(fn)
  
  #define __exitcall(fn) \
 diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
 index b6bbbcd..3faff3f 100755
 --- a/scripts/checkpatch.pl
 +++ b/scripts/checkpatch.pl
 @@ -2026,6 +2026,10 @@ sub process {
   if ($line =~ /\bsimple_(strto.*?)\s*\(/) {
   WARN(consider using strict_$1 in preference to 
 simple_$1\n . $herecurr);
   }
 +# check for __initcall(), use device_initcall() explicitly please
 + if ($line =~ /^.\s*__initcall\(/) {

Well you should probabally allow spaces before the ( but otherwise its
in the spirit.

Checkpatch has its own tree as it has an extensive regression test
suite.  So I'll suck this half up into my tree and it'll be in the 0.20
update.

 + WARN(please use device_initcall() instead of 
 __initcall()\n . $herecurr);
 + }
  
  # use of NR_CPUS is usually wrong
  # ignore definitions of NR_CPUS and usage to define arrays as likely right

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

Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc

2008-04-04 Thread Andy Whitcroft 
On Tue, Apr 01, 2008 at 11:39:09PM -0700, Andrew Morton wrote:
 On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote:
 
  Hi Andrew,
  
  The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
  
  [0.00] [ cut here ]
  [0.00] kernel BUG at arch/powerpc/mm/init_64.c:240!
  [0.00] Oops: Exception in kernel mode, sig: 5 [#1]
  [0.00] SMP NR_CPUS=32 NUMA PowerMac
  [0.00] Modules linked in:
  [0.00] NIP: c03d1dcc LR: c03d1dc4 CTR: 
  c002b6ac
  [0.00] REGS: c049b960 TRAP: 0700   Not tainted  
  (2.6.25-rc8-mm1-autokern1)
  [0.00] MSR: 90021032 ME,IR,DR  CR: 4488  XER: 2000
  [0.00] TASK = c03f9c90[0] 'swapper' THREAD: 
  c0498000 CPU: 0
  [0.00] GPR00: c03d1dc4 c049bbe0 c04989d0 
  0001 
  [0.00] GPR04: d59aca40f000 0b00 0010 
   
  [0.00] GPR08: 0004 0001 c0027e520800 
  c04bf0f0 
  [0.00] GPR12: c04bf020 c03fa900  
   
  [0.00] GPR16:    
   
  [0.00] GPR20:    
  4140 
  [0.00] GPR24: 017d64b0 c03d6250  
  c0504000 
  [0.00] GPR28:  cf1f8000 0100 
  cf00 
  [0.00] NIP [c03d1dcc] .vmemmap_populate+0xb8/0xf4
  [0.00] LR [c03d1dc4] .vmemmap_populate+0xb0/0xf4
  [0.00] Call Trace:
  [0.00] [c049bbe0] [c03d1dc4] 
  .vmemmap_populate+0xb0/0xf4 (unreliable)
  [0.00] [c049bc70] [c03d2ee8] 
  .sparse_mem_map_populate+0x38/0x60
  [0.00] [c049bd00] [c03c242c] 
  .sparse_early_mem_map_alloc+0x54/0x94
  [0.00] [c049bd90] [c03c250c] .sparse_init+0xa0/0x20c
  [0.00] [c049be50] [c03ab7d0] .setup_arch+0x1ac/0x218
  [0.00] [c049bee0] [c03a36ac] 
  .start_kernel+0xe0/0x3fc
  [0.00] [c049bf90] [c0008594] 
  .start_here_common+0x54/0xc0
  [0.00] Instruction dump:
  [0.00] 7fe3fb78 7ca02a14 4082000c 3860fff4 483c e92289c8 
  e96289c0 e9090002 
  [0.00] e8eb0002 4bc575cd 6000 78630fe0 0b03 7214 
  7fbfe840 7fe3fb78 
  [0.00] ---[ end trace 31fd0ba7d8756001 ]---
  [0.00] Kernel panic - not syncing: Attempted to kill the idle task!
  
 
 int __meminit vmemmap_populate(struct page *start_page,
   unsigned long nr_pages, int node)
 {
   unsigned long mode_rw;
   unsigned long start = (unsigned long)start_page;
   unsigned long end = (unsigned long)(start_page + nr_pages);
   unsigned long page_size = 1  mmu_psize_defs[mmu_linear_psize].shift;
 
   mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
 
   /* Align to the page size of the linear mapping. */
   start = _ALIGN_DOWN(start, page_size);
 
   for (; start  end; start += page_size) {
   int mapped;
   void *p;
 
   if (vmemmap_populated(start, page_size))
   continue;
 
   p = vmemmap_alloc_block(page_size, node);
   if (!p)
   return -ENOMEM;
 
   pr_debug(vmemmap %08lx allocated at %p, physical %08lx.\n,
   start, p, __pa(p));
 
   mapped = htab_bolt_mapping(start, start + page_size,
   __pa(p), mode_rw, mmu_linear_psize,
   mmu_kernel_ssize);
 =BUG_ON(mapped  0);
   }
 
   return 0;
 }
 
 Beats me.  pseries?  Badari has been diddling with the bolted memory code
 in git-powerpc...

It does look like this is resolved with the patch below, if my testing
is to be believed (results out on TKO):

[PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Yinghai Lu [EMAIL PROTECTED]

Andrew, I believe you just sucked that up into -mm.

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

Re: [PATCH 2/2 v2] Add DIU platform code for MPC8610HPCD

2008-03-25 Thread Andy Whitcroft 
On Thu, Mar 20, 2008 at 03:33:04PM -0700, Andrew Morton wrote:
 On Wed, 19 Mar 2008 13:50:27 -0500
 York Sun [EMAIL PROTECTED] wrote:
 
  Add platform code to support Freescale DIU. The platform code includes
  framebuffer memory allocation, pixel format, monitor port, etc.
 
  ...
 
  +unsigned int mpc8610hpcd_get_pixel_format
  +   (unsigned int bits_per_pixel, int monitor_port)

This seems like it might be detectable, does this seem like something we
should try an report?

WARNING: arguments for function declarations should follow identifier
#7: FILE: Z110.c:7:
+int __init preallocate_diu_videomemory

 Again, please do
 
 unsigned int mpc8610hpcd_get_pixel_format(unsigned int bits_per_pixel,
   int monitor_port)
 
 (and anywhere else where this was done)
 
  +int __init preallocate_diu_videomemory(void);
 
 Nope, please don't put extern declarations in .c files.  Find a suitable
 header for it - one which is included by the defining file and by all users
 of the symbol.
 
 Andy, checkpatch missed this.

Yeah, we did only look for explicitly extern'd declarations.  But this
form seems detectable, will be in v0.17.

WARNING: externs should be avoided in .c files
#2: FILE: Z110.c:2:
+int __init preallocate_diu_videomemory(void);

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

Re: [PATCH][ppc] logical/bitand typo in powerpc/boot/4xx.c

2008-01-29 Thread Andy Whitcroft 
On Thu, Jan 24, 2008 at 01:18:48AM +0100, Roel Kluin wrote:
 Joe Perches wrote:
  On Wed, 2008-01-23 at 23:37 +0100, Roel Kluin wrote:
  Signed-off-by: Roel Kluin [EMAIL PROTECTED]
  ---
  diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
  index ebf9e21..dcfb459 100644
  --- a/arch/powerpc/boot/4xx.c
  +++ b/arch/powerpc/boot/4xx.c
  @@ -104,7 +104,7 @@ void ibm4xx_denali_fixup_memsize(void)
 val = DDR_GET_VAL(val, DDR_CS_MAP, DDR_CS_MAP_SHIFT);
 cs = 0;
 while (val) {
  -  if (val  0x1)
  +  if (val  0x1)
 cs++;
 val = val  1;
  
  I think this pattern should be added to checkpatch
 
 I agree but...
 
  Signed-off-by: Joe Perches [EMAIL PROTECTED]
  
  diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
  index 579f50f..147e573 100755
  --- a/scripts/checkpatch.pl
  +++ b/scripts/checkpatch.pl
  @@ -1337,6 +1337,11 @@ sub process {
  }
  }
   
  +# Check for bitwise tests written as boolean
  +   if ($line =~ /\\\s*0[xX]/) {
  +   WARN(boolean test with hexadecimal, perhaps just 1 
  \?\n . $herecurr);
  +   }
  +
 
 when you use git-grep -n \(\|||\)${s}0x\([A-Z0-9]*\|[a-z0-9]*\),
 (with s=[[:space:]]*) there will be false positives like
 
 if (relocation  -0x2 || 0x1fffc  relocation)
 if (ARCH_SUN4C_SUN4  addr  0xe000  0x2000 - len  addr) {
 (and more)
 
 However, if you search with
 git-grep -n  \(\|||\)${s}0x\([A-Z0-9]*\|[a-z0-9]*\)$s\()\|\|||\)
 you won't get these false positives, but you do get the one I fixed.
 
 Also there is the same logic flipped (though it did not give matches at
 this time):
 git-grep -n  \(\|||\|(\)${s}0x\([A-Z0-9]*\|[a-z0-9]*\)$s\(\|||\)
 
 so i'd propose to change that to
 --
 Catch boolean tests with hexadecimals, based on suggestion by Joe Perches
 
 Signed-off-by: Roel Kluin [EMAIL PROTECTED]
 ---
 diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
 index 579f50f..8ac7c7b 100755
 --- a/scripts/checkpatch.pl
 +++ b/scripts/checkpatch.pl
 @@ -1337,6 +1337,12 @@ sub process {
   }
   }
  
 +# Check for bitwise tests written as boolean
 + if ($line =~ /(?:(?:\(|\\|\|\|)\s*0[xX]\s*(?:|\|\|)|
 + (?:\\|\|\|)\s*0[xX]\s*(?:\)||\|\|))/) {
 + WARN(boolean test with hexadecimal, perhaps just 1 \ 
 or \|?\n . $herecurr);
 + }
 +
  # if and else should not have general statements after it
   if ($line =~ /^.\s*(?:}\s*)?else\b(.*)/ 
   $1 !~ /^\s*(?:\sif|{|\\|$)/) {

That one doesn't even match the original example.  Seems to be missing
some number matching.  The concept seems sound though.  Basically
looking for numbers which are definatly adjacent to a boolean or a brace
on both sides.

/me goes play with some examples to see if the falsies are better than
the reports.

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

Re: 2.6.24-rc1-git15 Kernel build fails on powerpc - Unrecognized opcode: `dssall'

2007-11-06 Thread Andy Whitcroft 
On Tue, Nov 06, 2007 at 07:09:40PM +0530, Balbir Singh wrote:
 Kamalesh Babulal wrote:
  David Miller wrote:
  From: Johannes Berg [EMAIL PROTECTED]
  Date: Tue, 06 Nov 2007 11:54:46 +0100
 
CHK include/linux/compile.h
AS  arch/powerpc/kernel/swsusp_32.o
  arch/powerpc/kernel/swsusp_32.S: Assembler messages:
  arch/powerpc/kernel/swsusp_32.S:138: Error: Unrecognized opcode: 
  `dssall'
  make[1]: *** [arch/powerpc/kernel/swsusp_32.o] Error 1
  make: *** [arch/powerpc/kernel] Error 2
 
  Looks suspiciously like an altivec issue. Could you compile with make
  V=1 and/or do a git bisect and see what broke?
  Looks more like a toolchain issue to me.
  Or, this is another instance of the CFLAGS environment variable
  problem.
 
  For a few days, the kbuild stuff would integrate any CFLAGS,
  AFLAGS, etc. settings you might have set in your environment.
  
  Hi Balbir,
  
  The Build error of kernel compilation with V=1
  
  make -f scripts/Makefile.build obj=arch/powerpc/kernel
  make -f scripts/Makefile.build obj=arch/powerpc/kernel/vdso32
gcc -m32 -Wp,-MD,arch/powerpc/kernel/.swsusp_32.o.d  -nostdinc -isystem 
  /usr/lib/gcc/ppc64-redhat-linux/4.1.2/include -D__KERNEL__ -Iinclude  
  -include include/linux/autoconf.h -Iarch/powerpc -D__ASSEMBLY__ 
  -Iarch/powerpc -Wa,-m405 -gdwarf-2 -c -o 
  arch/powerpc/kernel/swsusp_32.o arch/powerpc/kernel/swsusp_32.S
  arch/powerpc/kernel/swsusp_32.S: Assembler messages:
  arch/powerpc/kernel/swsusp_32.S:138: Error: Unrecognized opcode: `dssall'
  make[1]: *** [arch/powerpc/kernel/swsusp_32.o] Error 1
  make: *** [arch/powerpc/kernel] Error 2
  
 
 I looked at your .config and now your  build. It looks like you select
 CONFIG_4xx (I see -Wa,-m405) and compile swsusp_32.S. The
 compiler/toolchain does not enable altivec instructions for CONFIG_4xx.
 If CONFIG_HIBERNATION is enabled as in your case, it compiles
 swsusp_32.S which assumes that ALTIVEC is enabled (see CPU_FTR_ALTIVEC).
 
 You ideally need to have -Wa,-maltivec passed in your CFLAGS.

So that sounds like a Kconfig problem then?  That HIBERATION requires
ALITIVEC and yet does not depend on it or set it.

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

Re: [PATCH][NET] gianfar: fix obviously wrong #ifdef CONFIG_GFAR_NAPI placement

2007-10-18 Thread Andy Whitcroft 
The check then is to see if a non {}'d block has no statements in it if the
ifdef is null.  Hmmm.  May be possible.  Will think on it.

if (err)
+#ifdef CONFIG_GFAR_NAPI
napi_disable(priv-napi);
+#endif

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

2.6.23-rc7-mm1 -- powerpc rtas panic

2007-09-24 Thread Andy Whitcroft 
Seeing the following from an older power LPAR, pretty sure we had
this in the previous -mm also:

Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0047ac8
cpu 0x0: Vector: 300 (Data Access) at [c058f750]
pc: c0047ac8: .pSeries_log_error+0x364/0x420
lr: c0047a4c: .pSeries_log_error+0x2e8/0x420
sp: c058f9d0
   msr: 80001032
   dar: 0
 dsisr: 4200
  current = 0xc04a9b30
  paca= 0xc04aa700
pid   = 0, comm = swapper
enter ? for help
[c058faf0] c0021164 .rtas_call+0x200/0x250
[c058fba0] c0049cd0 .early_enable_eeh+0x168/0x360
[c058fc70] c002f674 .traverse_pci_devices+0x8c/0x138
[c058fd10] c0460ce8 .eeh_init+0x1a8/0x200
[c058fdb0] c045fb70 .pSeries_setup_arch+0x128/0x234
[c058fe40] c044f830 .setup_arch+0x214/0x24c
[c058fee0] c0446a38 .start_kernel+0xd4/0x3e4
[c058ff90] c0373194 .start_here_common+0x54/0x58

This machine is a:

processor   : 0
cpu : POWER4+ (gq)
clock   : 1703.965296MHz
revision: 19.0

[...]

timebase: 212995662
machine : CHRP IBM,7040-681

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

2.6.23-rc6-mm1 -- powerpc link failure

2007-09-19 Thread Andy Whitcroft 
I am seeing this strange link error from a PowerMac G5 (powerpc):

  [...]
KSYM.tmp_kallsyms2.S
AS  .tmp_kallsyms2.o
LD  vmlinux.o
  ld: dynreloc miscount for fs/built-in.o, section .opd
  ld: can not edit opd Bad value
  make: *** [vmlinux.o] Error 1

Compiler version below.

[EMAIL PROTECTED]:~# gcc -v
Using built-in specs.
Target: powerpc-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-softfloat
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
--disable-werror --enable-checking=release powerpc-linux-gnu
Thread model: posix
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

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

2.6.23-rc6-mm1 -- powerpc pSeries_log_error panic in rtas_call/early_enable_eeh

2007-09-19 Thread Andy Whitcroft 
Seeing the following panic booting an old powerpc LPAR:

Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0047b48
cpu 0x0: Vector: 300 (Data Access) at [c06a3750]
pc: c0047b48: .pSeries_log_error+0x364/0x420
lr: c0047acc: .pSeries_log_error+0x2e8/0x420
sp: c06a39d0
   msr: 80001032
   dar: 0
 dsisr: 4200
  current = 0xc05acab0
  paca= 0xc05ad700
pid   = 0, comm = swapper
enter ? for help
[c06a3af0] c0021164 .rtas_call+0x200/0x250
[c06a3ba0] c0049d50 .early_enable_eeh+0x168/0x360
[c06a3c70] c002f674 .traverse_pci_devices+0x8c/0x138
[c06a3d10] c0560ce8 .eeh_init+0x1a8/0x200
[c06a3db0] c055fb70 .pSeries_setup_arch+0x128/0x234
[c06a3e40] c054f830 .setup_arch+0x214/0x24c
[c06a3ee0] c0546a38 .start_kernel+0xd4/0x3e4
[c06a3f90] c045adc4 .start_here_common+0x54/0x58
0:mon

This machine is:

# cat /proc/cpuinfo
processor   : 0
cpu : POWER4+ (gq)
clock   : 1703.965296MHz
revision: 19.0

[...]
machine : CHRP IBM,7040-681

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

Re: 2.6.23-rc6-mm1 -- powerpc link failure

2007-09-19 Thread Andy Whitcroft 
On Wed, Sep 19, 2007 at 06:36:29PM +0200, Segher Boessenkool wrote:
 I am seeing this strange link error from a PowerMac G5 (powerpc):
 
   [...]
 KSYM.tmp_kallsyms2.S
 AS  .tmp_kallsyms2.o
 LD  vmlinux.o
   ld: dynreloc miscount for fs/built-in.o, section .opd
   ld: can not edit opd Bad value
   make: *** [vmlinux.o] Error 1
 
 Compiler version below.
 
 It's an ld error, could you show us your ld version instead?  And
 please try with current mainline ld, too?

[EMAIL PROTECTED]:~# ld -v
GNU ld version 2.16.91 20060118 Debian GNU/Linux

Getting the compiler suite changed on here is going to be a lot
tricker.  One of the reasons we keep it back there is those versions
are supposed to be supported and we want to test those combinations.

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

Re: 2.6.23-rc6-mm1

2007-09-18 Thread Andy Whitcroft 
On Tue, Sep 18, 2007 at 02:43:48PM +0530, Kamalesh Babulal wrote:
 Andrew Morton wrote:
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
 
 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
 
   
 snip
 
 Hi Andrew,
 
 The 2.6.23-rc6-mm1build fails at
 
  CC  drivers/pci/hotplug/rpadlpar_core.o
  CC  drivers/pci/hotplug/rpadlpar_sysfs.o
 drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name' 
 specified in initializer
 drivers/pci/hotplug/rpadlpar_sysfs.c: In function `dlpar_sysfs_init':
 drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member 
 named `name'
 make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
 make[2]: *** [drivers/pci/hotplug] Error 2
 make[1]: *** [drivers/pci] Error 2
 make: *** [drivers] Error 2

This seems to be occuring across a number of the powerpc systems we test
with.  That driver is a power dynamic lpar IO partitioning driver.

Relevant Cc: added.

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

Re: [BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202

2007-09-14 Thread Andy Whitcroft 
Anton, this seems a little reminicient of that bug which popped up in
2.6.23-rc3 so do with SLB loading (if memory serves), with machine
checks and signal 7's.  Of course that is _supposed_ to be fixed by this
time ...

I believe it was Paul who fixed up that one, and he is already copied.

-apw

On Fri, Sep 14, 2007 at 04:07:37PM +0530, Satyam Sharma wrote:

  With 2.6.23-rc6 running on the ppc64 box, following oops is hit
 
  Oops: Machine check, sig: 7 [#1]
 
  SMP NR_CPUS=128 pSeries
 
  Modules linked in: binfmt_misc ipv6 dm_mod ehci_hcd ohci_hcd usbcore
 
  NIP: c00ed560 LR: c00efc7c CTR: c00ed504
 
  REGS: cffef680 TRAP: 0200   Not tainted  (2.6.23-rc6-autokern1)
 
  MSR: 80109032 EE,ME,IR,DR  CR: 28002042  XER: 0010
 
  TASK = c000ecf9f000[0] 'swapper' THREAD: cff8c000 CPU: 2
 
  GPR00:  cffef900 c06fe598 c000d7a8f200
 
  GPR04: 1000  1000 80c26393
 
  GPR08: c06b43d0 0001 1000 
 
  GPR12: 4848 c05f1700  07a8dcd0
 
  GPR16: 0002   
 
  GPR20:  1000 1000 
 
  GPR24:   1000 c63234e8
 
  GPR28: 1000  c0689c08 cff3a480
 
  NIP [c00ed560] .end_bio_bh_io_sync+0x5c/0xac
 
  LR [c00efc7c] .bio_endio+0xb4/0xd4
 
  Call Trace:
 
  [cffef900] [cffef990] 0xcffef990 (unreliable)
 
  [cffef980] [c00efc7c] .bio_endio+0xb4/0xd4
 
  [cffefa10] [c0290060] .__end_that_request_first+0x154/0x548
 
  [cffefae0] [c035af10] .scsi_end_request+0x40/0x138
 
  [cffefb80] [c035b234] .scsi_io_completion+0x188/0x454
 
  [cffefc60] [c0372a24] .sd_rw_intr+0x2e4/0x338
 
  [cffefd30] [c0354548] .scsi_finish_command+0xbc/0xe0
 
  [cffefdc0] [c035bdf0] .scsi_softirq_done+0x140/0x188
 
  [cffefe60] [c0293184] .blk_done_softirq+0xa0/0xd0
 
  [cffefef0] [c0055e1c] .__do_softirq+0xa8/0x164
 
  [cffeff90] [c0023f14] .call_do_softirq+0x14/0x24
 
  [cff8f960] [c000bd30] .do_softirq+0x68/0xac
 
  [cff8f9f0] [c0055f70] .irq_exit+0x54/0x6c
 
  [cff8fa70] [c000c358] .do_IRQ+0x170/0x1ac
 
  [cff8fb00] [c0004780] hardware_interrupt_entry+0x18/0x98
 
  --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe0/0x194
 
  LR = .pseries_dedicated_idle_sleep+0xd0/0x194
 
  [cff8fdf0] [] .__start+0x4000/0x8 
  (unreliable)
 
  [cff8fe80] [c0010bd4] .cpu_idle+0x104/0x1d8
 
  [cff8ff00] [c002672c] .start_secondary+0x160/0x184
 
  [cff8ff90] [c0008364] .start_secondary_prolog+0xc/0x10
 
  Instruction dump:
 
  409a0030 393f0018 3880 7d6048a8 7d6b0378 7d6049ad 40a2fff4 38002000
 
  7d2018a8 7d290378 7d2019ad 40a2fff4 e9230038 e89f0018 e969 f8410028
 
  Kernel panic - not syncing: Fatal exception in interrupt
 
 This oops is the real bug here, but is that a machine check exception?
 If so, it could be a hardware failure what you saw there instead, and not
 really a kernel bug ...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: 2.6.23-rc4-mm1 -- powerpc per_cpu__cpu_sibling_map compile failure

2007-09-10 Thread Andy Whitcroft 
Am seeing the following compile error on all of my powerpc platforms:

  CC  kernel/sched.o
  kernel/sched.c: In function `cpu_to_phys_group':
  kernel/sched.c:5937: error: `per_cpu__cpu_sibling_map' undeclared (first use 
in this function)
  kernel/sched.c:5937: error: (Each undeclared identifier is reported only once
  kernel/sched.c:5937: error: for each function it appears in.)
  kernel/sched.c:5937: warning: type defaults to `int' in declaration of `type 
name'
  kernel/sched.c:5937: error: invalid type argument of `unary *'
  kernel/sched.c: In function `build_sched_domains':
  kernel/sched.c:6172: error: `per_cpu__cpu_sibling_map' undeclared (first use 
in this function)
  kernel/sched.c:6172: warning: type defaults to `int' in declaration of `type 
name'
  kernel/sched.c:6172: error: invalid type argument of `unary *'
  kernel/sched.c:6183: warning: type defaults to `int' in declaration of `type 
name'
  kernel/sched.c:6183: error: invalid type argument of `unary *'
  make[1]: *** [kernel/sched.o] Error 1
  make: *** [kernel] Error 2

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

[PATCH 2/6] powerpc: hash_preload fails to preload under CONFIG_PPC_MM_SLICES

2007-08-16 Thread Andy Whitcroft 

Seems that a trailing ';' has slipped onto the end of the
get_slice_psize checks under CONFIG_PPC_MM_SLICES causing us to
return unconditionally and never preload.

Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: linuxppc-dev@ozlabs.org
---
 arch/powerpc/mm/hash_utils_64.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index f178957..a47151e 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -795,7 +795,7 @@ void hash_preload(struct mm_struct *mm, unsigned long ea,
 
 #ifdef CONFIG_PPC_MM_SLICES
/* We only prefault standard pages for now */
-   if (unlikely(get_slice_psize(mm, ea) != mm-context.user_psize));
+   if (unlikely(get_slice_psize(mm, ea) != mm-context.user_psize))
return;
 #endif
 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev