* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Peter Zijlstra @ 2008-01-23 12:36 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, Ingo Molnar
In-Reply-To: <1201090699.9052.39.camel@thor.sulgenrain.local>
On Wed, 2008-01-23 at 13:18 +0100, Michel Dänzer wrote:
> On Tue, 2008-01-22 at 15:56 +0100, Michel Dänzer wrote:
> > On Fri, 2008-01-18 at 13:34 +0100, Michel Dänzer wrote:
> > > This is on a PowerBook5,8.
> > >
> > > In a nutshell, things seem more sluggish in general than with 2.6.23.
> > > But in particular, processes running at nice levels >0 can get most of
> > > the CPU cycles available, slowing down processes running at nice level
> > > 0.
> >
> > The canonical test case I've come up with is to run an infinite loop
> > with
> >
> > sudo -u nobody nice -n 19 sh -c 'while true; do true; done'
> >
> > This makes my X session (X server running at nice level -1, clients at
> > 0) unusably sluggish (it can even take several seconds to process ctrl-c
> > to interrupt the infinite loop) with 2.6.24-rc but works as expected
> > with 2.6.23.
> >
> > Anybody else seeing this?
> >
> >
> > > I've seen this since .24-rc5 (the first .24-rc I tried), and it's still
> > > there with -rc8. I'd be surprised if this kind of behaviour remained
> > > unfixed for that long if it affected x86, so I presume it's powerpc
> > > specific.
> >
> > Or maybe not... I've bisected this down to the scheduler changes
> > between
> > df3d80f5a5c74168be42788364d13cf6c83c7b9c/23fd50450a34f2558070ceabb0bfebc1c9604af5 and b5869ce7f68b233ceb81465a7644be0d9a5f3dbb .
>
> Finished bisecting now. And the winner is...
>
> 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
> commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Mon Oct 15 17:00:14 2007 +0200
>
> sched: another wakeup_granularity fix
>
> unit mis-match: wakeup_gran was used against a vruntime
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>
> :040000 040000 61242d589b0082a417657807ed6329321340f7f3 bff39e49275324e15f37d2163157733580b7df1a M kernel
>
>
> Unfortunately, I don't understand how that can cause the misbehaviour
> described above, and 2.6.24-rc8
> (667984d9e481e43a930a478c588dced98cb61fea) with the patch below still
> shows the problem. Any ideas Peter or Ingo (or anyone, really :)?
>
>
> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> index da7c061..a7cc22a 100644
> --- a/kernel/sched_fair.c
> +++ b/kernel/sched_fair.c
> @@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
> struct task_struct *curr = rq->curr;
> struct cfs_rq *cfs_rq = task_cfs_rq(curr);
> struct sched_entity *se = &curr->se, *pse = &p->se;
> - unsigned long gran;
>
> if (unlikely(rt_prio(p->prio))) {
> update_rq_clock(rq);
> @@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
> pse = parent_entity(pse);
> }
>
> - gran = sysctl_sched_wakeup_granularity;
> - if (unlikely(se->load.weight != NICE_0_LOAD))
> - gran = calc_delta_fair(gran, &se->load);
>
> - if (pse->vruntime + gran < se->vruntime)
> + if (pse->vruntime + sysctl_sched_wakeup_granularity < se->vruntime)
> resched_task(curr);
> }
>
Most curious; are you sure its not a bisection problem?
Does ppc32 (or your instance thereof) have a high resolution
sched_clock()?
^ permalink raw reply
* [PATCH] [RAPIDIO] Fix compile error and warning
From: Kumar Gala @ 2008-01-23 12:37 UTC (permalink / raw)
To: linuxppc-dev
drivers/rapidio/rio.c: In function 'rio_get_asm':
drivers/rapidio/rio.c:413: error: implicit declaration of function 'in_interrupt'
drivers/rapidio/rio.c: In function 'rio_init_mports':
drivers/rapidio/rio.c:480: warning: format '%8.8lx' expects type 'long unsigned int', but argument 2 has type 'resource_size_t'
drivers/rapidio/rio.c:480: warning: format '%8.8lx' expects type 'long unsigned int', but argument 3 has type 'resource_size_t'
---
drivers/rapidio/rio.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/rapidio/rio.c b/drivers/rapidio/rio.c
index f644807..80c5f1b 100644
--- a/drivers/rapidio/rio.c
+++ b/drivers/rapidio/rio.c
@@ -23,6 +23,7 @@
#include <linux/module.h>
#include <linux/spinlock.h>
#include <linux/slab.h>
+#include <linux/interrupt.h>
#include "rio.h"
@@ -476,8 +477,8 @@ int rio_init_mports(void)
port->iores.end - port->iores.start,
port->name)) {
printk(KERN_ERR
- "RIO: Error requesting master port region %8.8lx-%8.8lx\n",
- port->iores.start, port->iores.end - 1);
+ "RIO: Error requesting master port region 0x%016llx-0x%016llx\n",
+ (u64)port->iores.start, (u64)port->iores.end - 1);
rc = -ENOMEM;
goto out;
}
--
1.5.3.7
^ permalink raw reply related
* [PATCH] [POWERPC] Fix compile error if CONFIG_STX_GP3 is defined
From: Kumar Gala @ 2008-01-23 12:38 UTC (permalink / raw)
To: linuxppc-dev
cpmux is need in all cases, having wrapped by the ifndef CONFIG_STX_GP3
was causing a compile error.
---
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index def0158..d9af06a 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -165,9 +165,9 @@ void scc2_lineif(struct uart_cpm_port *pinfo)
* really has to get out of the driver so boards can
* be supported in a sane fashion.
*/
+ volatile cpmux_t *cpmux = cpm2_map(im_cpmux);
#ifndef CONFIG_STX_GP3
volatile iop_cpm2_t *io = cpm2_map(im_ioport);
- volatile cpmux_t *cpmux = cpm2_map(im_cpmux);
io->iop_pparb |= 0x008b0000;
io->iop_pdirb |= 0x00880000;
--
1.5.3.7
^ permalink raw reply related
* [PATCH] [POWERPC] Move RapidIO support code from arch/ppc
From: Kumar Gala @ 2008-01-23 12:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Wei.Zhang
Do just enough to move the RapidIO support code for 85xx over from arch/ppc
into arch/powerpc and make it still build.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/kernel/Makefile | 1 +
arch/{ppc => powerpc}/kernel/rio.c | 0
arch/powerpc/sysdev/Makefile | 1 +
.../ppc85xx_rio.c => powerpc/sysdev/fsl_rio.c} | 0
.../ppc85xx_rio.h => powerpc/sysdev/fsl_rio.h} | 0
arch/ppc/kernel/Makefile | 1 -
arch/ppc/platforms/85xx/mpc85xx_ads_common.c | 3 +--
arch/ppc/platforms/85xx/stx_gp3.c | 2 +-
arch/ppc/platforms/85xx/tqm85xx.c | 2 +-
arch/ppc/syslib/Makefile | 1 -
10 files changed, 5 insertions(+), 6 deletions(-)
rename arch/{ppc => powerpc}/kernel/rio.c (100%)
rename arch/{ppc/syslib/ppc85xx_rio.c => powerpc/sysdev/fsl_rio.c} (100%)
rename arch/{ppc/syslib/ppc85xx_rio.h => powerpc/sysdev/fsl_rio.h} (100%)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index d9b3770..58dbfef 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -70,6 +70,7 @@ pci64-$(CONFIG_PPC64) += pci_dn.o isa-bridge.o
obj-$(CONFIG_PCI) += pci_$(CONFIG_WORD_SIZE).o $(pci64-y) \
pci-common.o
obj-$(CONFIG_PCI_MSI) += msi.o
+obj-$(CONFIG_RAPIDIO) += rio.o
obj-$(CONFIG_KEXEC) += machine_kexec.o crash.o \
machine_kexec_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_AUDIT) += audit.o
diff --git a/arch/ppc/kernel/rio.c b/arch/powerpc/kernel/rio.c
similarity index 100%
rename from arch/ppc/kernel/rio.c
rename to arch/powerpc/kernel/rio.c
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 66fe39c..f17e7b8 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_U3_DART) += dart_iommu.o
obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o
+obj-$(CONFIG_RAPIDIO) += fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
diff --git a/arch/ppc/syslib/ppc85xx_rio.c b/arch/powerpc/sysdev/fsl_rio.c
similarity index 100%
rename from arch/ppc/syslib/ppc85xx_rio.c
rename to arch/powerpc/sysdev/fsl_rio.c
diff --git a/arch/ppc/syslib/ppc85xx_rio.h b/arch/powerpc/sysdev/fsl_rio.h
similarity index 100%
rename from arch/ppc/syslib/ppc85xx_rio.h
rename to arch/powerpc/sysdev/fsl_rio.h
diff --git a/arch/ppc/kernel/Makefile b/arch/ppc/kernel/Makefile
index 6b4f022..5da0ca7 100644
--- a/arch/ppc/kernel/Makefile
+++ b/arch/ppc/kernel/Makefile
@@ -13,7 +13,6 @@ obj-y := entry.o traps.o time.o misc.o \
ppc_htab.o
obj-$(CONFIG_MODULES) += ppc_ksyms.o
obj-$(CONFIG_PCI) += pci.o
-obj-$(CONFIG_RAPIDIO) += rio.o
obj-$(CONFIG_KGDB) += ppc-stub.o
obj-$(CONFIG_SMP) += smp.o smp-tbsync.o
obj-$(CONFIG_KEXEC) += machine_kexec.o relocate_kernel.o
diff --git a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
index 674806e..0706dca 100644
--- a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
+++ b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
@@ -42,8 +42,6 @@
#include <mm/mmu_decl.h>
-#include <syslib/ppc85xx_rio.h>
-
#include <platforms/85xx/mpc85xx_ads_common.h>
#ifndef CONFIG_PCI
@@ -190,6 +188,7 @@ mpc85xx_exclude_device(u_char bus, u_char devfn)
#endif /* CONFIG_PCI */
#ifdef CONFIG_RAPIDIO
+extern void mpc85xx_rio_setup(int law_start, int law_size);
void platform_rio_init(void)
{
/* 512MB RIO LAW at 0xc0000000 */
diff --git a/arch/ppc/platforms/85xx/stx_gp3.c b/arch/ppc/platforms/85xx/stx_gp3.c
index 731b40e..8748da3 100644
--- a/arch/ppc/platforms/85xx/stx_gp3.c
+++ b/arch/ppc/platforms/85xx/stx_gp3.c
@@ -54,7 +54,6 @@
#include <syslib/cpm2_pic.h>
#include <syslib/ppc85xx_common.h>
-#include <syslib/ppc85xx_rio.h>
unsigned char __res[sizeof(bd_t)];
@@ -270,6 +269,7 @@ int mpc85xx_exclude_device(u_char bus, u_char devfn)
#endif /* CONFIG_PCI */
#ifdef CONFIG_RAPIDIO
+extern void mpc85xx_rio_setup(int law_start, int law_size);
void
platform_rio_init(void)
{
diff --git a/arch/ppc/platforms/85xx/tqm85xx.c b/arch/ppc/platforms/85xx/tqm85xx.c
index 4ee2bd1..2a863a8 100644
--- a/arch/ppc/platforms/85xx/tqm85xx.c
+++ b/arch/ppc/platforms/85xx/tqm85xx.c
@@ -54,7 +54,6 @@
#include <syslib/ppc85xx_setup.h>
#include <syslib/cpm2_pic.h>
#include <syslib/ppc85xx_common.h>
-#include <syslib/ppc85xx_rio.h>
#ifndef CONFIG_PCI
unsigned long isa_io_base = 0;
@@ -309,6 +308,7 @@ int mpc85xx_exclude_device(u_char bus, u_char devfn)
#endif /* CONFIG_PCI */
#ifdef CONFIG_RAPIDIO
+extern void mpc85xx_rio_setup(int law_start, int law_size);
void platform_rio_init(void)
{
/* 512MB RIO LAW at 0xc0000000 */
diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
index 543795b..5e16228 100644
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -93,7 +93,6 @@ obj-$(CONFIG_85xx) += open_pic.o ppc85xx_common.o ppc85xx_setup.o \
ifeq ($(CONFIG_85xx),y)
obj-$(CONFIG_PCI) += pci_auto.o
endif
-obj-$(CONFIG_RAPIDIO) += ppc85xx_rio.o
obj-$(CONFIG_83xx) += ppc83xx_setup.o ppc_sys.o \
mpc83xx_sys.o mpc83xx_devices.o ipic.o
ifeq ($(CONFIG_83xx),y)
--
1.5.3.7
^ permalink raw reply related
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Peter Zijlstra @ 2008-01-23 12:42 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, Ingo Molnar
In-Reply-To: <1201090699.9052.39.camel@thor.sulgenrain.local>
Another question, do you have:
CONFIG_FAIR_GROUP_SCHED=y
if so, does flipping that off have any effect?
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Olaf Hering @ 2008-01-23 12:52 UTC (permalink / raw)
To: Mel Gorman
Cc: lee.schermerhorn, Linux MM, linux-kernel, linuxppc-dev,
Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan, akpm,
KAMEZAWA Hiroyuki, Christoph Lameter
In-Reply-To: <20080123121459.GA18631@aepfle.de>
On Wed, Jan 23, Olaf Hering wrote:
> On Wed, Jan 23, Mel Gorman wrote:
>
> > Sorry this is dragging out. Can you post the full dmesg with loglevel=8 of the
> > following patch against 2.6.24-rc8 please? It contains the debug information
> > that helped me figure out what was going wrong on the PPC64 machine here,
> > the revert and the !l3 checks (i.e. the two patches that made machines I
> > have access to work). Thanks
>
> It boots with your change.
This version of the patch boots ok for me:
Maybe I made a mistake with earlier patches, no idea.
---
mm/slab.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1590,7 +1590,7 @@ void __init kmem_cache_init(void)
/* Replace the static kmem_list3 structures for the boot cpu */
init_list(&cache_cache, &initkmem_list3[CACHE_CACHE], node);
- for_each_node_state(nid, N_NORMAL_MEMORY) {
+ for_each_online_node(nid) {
init_list(malloc_sizes[INDEX_AC].cs_cachep,
&initkmem_list3[SIZE_AC + nid], nid);
@@ -1968,7 +1968,7 @@ static void __init set_up_list3s(struct
{
int node;
- for_each_node_state(node, N_NORMAL_MEMORY) {
+ for_each_online_node(node) {
cachep->nodelists[node] = &initkmem_list3[index + node];
cachep->nodelists[node]->next_reap = jiffies +
REAPTIMEOUT_LIST3 +
@@ -2099,7 +2099,7 @@ static int __init_refok setup_cpu_cache(
g_cpucache_up = PARTIAL_L3;
} else {
int node;
- for_each_node_state(node, N_NORMAL_MEMORY) {
+ for_each_online_node(node) {
cachep->nodelists[node] =
kmalloc_node(sizeof(struct kmem_list3),
GFP_KERNEL, node);
@@ -2775,6 +2775,11 @@ static int cache_grow(struct kmem_cache
/* Take the l3 list lock to change the colour_next on this node */
check_irq_off();
l3 = cachep->nodelists[nodeid];
+ if (!l3) {
+ nodeid = numa_node_id();
+ l3 = cachep->nodelists[nodeid];
+ }
+ BUG_ON(!l3);
spin_lock(&l3->list_lock);
/* Get colour for the slab, and cal the next value. */
@@ -3317,6 +3322,10 @@ static void *____cache_alloc_node(struct
int x;
l3 = cachep->nodelists[nodeid];
+ if (!l3) {
+ nodeid = numa_node_id();
+ l3 = cachep->nodelists[nodeid];
+ }
BUG_ON(!l3);
retry:
@@ -3815,7 +3824,7 @@ static int alloc_kmemlist(struct kmem_ca
struct array_cache *new_shared;
struct array_cache **new_alien = NULL;
- for_each_node_state(node, N_NORMAL_MEMORY) {
+ for_each_online_node(node) {
if (use_alien_caches) {
new_alien = alloc_alien_cache(node, cachep->limit);
^ permalink raw reply
* Re: [PATCH] [POWERPC] Update TQM5200, CM5200 and Motion-PRO _defconfig and .dts files
From: Wolfgang Denk @ 2008-01-23 12:54 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: Olof Johansson, tech-denx, Detlev Zundel, linuxppc-dev
In-Reply-To: <479725A4.2020401@semihalf.com>
In message <479725A4.2020401@semihalf.com> you wrote:
> Olof Johansson wrote:
> ...
> >
> > I disagree, I have one defconfig for all our boards to date. It means I
> > only have one kernel to build to test on all boards, instead of having
> > to build a number of different kernels. Keeping it fairly generic also
> > means a customer can start out using the generic kernel in case they
> > want to, and later on add their own drivers and prune out what is not
> > needed.
>
> Well, I just prefer separate defconfigs but I can live with the common
> one as well, feel free to merge it as you see it fit.
Well, it may make sense to use common defconfig files for boards of
the same breed (different configurations of one board family from one
vendor for example). But please note that TQM5200, CM5200 and
Motion-PRO are boards from 3 different vendors, used by different
projects with differing needs. IMO it makes very much sense to
provide 3 separate default configurations that match the specific
requirements of each of these boards.
In this case I vote for separate defconfig files, please.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Be careful what you wish for. You never know who will be listening.
- Terry Pratchett, _Soul Music_
^ permalink raw reply
* Re: [PATCHv2] i2c: adds support for i2c bus on Frescale CPM1/CPM2 controllers
From: Jean Delvare @ 2008-01-23 13:02 UTC (permalink / raw)
To: Jochen Friedrich
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Linux I2C,
Scott Wood
In-Reply-To: <479723CE.5020609@scram.de>
Hallo Jochen,
On Wed, 23 Jan 2008 12:23:58 +0100, Jochen Friedrich wrote:
> Hi Jean,
>
> > Do you have an updated patch addressing Stephen's comment?
> >
> > Note: you'd rather send updates of this patch to the i2c list rather
> > than LKML.
>
> I'm currently looking at that last patches from Jon and try to make this
> driver fit in there (+ the class override stuff).
I'm not sure what patches exactly you're talking about, but the
aliasing stuff Jon and myself have been working on are still under
debate. Your patch shouldn't assume that any of these patches will go
upstream immediately, so your patch adding the i2c-cpm driver can
ignore them. I'll update the patches before merging them as needed, do
not worry too much about that.
> Note: will do. I just subscribed to this list.
Note hat you do not need to be subscribed to post to the i2c list (but
of course, if you have some interest in Linux i2c development,
subscribing was a good idea anyway.)
--
Jean Delvare
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Michel Dänzer @ 2008-01-23 13:14 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: linuxppc-dev, Ingo Molnar
In-Reply-To: <1201091798.6341.49.camel@lappy>
On Wed, 2008-01-23 at 13:36 +0100, Peter Zijlstra wrote:
> On Wed, 2008-01-23 at 13:18 +0100, Michel Dänzer wrote:
> >
> > 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
> > commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> > Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Date: Mon Oct 15 17:00:14 2007 +0200
> >
> > sched: another wakeup_granularity fix
> >
> > unit mis-match: wakeup_gran was used against a vruntime
> >
> > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Signed-off-by: Ingo Molnar <mingo@elte.hu>
> >
> > :040000 040000 61242d589b0082a417657807ed6329321340f7f3 bff39e49275324e15f37d2163157733580b7df1a M kernel
> >
> >
> > Unfortunately, I don't understand how that can cause the misbehaviour
> > described above, and 2.6.24-rc8
> > (667984d9e481e43a930a478c588dced98cb61fea) with the patch below still
> > shows the problem. Any ideas Peter or Ingo (or anyone, really :)?
> >
> >
> > diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> > index da7c061..a7cc22a 100644
> > --- a/kernel/sched_fair.c
> > +++ b/kernel/sched_fair.c
> > @@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
> > struct task_struct *curr = rq->curr;
> > struct cfs_rq *cfs_rq = task_cfs_rq(curr);
> > struct sched_entity *se = &curr->se, *pse = &p->se;
> > - unsigned long gran;
> >
> > if (unlikely(rt_prio(p->prio))) {
> > update_rq_clock(rq);
> > @@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
> > pse = parent_entity(pse);
> > }
> >
> > - gran = sysctl_sched_wakeup_granularity;
> > - if (unlikely(se->load.weight != NICE_0_LOAD))
> > - gran = calc_delta_fair(gran, &se->load);
> >
> > - if (pse->vruntime + gran < se->vruntime)
> > + if (pse->vruntime + sysctl_sched_wakeup_granularity < se->vruntime)
> > resched_task(curr);
> > }
> >
>
> Most curious; are you sure its not a bisection problem?
Quite sure.
> Does ppc32 (or your instance thereof) have a high resolution
> sched_clock()?
I'm not sure (FWIW, we did get support for NO_HZ and HIGH_RES_TIMERS in
2.6.24-rc as well, but playing with these config options and even
reverting the code didn't seem to have any effect), can someone from the
linuxppc-dev list answer this?
> Another question, do you have:
> CONFIG_FAIR_GROUP_SCHED=y
>
> if so, does flipping that off have any effect?
I tried both, no difference that I could tell.
Is there any debugging information I could provide from running the test
on kernels built from at and before the change in question?
Thanks,
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Mel Gorman @ 2008-01-23 13:41 UTC (permalink / raw)
To: Olaf Hering
Cc: lee.schermerhorn, Linux MM, linux-kernel, linuxppc-dev,
Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan, akpm,
KAMEZAWA Hiroyuki, Christoph Lameter
In-Reply-To: <20080123121459.GA18631@aepfle.de>
On (23/01/08 13:14), Olaf Hering didst pronounce:
> On Wed, Jan 23, Mel Gorman wrote:
>
> > Sorry this is dragging out. Can you post the full dmesg with loglevel=8 of the
> > following patch against 2.6.24-rc8 please? It contains the debug information
> > that helped me figure out what was going wrong on the PPC64 machine here,
> > the revert and the !l3 checks (i.e. the two patches that made machines I
> > have access to work). Thanks
>
> It boots with your change.
>
....... Nice one! As the only addition here is debugging output, I can
only assume that the two patches were being booted in isolation instead
of combination earlier. The two threads have been a little confused with
hand waving so that can easily happen.
Looking at your log;
> early_node_map[1] active PFN ranges
> 1: 0 -> 892928
All memory on node 1
> Online nodes
> o 0
> o 1
> Nodes with regular memory
> o 1
> Current running CPU 0 is associated with node 0
> Current node is 0
Running CPU associated with node 0 so other than being node 1 instead of
node 2, your machine is similar to the one I had the problem on in terms
of memoryless nodes and CPU configuration.
> VFS: Cannot open root device "<NULL>" or unknown-block(0,0)
> Please append a correct "root=" boot option; here are the available partitions:
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
> Rebooting in 1 seconds..
>
I see it failed to complete boot but I'm going to assume this is a relatively
normal commane-line, .config or initrd problem and not a regression of
some type.
I'll post a patch suitable for pick-up shortly. The two patches ran in
combination with CONFIG_DEBUG_SLAB a compile-based stress tests without
difficulty so hopefully there is not new surprises hiding in the corners.
Thanks Olaf.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
From: Koss, Mike (Mission Systems) @ 2008-01-23 13:43 UTC (permalink / raw)
To: Mohammad Sadegh Sadri, David Baird, linuxppc-embedded
In-Reply-To: <BAY115-W415137ADEA0BE4A33D2BAEB23F0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 3265 bytes --]
Actually, with the MPMC3 the XPS_LL_TEMAC still can directly connect to
the MPMC. You set one of the ports' type to SDMA and it instantiates
what is similar to the old CDMAC.
________________________________
From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
Sent: Wednesday, January 23, 2008 2:36 AM
To: Koss, Mike (Mission Systems); David Baird;
linuxppc-embedded@ozlabs.org
Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
Hi
Well, As you know, we now need a PLB version, XPS_LL_TEMAC is connected
to PLB not MPMC2...yes I remember those days of Xilinx GSRD and MPMC2
however it seems that the current architecture has slight changes.
about the git repository of Xilinx, Although I do not believe on it,
I'll give it a try...thanks for info.
well, what about Grant Likely... and his git tree?
________________________________
Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
Date: Mon, 21 Jan 2008 11:44:14 -0600
From: mike.koss@ngc.com
To: mamsadegh@hotmail.com; dhbaird@gmail.com;
linuxppc-embedded@ozlabs.org
In case anyone is interested, I'm currently working on an
almost-kernel-ready version that will be self-contained based on the
LL-DMA version (the native MPMC port, not the PLB). It's based upon the
old adapter from MontaVista, that I originally ported to 2.6 and the
MPMC2. Unfortunately, it won't be ready for another few weeks since I'm
working on hardware images currently.
-- Mike
________________________________
From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
Sent: Monday, January 21, 2008 3:54 AM
To: David Baird; linuxppc-embedded@ozlabs.org
Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
thanks for you reply david,
As far as I know the Linux driver for Xilinx PLB TEMAC was two
parts : 1- adapter.c and 2- the rest of the driver files
Only adapter.c was really a linux related file and the rest of
the files were Xilinx generic driver code for PLB TEMAC.
correct?
then now, I know EDK 9.2 generates the needed Linux support
package and needed related files, so if this is the case can we use
these files as the needed driver in our linux kernel?
by the way, i did never hear about this git repository
before...can you describe us, where is it and how we can access it and
which projects are now hosted by it?
thanks
> Date: Mon, 21 Jan 2008 00:54:30 -0700
> From: dhbaird@gmail.com
> To: mamsadegh@hotmail.com
> Subject: Re: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
>
> On Jan 21, 2008 12:36 AM, Mohammad Sadegh Sadri
<mamsadegh@hotmail.com> wrote:
> > As you know Xilinx PLB TEMAC is a module which connects Hard
TEMAC in
> > Virtex-4 FX devices to PLB bus,
> > now, in the new release of EDK , EDK 9.2 Xilinx has added a
new interface
> > core , which is called XPS_LL_TEMAC and has a different
structure than
> > normal PLB TEMAC. spacially it has some additional data
transfer buses.
> >
> > Now the question is,... is there any linux driver available
for this new
> > core?
>
> Yes there is, but I had to use the git sources at:
>
> git.xilinx.com
________________________________
<http://>
________________________________
[-- Attachment #2: Type: text/html, Size: 4986 bytes --]
^ permalink raw reply
* [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
From: Mel Gorman @ 2008-01-23 13:55 UTC (permalink / raw)
To: akpm, Christoph Lameter, Pekka Enberg
Cc: lee.schermerhorn, Olaf Hering, Linux MM, linux-kernel,
linuxppc-dev, Aneesh Kumar K.V, hanth Aravamudan,
KAMEZAWA Hiroyuki
In-Reply-To: <20080123125236.GA18876@aepfle.de>
This patch in combination with a partial revert of commit
04231b3002ac53f8a64a7bd142fde3fa4b6808c6 fixes a regression between 2.6.23
and 2.6.24-rc8 where a PPC64 machine with all CPUS on a memoryless node fails
to boot. If approved by the SLAB maintainers, it should be merged for 2.6.24.
With memoryless-node configurations, it is possible that all the CPUs are
associated with a node with no memory. Early in the boot process, nodelists
are not setup that allow fallback_alloc to work, an Oops occurs and the
machine fails to boot.
This patch adds the necessary checks to make sure a kmem_list3 exists for
the preferred node used when growing the cache. If the preferred node has
no nodelist then the currently running node is used instead. This
problem only affects the SLAB allocator, SLUB appears to work fine.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---
mm/slab.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-005-revert-memoryless-slab/mm/slab.c linux-2.6.24-rc8-010_handle_missing_l3/mm/slab.c
--- linux-2.6.24-rc8-005-revert-memoryless-slab/mm/slab.c 2008-01-22 17:46:32.000000000 +0000
+++ linux-2.6.24-rc8-010_handle_missing_l3/mm/slab.c 2008-01-22 18:42:53.000000000 +0000
@@ -2775,6 +2775,11 @@ static int cache_grow(struct kmem_cache
/* Take the l3 list lock to change the colour_next on this node */
check_irq_off();
l3 = cachep->nodelists[nodeid];
+ if (!l3) {
+ nodeid = numa_node_id();
+ l3 = cachep->nodelists[nodeid];
+ }
+ BUG_ON(!l3);
spin_lock(&l3->list_lock);
/* Get colour for the slab, and cal the next value. */
@@ -3317,6 +3322,10 @@ static void *____cache_alloc_node(struct
int x;
l3 = cachep->nodelists[nodeid];
+ if (!l3) {
+ nodeid = numa_node_id();
+ l3 = cachep->nodelists[nodeid];
+ }
BUG_ON(!l3);
retry:
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH 2/3 v3] Add initial iomega StorCenter board port.
From: Jon Loeliger @ 2008-01-23 14:05 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20080123105111.125f075d.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi Jon,
>
> On Tue, 22 Jan 2008 16:37:59 -0600 Jon Loeliger <jdl@jdl.com> wrote:
>> +++ b/arch/powerpc/platforms/embedded6xx/storcenter.c
>
>> +extern void _nmask_and_or_msr(unsigned long nmask, unsigned long or_val);
>
> This clearly needs to be decalred in some header file. (I know you did
> not introduce it.) In arch/ppc, it was declared in asm/system.h (but I
> don't know if that is appropriate for arch/powerpc). Maybe you could do
> a preceeding patch that does this and fixes the other user.
I hear my Janitorial Karmic Duty calling.
>> +static void __init storcenter_init_IRQ(void)
>> + prop = of_get_property(dnp, "reg", &size);
>> + paddr = (phys_addr_t)of_translate_address(dnp, prop);
>
> What happens of "prop" is NULL?
Someone should fix that case too. :-)
Kumar,
I'll respin this trio for you.
jdl
^ permalink raw reply
* Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
From: Pekka J Enberg @ 2008-01-23 14:18 UTC (permalink / raw)
To: Mel Gorman
Cc: lee.schermerhorn, Olaf Hering, Linux MM, linux-kernel,
linuxppc-dev, Aneesh Kumar K.V, hanth Aravamudan, akpm,
KAMEZAWA Hiroyuki, Christoph Lameter
In-Reply-To: <20080123135513.GA14175@csn.ul.ie>
Hi Mel,
On Wed, 23 Jan 2008, Mel Gorman wrote:
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-005-revert-memoryless-slab/mm/slab.c linux-2.6.24-rc8-010_handle_missing_l3/mm/slab.c
> --- linux-2.6.24-rc8-005-revert-memoryless-slab/mm/slab.c 2008-01-22 17:46:32.000000000 +0000
> +++ linux-2.6.24-rc8-010_handle_missing_l3/mm/slab.c 2008-01-22 18:42:53.000000000 +0000
> @@ -2775,6 +2775,11 @@ static int cache_grow(struct kmem_cache
> /* Take the l3 list lock to change the colour_next on this node */
> check_irq_off();
> l3 = cachep->nodelists[nodeid];
> + if (!l3) {
> + nodeid = numa_node_id();
> + l3 = cachep->nodelists[nodeid];
> + }
> + BUG_ON(!l3);
> spin_lock(&l3->list_lock);
>
> /* Get colour for the slab, and cal the next value. */
> @@ -3317,6 +3322,10 @@ static void *____cache_alloc_node(struct
> int x;
>
> l3 = cachep->nodelists[nodeid];
> + if (!l3) {
> + nodeid = numa_node_id();
> + l3 = cachep->nodelists[nodeid];
> + }
What guarantees that current node ->nodelists is never NULL?
I still think Christoph's kmem_getpages() patch is correct (to fix
cache_grow() oops) but I overlooked the fact that none the callers of
____cache_alloc_node() deal with bootstrapping (with the exception of
__cache_alloc_node() that even has a comment about it).
But what I am really wondering about is, why wasn't the
N_NORMAL_MEMORY revert enough? I assume this used to work before so what
more do we need to revert for 2.6.24?
Pekka
^ permalink raw reply
* Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
From: Olaf Hering @ 2008-01-23 14:27 UTC (permalink / raw)
To: Mel Gorman
Cc: lee.schermerhorn, linuxppc-dev, linux-kernel, Linux MM,
Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan, akpm,
KAMEZAWA Hiroyuki, Christoph Lameter
In-Reply-To: <20080123135513.GA14175@csn.ul.ie>
On Wed, Jan 23, Mel Gorman wrote:
> This patch in combination with a partial revert of commit
> 04231b3002ac53f8a64a7bd142fde3fa4b6808c6 fixes a regression between 2.6.23
> and 2.6.24-rc8 where a PPC64 machine with all CPUS on a memoryless node fails
> to boot. If approved by the SLAB maintainers, it should be merged for 2.6.24.
This change alone does not help, its not the version I tested.
Will all the changes below go into 2.6.24 as well, in a seperate patch?
- for_each_node_state(node, N_NORMAL_MEMORY) {
+ for_each_online_node(node) {
^ permalink raw reply
* Re: [PATCHv2] i2c: adds support for i2c bus on Frescale CPM1/CPM2 controllers
From: Jon Smirl @ 2008-01-23 14:28 UTC (permalink / raw)
To: Jean Delvare
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Linux I2C,
Scott Wood
In-Reply-To: <20080123140232.67273b22@hyperion.delvare>
On 1/23/08, Jean Delvare <khali@linux-fr.org> wrote:
> Hallo Jochen,
>
> On Wed, 23 Jan 2008 12:23:58 +0100, Jochen Friedrich wrote:
> > Hi Jean,
> >
> > > Do you have an updated patch addressing Stephen's comment?
> > >
> > > Note: you'd rather send updates of this patch to the i2c list rather
> > > than LKML.
> >
> > I'm currently looking at that last patches from Jon and try to make this
> > driver fit in there (+ the class override stuff).
>
> I'm not sure what patches exactly you're talking about, but the
> aliasing stuff Jon and myself have been working on are still under
> debate. Your patch shouldn't assume that any of these patches will go
> upstream immediately, so your patch adding the i2c-cpm driver can
> ignore them. I'll update the patches before merging them as needed, do
> not worry too much about that.
He wants the module name translation support I split out into powerpc-common.c.
>
> > Note: will do. I just subscribed to this list.
>
> Note hat you do not need to be subscribed to post to the i2c list (but
> of course, if you have some interest in Linux i2c development,
> subscribing was a good idea anyway.)
>
> --
> Jean Delvare
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 2/3] Convert PowerPC MPC i2c to of_platform_driver from platform_driver
From: Jon Loeliger @ 2008-01-23 14:31 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c
In-Reply-To: <20080123020914.31675.35659.stgit@terra.home>
So, like, the other day Jon Smirl mumbled:
> Convert MPC i2c driver from a platform_driver to a
> of_platform_driver. Add the ability to dynamically load i2c drivers
> based on device tree names. Routine names were changed from fsl_ to
> mpc_ to make them match the file name. Common code moved to
> powerpc-common.* Orginal ppc driver left intact for deletion when ppc
> arch is removed.
This seems backwards to me. I was under the impression
that our trend was _toward_ "Freescale" and "fsl" names...?
And aren't the drivers also already using "fsl-i2c" in the
DTS files as called out in the b-w-o.txt too?
Grumble long lines not hard-limited to 70-ish columns,
yes, even in log messages... :-)
jdl
^ permalink raw reply
* Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
From: Pekka J Enberg @ 2008-01-23 14:32 UTC (permalink / raw)
To: Mel Gorman
Cc: lee.schermerhorn, Olaf Hering, Linux MM, linux-kernel,
linuxppc-dev, Aneesh Kumar K.V, hanth Aravamudan, akpm,
KAMEZAWA Hiroyuki, Christoph Lameter
In-Reply-To: <Pine.LNX.4.64.0801231611160.20050@sbz-30.cs.Helsinki.FI>
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
> I still think Christoph's kmem_getpages() patch is correct (to fix
> cache_grow() oops) but I overlooked the fact that none the callers of
> ____cache_alloc_node() deal with bootstrapping (with the exception of
> __cache_alloc_node() that even has a comment about it).
So something like this (totally untested) patch on top of current git:
---
mm/slab.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
Index: linux-2.6/mm/slab.c
===================================================================
--- linux-2.6.orig/mm/slab.c
+++ linux-2.6/mm/slab.c
@@ -1668,7 +1668,11 @@ static void *kmem_getpages(struct kmem_c
if (cachep->flags & SLAB_RECLAIM_ACCOUNT)
flags |= __GFP_RECLAIMABLE;
- page = alloc_pages_node(nodeid, flags, cachep->gfporder);
+ if (nodeid == -1)
+ page = alloc_pages(flags, cachep->gfporder);
+ else
+ page = alloc_pages_node(nodeid, flags, cachep->gfporder);
+
if (!page)
return NULL;
@@ -2976,8 +2980,9 @@ retry:
batchcount = BATCHREFILL_LIMIT;
}
l3 = cachep->nodelists[node];
+ if (!l3)
+ return NULL;
- BUG_ON(ac->avail > 0 || !l3);
spin_lock(&l3->list_lock);
/* See if we can refill from the shared array */
@@ -3317,7 +3322,8 @@ static void *____cache_alloc_node(struct
int x;
l3 = cachep->nodelists[nodeid];
- BUG_ON(!l3);
+ if (!l3)
+ return fallback_alloc(cachep, flags);
retry:
check_irq_off();
@@ -3394,12 +3400,6 @@ __cache_alloc_node(struct kmem_cache *ca
if (unlikely(nodeid == -1))
nodeid = numa_node_id();
- if (unlikely(!cachep->nodelists[nodeid])) {
- /* Node not bootstrapped yet */
- ptr = fallback_alloc(cachep, flags);
- goto out;
- }
-
if (nodeid == numa_node_id()) {
/*
* Use the locally cached objects if possible.
^ permalink raw reply
* Re: [PATCH 2/3] Convert PowerPC MPC i2c to of_platform_driver from platform_driver
From: Jon Smirl @ 2008-01-23 14:40 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, i2c
In-Reply-To: <E1JHgdB-0002zV-F4@jdl.com>
On 1/23/08, Jon Loeliger <jdl@jdl.com> wrote:
> So, like, the other day Jon Smirl mumbled:
> > Convert MPC i2c driver from a platform_driver to a
> > of_platform_driver. Add the ability to dynamically load i2c drivers
> > based on device tree names. Routine names were changed from fsl_ to
> > mpc_ to make them match the file name. Common code moved to
> > powerpc-common.* Orginal ppc driver left intact for deletion when ppc
> > arch is removed.
>
> This seems backwards to me. I was under the impression
> that our trend was _toward_ "Freescale" and "fsl" names...?
> And aren't the drivers also already using "fsl-i2c" in the
> DTS files as called out in the b-w-o.txt too?
The routine names should match the file name which then determines the
module name. I didn't want to change the module name so I made the
routines names match the module name.
>
> Grumble long lines not hard-limited to 70-ish columns,
> yes, even in log messages... :-)
>
> jdl
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
From: Mel Gorman @ 2008-01-23 14:42 UTC (permalink / raw)
To: Olaf Hering
Cc: lee.schermerhorn, linuxppc-dev, linux-kernel, Linux MM,
Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan, akpm,
KAMEZAWA Hiroyuki, Christoph Lameter
In-Reply-To: <20080123142759.GB19161@aepfle.de>
On (23/01/08 15:27), Olaf Hering didst pronounce:
> On Wed, Jan 23, Mel Gorman wrote:
>
> > This patch in combination with a partial revert of commit
> > 04231b3002ac53f8a64a7bd142fde3fa4b6808c6 fixes a regression between 2.6.23
> > and 2.6.24-rc8 where a PPC64 machine with all CPUS on a memoryless node fails
> > to boot. If approved by the SLAB maintainers, it should be merged for 2.6.24.
>
> This change alone does not help, its not the version I tested.
> Will all the changes below go into 2.6.24 as well, in a seperate patch?
>
> - for_each_node_state(node, N_NORMAL_MEMORY) {
> + for_each_online_node(node) {
Those changes are already in a separate patch and have been sent. I don't
see it in git yet but it should be on the way.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
From: Pekka J Enberg @ 2008-01-23 14:49 UTC (permalink / raw)
To: Mel Gorman
Cc: lee.schermerhorn, Olaf Hering, Linux MM, linux-kernel,
linuxppc-dev, Aneesh Kumar K.V, hanth Aravamudan, akpm,
KAMEZAWA Hiroyuki, Christoph Lameter
In-Reply-To: <Pine.LNX.4.64.0801231626320.21475@sbz-30.cs.Helsinki.FI>
Hi,
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
> > I still think Christoph's kmem_getpages() patch is correct (to fix
> > cache_grow() oops) but I overlooked the fact that none the callers of
> > ____cache_alloc_node() deal with bootstrapping (with the exception of
> > __cache_alloc_node() that even has a comment about it).
>
> So something like this (totally untested) patch on top of current git:
Sorry, removed a BUG_ON() from cache_alloc_refill() by mistake, here's a
better one:
[PATCH] slab: fix allocation on memoryless nodes
From: Pekka Enberg <penberg@cs.helsinki.fi>
As memoryless nodes do not have a nodelist, change cache_alloc_refill() to bail
out for those and let ____cache_alloc_node() always deal with that by resorting
to fallback_alloc().
Furthermore, don't let kmem_getpages() call alloc_pages_node() if nodeid passed
to it is -1 as the latter will always translate that to numa_node_id() which
might not have ->nodelist that caused the invocation of fallback_alloc() in the
first place (for example, during bootstrap).
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
mm/slab.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
Index: linux-2.6/mm/slab.c
===================================================================
--- linux-2.6.orig/mm/slab.c
+++ linux-2.6/mm/slab.c
@@ -1668,7 +1668,11 @@ static void *kmem_getpages(struct kmem_c
if (cachep->flags & SLAB_RECLAIM_ACCOUNT)
flags |= __GFP_RECLAIMABLE;
- page = alloc_pages_node(nodeid, flags, cachep->gfporder);
+ if (nodeid == -1)
+ page = alloc_pages(flags, cachep->gfporder);
+ else
+ page = alloc_pages_node(nodeid, flags, cachep->gfporder);
+
if (!page)
return NULL;
@@ -2975,9 +2979,11 @@ retry:
*/
batchcount = BATCHREFILL_LIMIT;
}
+ BUG_ON(ac->avail > 0);
l3 = cachep->nodelists[node];
+ if (!l3)
+ return NULL;
- BUG_ON(ac->avail > 0 || !l3);
spin_lock(&l3->list_lock);
/* See if we can refill from the shared array */
@@ -3317,7 +3323,8 @@ static void *____cache_alloc_node(struct
int x;
l3 = cachep->nodelists[nodeid];
- BUG_ON(!l3);
+ if (!l3)
+ return fallback_alloc(cachep, flags);
retry:
check_irq_off();
@@ -3394,12 +3401,6 @@ __cache_alloc_node(struct kmem_cache *ca
if (unlikely(nodeid == -1))
nodeid = numa_node_id();
- if (unlikely(!cachep->nodelists[nodeid])) {
- /* Node not bootstrapped yet */
- ptr = fallback_alloc(cachep, flags);
- goto out;
- }
-
if (nodeid == numa_node_id()) {
/*
* Use the locally cached objects if possible.
^ permalink raw reply
* Re: CONFIG_PCI interaction with pata_platform driver on MPC834x board
From: Johns Daniel @ 2008-01-23 15:06 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <ba5d9360712210737h133fd831vbfb7c9f996c6df7c@mail.gmail.com>
I am asking this question once more since my previous try -- right
before the Christmas break -- did not elicit any responses! ;~)
Without PCI support configured in the kernel, the CompactFlash card is
discovered and configured by the kernel. With PCI support configured
in the kernel, it fails to discover the CF card through the
pata_platform driver.
(Note that both PCI and CF work fine on this same board with the
generic IDE driver!)
There are only two differences that I notice between the two kernel
setups that might be significant:
1.) The libata virq changes from 19 to 20.
2.) The isa_io_base changes from 0x0 to 0xfcfff000.
Are either of these two changes significant?
I am using the "arch/powerpc" kernel, version 2.6.20.21. The CF is
wired directly to the local bus in True IDE mode.
I have some debug info included in my previous message at:
http://www.nabble.com/CONFIG_PCI-interaction-with-pata_platform-driver-on-MPC834x-board-tc14457502.html
TIA!
-- Johns
^ permalink raw reply
* RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
From: Mohammad Sadegh Sadri @ 2008-01-23 15:12 UTC (permalink / raw)
To: Koss, Mike (Mission Systems), David Baird, linuxppc-embedded
In-Reply-To: <EDAE140DF1B2FC42B5867C22CA0B333F0A5959@XMBIL132.northgrum.com>
[-- Attachment #1: Type: text/plain, Size: 3699 bytes --]
So, in this case, our base system, created with EDK 9.2 will not be the same as previous systems, as shown in
http://www.xilinx.com/esp/wired/optical/xlnx_net/mpmc.htm
PLB and OPB usage is limited to a small area of design...
Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
Date: Wed, 23 Jan 2008 07:43:14 -0600
From: mike.koss@ngc.com
To: mamsadegh@hotmail.com; dhbaird@gmail.com; linuxppc-embedded@ozlabs.org
Actually, with the MPMC3 the XPS_LL_TEMAC still can
directly connect to the MPMC. You set one of the ports' type to SDMA and it
instantiates what is similar to the old CDMAC.
From: Mohammad Sadegh Sadri
[mailto:mamsadegh@hotmail.com]
Sent: Wednesday, January 23, 2008 2:36
AM
To: Koss, Mike (Mission Systems); David Baird;
linuxppc-embedded@ozlabs.org
Subject: RE: Xilinx XPS_LL_TEMAC vs
PLB_TEMAC
Hi
Well, As you know, we now need a PLB version, XPS_LL_TEMAC
is connected to PLB not MPMC2...yes I remember those days of Xilinx GSRD and
MPMC2 however it seems that the current architecture has slight changes.
about the git repository of Xilinx, Although I do not believe on it,
I'll give it a try...thanks for info.
well, what about Grant Likely...
and his git tree?
Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
Date: Mon, 21 Jan 2008
11:44:14 -0600
From: mike.koss@ngc.com
To: mamsadegh@hotmail.com;
dhbaird@gmail.com; linuxppc-embedded@ozlabs.org
In case anyone is interested, I'm currently
working on an almost-kernel-ready version that will be self-contained based on
the LL-DMA version (the native MPMC port, not the PLB). It's based upon the
old adapter from MontaVista, that I originally ported to 2.6 and the MPMC2.
Unfortunately, it won't be ready for another few weeks since I'm working on
hardware images currently.
-- Mike
From: Mohammad Sadegh Sadri
[mailto:mamsadegh@hotmail.com]
Sent: Monday, January 21, 2008 3:54
AM
To: David Baird; linuxppc-embedded@ozlabs.org
Subject:
RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
thanks for you reply david,
As far as I know the Linux
driver for Xilinx PLB TEMAC was two parts : 1- adapter.c and 2- the rest of
the driver files
Only adapter.c was really a linux related file and the
rest of the files were Xilinx generic driver code for PLB
TEMAC.
correct?
then now, I know EDK 9.2 generates the needed
Linux support package and needed related files, so if this is the case can we
use these files as the needed driver in our linux kernel?
by the way, i
did never hear about this git repository before...can you describe us, where
is it and how we can access it and which projects are now hosted by
it?
thanks
> Date: Mon, 21 Jan 2008 00:54:30
-0700
> From: dhbaird@gmail.com
> To:
mamsadegh@hotmail.com
> Subject: Re: Xilinx XPS_LL_TEMAC vs
PLB_TEMAC
>
> On Jan 21, 2008 12:36 AM, Mohammad Sadegh Sadri
<mamsadegh@hotmail.com> wrote:
> > As you know Xilinx PLB TEMAC
is a module which connects Hard TEMAC in
> > Virtex-4 FX devices to
PLB bus,
> > now, in the new release of EDK , EDK 9.2 Xilinx has
added a new interface
> > core , which is called XPS_LL_TEMAC and has
a different structure than
> > normal PLB TEMAC. spacially it has
some additional data transfer buses.
> >
> > Now the
question is,... is there any linux driver available for this new
> >
core?
>
> Yes there is, but I had to use the git sources
at:
>
> git.xilinx.com
_________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 5585 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix boot problem in situations where the boot CPU is running on a memoryless node
From: Mel Gorman @ 2008-01-23 15:56 UTC (permalink / raw)
To: Pekka J Enberg
Cc: lee.schermerhorn, Olaf Hering, Linux MM, linux-kernel,
linuxppc-dev, Aneesh Kumar K.V, hanth Aravamudan, akpm,
KAMEZAWA Hiroyuki, Christoph Lameter
In-Reply-To: <Pine.LNX.4.64.0801231648140.23343@sbz-30.cs.Helsinki.FI>
On (23/01/08 16:49), Pekka J Enberg didst pronounce:
> Hi,
>
> On Wed, 23 Jan 2008, Pekka J Enberg wrote:
> > > I still think Christoph's kmem_getpages() patch is correct (to fix
> > > cache_grow() oops) but I overlooked the fact that none the callers of
> > > ____cache_alloc_node() deal with bootstrapping (with the exception of
> > > __cache_alloc_node() that even has a comment about it).
> >
> > So something like this (totally untested) patch on top of current git:
>
> Sorry, removed a BUG_ON() from cache_alloc_refill() by mistake, here's a
> better one:
>
Applied in combination with the N_NORMAL_MEMORY revert and it fails to
boot. Console is as follows;
Linux version 2.6.24-rc8-autokern1 (root@gekko-lp3.ltc.austin.ibm.com)
(gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)) #2 SMP Wed Jan 23
10:37:36 EST 2008
[boot]0012 Setup Arch
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Zone PFN ranges:
DMA 0 -> 1048576
Normal 1048576 -> 1048576
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
2: 0 -> 1048576
Could not find start_pfn for node 0
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on. Total pages: 1034240
Policy zone: DMA
Kernel command line: ro console=hvc0 autobench_args: root=/dev/sda6
ABAT:1201101591 loglevel=8
[boot]0020 XICS Init
xics: no ISA interrupt controller
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 238.059000 MHz
time_init: processor frequency = 1904.472000 MHz
clocksource: timebase mult[10cd746] shift[22] registered
clockevent: decrementer mult[3cf1] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [hvc0]
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
freeing bootmem node 2
Memory: 4105560k/4194304k available (5004k kernel code, 88744k reserved,
876k data, 559k bss, 272k init)
Unable to handle kernel paging request for data at address 0x00000040
Faulting instruction address: 0xc0000000003c8ae8
cpu 0x0: Vector: 300 (Data Access) at [c0000000005c3840]
pc: c0000000003c8ae8: __lock_text_start+0x20/0x88
lr: c0000000000dadb4: .cache_grow+0x7c/0x338
sp: c0000000005c3ac0
msr: 8000000000009032
dar: 40
dsisr: 40000000
current = 0xc000000000500f10
paca = 0xc000000000501b80
pid = 0, comm = swapper
enter ? for help
[c0000000005c3b40] c0000000000dadb4 .cache_grow+0x7c/0x338
[c0000000005c3c00] c0000000000db518 .fallback_alloc+0x1c0/0x224
[c0000000005c3cb0] c0000000000db920 .kmem_cache_alloc+0xe0/0x14c
[c0000000005c3d50] c0000000000dcbd0 .kmem_cache_create+0x230/0x4cc
[c0000000005c3e30] c0000000004c049c .kmem_cache_init+0x1ec/0x51c
[c0000000005c3ee0] c00000000049f8d8 .start_kernel+0x304/0x3fc
[c0000000005c3f90] c000000000008594 .start_here_common+0x54/0xc0
0xc0000000000dadb4 is in cache_grow (mm/slab.c:2782).
2777 local_flags = flags & (GFP_CONSTRAINT_MASK|GFP_RECLAIM_MASK);
2778
2779 /* Take the l3 list lock to change the colour_next on this node */
2780 check_irq_off();
2781 l3 = cachep->nodelists[nodeid];
2782 spin_lock(&l3->list_lock);
2783
2784 /* Get colour for the slab, and cal the next value. */
2785 offset = l3->colour_next;
2786 l3->colour_next++;
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* [PATCHv2 0/8] [POWERPC] 8xx cleanups
From: Jochen Friedrich @ 2008-01-23 15:58 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Scott Wood, linuxppc-dev list, Kernel, Linux
Hi,
this is a series against paulus for-2.6.25 tree to clean up various 8xx related stuff.
The series can be pulled from git://git.bocc.de/dbox2.git cleanup.
Patch 6 has been modified to remove the #ifdefs as suggested by Arndt Bergmann.
Patch 8 is a new one.
[POWERPC] Remove unused m8xx_cpm_hostalloc/free/dump()
[POWERPC] Rename m8xx_pic_init to mpc8xx_pics_init
[POWERPC] Remove unneeded and misspelled prototype m8xx_calibrate_decr
[POWERPC] Remove declaration of m8xx_pic_init.
[POWERPC] Remove sysdev/commproc.h
[POWERPC] Get rid of conditional includes of board specific setup
[POWERPC] Rename commproc to cpm1 and cpm2_common.c to cpm2.c
[POWERPC] Move definition of buffer descriptor to cpm.h
Thanks,
Jochen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox