headers
Benjamin Herrenschmidt | 1 Mar 2005 05:29

[PATCH] ppc64: Fix zImage wrapper incorrect size to flush_cache()

Hi !

This patch fixes a bug in the ppc64 zImage wrapper causing it to
pass an incorrect size to flush_cache() when flushing the data and
instruction caches prior to jumping to the kernel entry. This causes
crashes on firmare environment that do strict MMU mapping only of
actually allocated areas

Signed-off-by: Benjamin Herrenschmidt <benh <at> kernel.crashing.org>

--- dingo/2.6.10-bk5/arch/ppc64/boot/main.c	2004-12-25 08:35:50.000000000 +1100
+++ 2.6.10-bk5/arch/ppc64/boot/main.c	2005-02-16 17:10:49.194263268 +1100
 <at>  <at>  -200,7 +200,7  <at>  <at> 
 	vmlinux.addr += (unsigned long)elf64ph->p_offset;
 	vmlinux.size -= (unsigned long)elf64ph->p_offset;

-	flush_cache((void *)vmlinux.addr, vmlinux.memsize);
+	flush_cache((void *)vmlinux.addr, vmlinux.size);

 	if (a1)
 		printf("initrd head: 0x%lx\n\r", *((u32 *)initrd.addr));
Permalink | Reply | 0 comments |
headers
Mike Kravetz | 1 Mar 2005 23:27
Picon
Favicon

[PATCH] NUMA memory fixup

When I booted my new 720 on a kernel configured for NUMA, I received
the following during bootup:

WARNING: Unexpected node layout: region start 44000000 length 2000000
NUMA is disabled

This is due to memory 'holes' within nodes.  If such holes are
encountered, then NUMA is disabled.  The following patch adds support
for such configurations.  My 720 now boots with the following message:

[boot]0012 Setup Arch
Node 0 Memory: 0x0-0x8000000 0x44000000-0x12a000000
Node 1 Memory: 0x8000000-0x44000000 0x12a000000-0x1ea000000

I'd appreciate any comments on the approach taken.  I'm also working
on adding NUMA support on top of the SPARSEMEM implementation being
pushed as part of memory hot add.  However, it seems important to get
the current implementation based on DISCONTIGMEM working first.  This
patch is against 2.6.11-rc3, but I can provide a later version if needed.

--

-- 
Signed-off-by: Mike Kravetz <kravetz <at> us.ibm.com>

diff -Naupr linux-2.6.11-rc3/arch/ppc64/mm/numa.c linux-2.6.11-rc3.work/arch/ppc64/mm/numa.c
--- linux-2.6.11-rc3/arch/ppc64/mm/numa.c	2005-02-03 01:57:16.000000000 +0000
+++ linux-2.6.11-rc3.work/arch/ppc64/mm/numa.c	2005-03-01 19:39:21.000000000 +0000
 <at>  <at>  -40,7 +40,6  <at>  <at>  int nr_cpus_in_node[MAX_NUMNODES] = { [0

 struct pglist_data *node_data[MAX_NUMNODES];
 bootmem_data_t __initdata plat_node_bdata[MAX_NUMNODES];
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nathan Lynch | 2 Mar 2005 02:47
Picon
Favicon

[PATCH] explicitly bind idle tasks

On Sun, Feb 27, 2005 at 02:49:28PM -0800, Andrew Morton wrote:
> Benjamin Herrenschmidt <benh <at> kernel.crashing.org> wrote:
> >
> > > -		if (cpu_is_offline(smp_processor_id()) &&
> >  > +		if (cpu_is_offline(_smp_processor_id()) &&
> >  >  		    system_state == SYSTEM_RUNNING)
> >  >  			cpu_die();
> >  >  	}
> >  > _
> > 
> >  This is the idle loop. Is that ever supposed to be preempted ?
> 
> Nope, it's a false positive.  We had to do the same in x86's idle loop and
> probably others will hit it.

Perhaps I'm missing something, but is there any reason we can't do
the following?  I've tested it on ppc64, doesn't seem to break anything.

With hotplug cpu and preempt, we tend to see smp_processor_id warnings
from idle loop code because it's always checking whether its cpu has
gone offline.  Replacing every use of smp_processor_id with
_smp_processor_id in all idle loop code is one solution; another way
is explicitly binding idle threads to their cpus (the smp_processor_id
warning does not fire if the caller is bound only to the calling cpu).
This has the (admittedly slight) advantage of letting us know if an
idle thread ever runs on the wrong cpu.

Signed-off-by: Nathan Lynch <ntl <at> pobox.com>

Index: linux-2.6.11-rc5-mm1/init/main.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zwane Mwaikambo | 2 Mar 2005 04:13
Picon

Re: [PATCH] explicitly bind idle tasks

On Tue, 1 Mar 2005, Nathan Lynch wrote:

> On Sun, Feb 27, 2005 at 02:49:28PM -0800, Andrew Morton wrote:
> > Benjamin Herrenschmidt <benh <at> kernel.crashing.org> wrote:
> > >
> > > > -		if (cpu_is_offline(smp_processor_id()) &&
> > >  > +		if (cpu_is_offline(_smp_processor_id()) &&
> > >  >  		    system_state == SYSTEM_RUNNING)
> > >  >  			cpu_die();
> > >  >  	}
> > >  > _
> > > 
> > >  This is the idle loop. Is that ever supposed to be preempted ?
> > 
> > Nope, it's a false positive.  We had to do the same in x86's idle loop and
> > probably others will hit it.
> 
> Perhaps I'm missing something, but is there any reason we can't do
> the following?  I've tested it on ppc64, doesn't seem to break anything.
> 
> With hotplug cpu and preempt, we tend to see smp_processor_id warnings
> from idle loop code because it's always checking whether its cpu has
> gone offline.  Replacing every use of smp_processor_id with
> _smp_processor_id in all idle loop code is one solution; another way
> is explicitly binding idle threads to their cpus (the smp_processor_id
> warning does not fire if the caller is bound only to the calling cpu).
> This has the (admittedly slight) advantage of letting us know if an
> idle thread ever runs on the wrong cpu.

Makes sense to me, for some reason i thought the smp_processor_id()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nishanth Aravamudan | 2 Mar 2005 19:12
Picon
Favicon

eeh.h compile warnings / adbhid.c build failure

Hi,

While building 2.6.11 for a G5, I noticed the following errors being
spit out (gcc 3.3.5):

include/asm/eeh.h: In function `eeh_memcpy_fromio':
include/asm/eeh.h:265: warning: statement with no effect
include/asm/eeh.h: In function `eeh_insb':
include/asm/eeh.h:353: warning: statement with no effect
include/asm/eeh.h: In function `eeh_insw_ns':
include/asm/eeh.h:360: warning: statement with no effect
include/asm/eeh.h: In function `eeh_insl_ns':
include/asm/eeh.h:367: warning: statement with no effect
include/asm/eeh.h: In function `eeh_memcpy_fromio':
include/asm/eeh.h:265: warning: statement with no effect
include/asm/eeh.h: In function `eeh_insb':
include/asm/eeh.h:353: warning: statement with no effect
include/asm/eeh.h: In function `eeh_insw_ns':
include/asm/eeh.h:360: warning: statement with no effect
include/asm/eeh.h: In function `eeh_insl_ns':
include/asm/eeh.h:367: warning: statement with no effect

These warnings are emitted for pretty much every driver. It looks like
it is becuase with CONFIG_EEH undefined (it's a pSeries thing? -- my
interpretation from looking at the ppc64 Kconfig), eeh_check_failure()
becomes #define'd to simply it's second parameter, which in the case of
assignment statements ia statement with no effect. It's not a big deal,
the kernels still compile (with a patch to adbhid.c which I'll mention
in a second) but it's a lot of noise to be generated because I don't
have a pSeries machine...
(Continue reading)

Permalink | Reply | 14 comments |
headers
Nishanth Aravamudan | 2 Mar 2005 20:28
Picon
Favicon

Re: eeh.h compile warnings / adbhid.c build failure

On Wed, Mar 02, 2005 at 11:20:06AM -0800, Brad Boyer wrote:
> On Wed, Mar 02, 2005 at 10:12:06AM -0800, Nishanth Aravamudan wrote:
> > Now, to the build-blocking code:
> > 
> > In drivers/macintosh/adbhid.c::1159:
> > 
> > static int __init adbhid_init(void)
> > {
> > #ifndef CONFIG_MAC
> >         if ( (_machine != _MACH_chrp) && (_machine != _MACH_Pmac) )
> > 		return 0;
> > #endif
> > ...
> > 
> > I don't see CONFIG_MAC in my .config (attached below [1]), and _MACH_chrp is
> > not defined for ppc64 (it's in asm-ppc/processor.h not in
> > ppc64/processor.h. I just removed the _MACH_chrp conditional in my local
> > code to get the kernel to build. I'm not sure what the actual solution
> > is, but I thought you all should know about it.
> 
> The CONFIG_MAC symbol is defined for mac68k support. The m68k arch has a
> different way of telling the various machines apart, although I notice
> that there isn't an equivalent block here for that. I guess no other 68k
> people cared enough to make sure the ADB layer doesn't load on their boxes.
> 
> In my opinion, the machine selectors should be reconciled between ppc and
> ppc64 due to the amount of code that expects them to act the same. So
> even though you wouldn't have a CHRP ppc64 box, the define will be there.

I definitely think this is the ideal solution. I did notice, though,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brad Boyer | 2 Mar 2005 20:20

Re: eeh.h compile warnings / adbhid.c build failure

On Wed, Mar 02, 2005 at 10:12:06AM -0800, Nishanth Aravamudan wrote:
> Now, to the build-blocking code:
> 
> In drivers/macintosh/adbhid.c::1159:
> 
> static int __init adbhid_init(void)
> {
> #ifndef CONFIG_MAC
>         if ( (_machine != _MACH_chrp) && (_machine != _MACH_Pmac) )
> 		return 0;
> #endif
> ...
> 
> I don't see CONFIG_MAC in my .config (attached below [1]), and _MACH_chrp is
> not defined for ppc64 (it's in asm-ppc/processor.h not in
> ppc64/processor.h. I just removed the _MACH_chrp conditional in my local
> code to get the kernel to build. I'm not sure what the actual solution
> is, but I thought you all should know about it.

The CONFIG_MAC symbol is defined for mac68k support. The m68k arch has a
different way of telling the various machines apart, although I notice
that there isn't an equivalent block here for that. I guess no other 68k
people cared enough to make sure the ADB layer doesn't load on their boxes.

In my opinion, the machine selectors should be reconciled between ppc and
ppc64 due to the amount of code that expects them to act the same. So
even though you wouldn't have a CHRP ppc64 box, the define will be there.

	Brad Boyer
	flar <at> allandria.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Rose | 2 Mar 2005 22:10
Picon
Favicon

[PATCH] error code cleanups for rtas wrappers

This patch changes the rtas wrapper functions in rtas.c to map RTAS failures
to conventional error values.  The goal is to make failure conditions 
obvious in the wrapper functions and in the caller code.

Flame away :)

John

Signed-off-by: John Rose <johnrose <at> austin.ibm.com>

diff -puN arch/ppc64/kernel/pSeries_smp.c~01_rtas_rcs arch/ppc64/kernel/pSeries_smp.c
--- 2_6_linus_3/arch/ppc64/kernel/pSeries_smp.c~01_rtas_rcs	2005-03-02 14:50:33.000000000 -0600
+++ 2_6_linus_3-johnrose/arch/ppc64/kernel/pSeries_smp.c	2005-03-02 14:50:33.000000000 -0600
 <at>  <at>  -151,7 +151,7  <at>  <at>  static unsigned int find_physical_cpu_to
 		if (index) {
 			int state;
 			int rc = rtas_get_sensor(9003, *index, &state);
-			if (rc != 0 || state != 1)
+			if (rc < 0 || state != 1)
 				continue;
 		}

diff -puN arch/ppc64/kernel/rtas.c~01_rtas_rcs arch/ppc64/kernel/rtas.c
--- 2_6_linus_3/arch/ppc64/kernel/rtas.c~01_rtas_rcs	2005-03-02 14:50:33.000000000 -0600
+++ 2_6_linus_3-johnrose/arch/ppc64/kernel/rtas.c	2005-03-02 14:50:33.000000000 -0600
 <at>  <at>  -255,29 +255,59  <at>  <at>  rtas_extended_busy_delay_time(int status
 	return ms; 
 }

-int
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jake Moilanen | 2 Mar 2005 23:34
Picon
Favicon

[PATCH][RFC] unlikely spinlocks

On our raw spinlocks, we currently have an attempt at the lock, and if
we do not get it we enter a spin loop.  This spinloop will likely
continue for awhile, and we pridict likely.  

Shouldn't we predict that we will get out of the loop so our next
instructions are already prefetched.  Even when we miss because the lock
is still held, it won't matter since we are waiting anyways.

I did a couple quick benchmarks, but the results are inconclusive.  

	16-way 690 running specjbb with original code
	# ./specjbb 3000 16 1 1 19 30 120
	    ...
	Valid run, Score is 59282

	16-way 690 running specjbb with unlikely code
	# ./specjbb 3000 16 1 1 19 30 120
	    ...
	Valid run, Score is 59541

I saw a smaller increase on a JS20 (~1.6%)

	JS20 specjbb w/ original code
	# ./specjbb 400 2 1 1 19 30 120
	   ...
	Valid run, Score is 20460

	JS20 specjbb w/ unlikely code
	# ./specjbb 400 2 1 1 19 30 120
	   ...
(Continue reading)

Permalink | Reply | 4 comments |
headers
Benjamin Herrenschmidt | 3 Mar 2005 00:39

Re: eeh.h compile warnings / adbhid.c build failure

On Wed, 2005-03-02 at 10:12 -0800, Nishanth Aravamudan wrote:
> 
> These warnings are emitted for pretty much every driver. It looks like
> it is becuase with CONFIG_EEH undefined (it's a pSeries thing? -- my
> interpretation from looking at the ppc64 Kconfig), eeh_check_failure()
> becomes #define'd to simply it's second parameter, which in the case of
> assignment statements ia statement with no effect. It's not a big deal,
> the kernels still compile (with a patch to adbhid.c which I'll mention
> in a second) but it's a lot of noise to be generated because I don't
> have a pSeries machine...

Stupid gcc :)

> Now, to the build-blocking code:
> 
> In drivers/macintosh/adbhid.c::1159:
> 
> static int __init adbhid_init(void)
> {
> #ifndef CONFIG_MAC
>         if ( (_machine != _MACH_chrp) && (_machine != _MACH_Pmac) )
> 		return 0;
> #endif
> ...
> 
> I don't see CONFIG_MAC in my .config (attached below [1]), and _MACH_chrp is
> not defined for ppc64 (it's in asm-ppc/processor.h not in
> ppc64/processor.h. I just removed the _MACH_chrp conditional in my local
> code to get the kernel to build. I'm not sure what the actual solution
> is, but I thought you all should know about it.
(Continue reading)

Permalink | Reply | 7 comments |

Gmane