* Re: crash in kmem_cache_init
From: Olaf Hering @ 2008-01-23 7:58 UTC (permalink / raw)
To: Christoph Lameter
Cc: lee.schermerhorn, Linux MM, Mel Gorman, linux-kernel,
linuxppc-dev, Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan,
akpm, KAMEZAWA Hiroyuki
In-Reply-To: <Pine.LNX.4.64.0801221417480.1912@schroedinger.engr.sgi.com>
On Tue, Jan 22, Christoph Lameter wrote:
> > 0xc0000000000fe018 is in setup_cpu_cache (/home/olaf/kernel/git/linux-2.6-numa/mm/slab.c:2111).
> > 2106 BUG_ON(!cachep->nodelists[node]);
> > 2107 kmem_list3_init(cachep->nodelists[node]);
> > 2108 }
> > 2109 }
> > 2110 }
>
> if (cachep->nodelists[numa_node_id()])
> return;
Does not help.
Linux version 2.6.24-rc8-ppc64 (olaf@lingonberry) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #48 SMP Wed Jan 23 08:54:23 CET 2008
[boot]0012 Setup Arch
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 8192 bytes
Zone PFN ranges:
DMA 0 -> 892928
Normal 892928 -> 892928
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
1: 0 -> 892928
Could not find start_pfn for node 0
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on. Total pages: 880720
Policy zone: DMA
Kernel command line: debug xmon=on panic=1
[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 = 275.070000 MHz
time_init: processor frequency = 2197.800000 MHz
clocksource: timebase mult[e8ab05] shift[22] registered
clockevent: decrementer mult[466a] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg-1] -> 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 1
Memory: 3496632k/3571712k available (6188k kernel code, 75080k reserved, 1324k data, 1220k bss, 304k init)
Kernel panic - not syncing: kmem_cache_create(): failed to create slab `size-32(DMA)'
Rebooting in 1 seconds..
---
mm/slab.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 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 +
@@ -2108,6 +2108,8 @@ static int __init_refok setup_cpu_cache(
}
}
}
+ if (!cachep->nodelists[numa_node_id()])
+ return -ENODEV;
cachep->nodelists[numa_node_id()]->next_reap =
jiffies + REAPTIMEOUT_LIST3 +
((unsigned long)cachep) % REAPTIMEOUT_LIST3;
@@ -2775,6 +2777,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 +3324,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 +3826,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: crash in kmem_cache_init
From: Pekka Enberg @ 2008-01-23 8:19 UTC (permalink / raw)
To: Christoph Lameter
Cc: lee.schermerhorn, Olaf Hering, Linux MM, Mel Gorman, linux-kernel,
linuxppc-dev, Aneesh Kumar K.V, hanth Aravamudan, akpm,
KAMEZAWA Hiroyuki
In-Reply-To: <Pine.LNX.4.64.0801221517260.2871@schroedinger.engr.sgi.com>
Hi Christoph,
On Jan 23, 2008 1:18 AM, Christoph Lameter <clameter@sgi.com> wrote:
> My patch is useless (fascinating history of the changelog there through).
> fallback_alloc calls kmem_getpages without GFP_THISNODE. This means that
> alloc_pages_node() will try to allocate on the current node but fallback
> to neighboring node if nothing is there....
Sure, but I was referring to the scenario where current node _has_
pages available but no ->nodelists. Olaf, did you try it?
Pekka
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Olaf Hering @ 2008-01-23 8:40 UTC (permalink / raw)
To: Pekka Enberg
Cc: lee.schermerhorn, Linux MM, Mel Gorman, linux-kernel,
linuxppc-dev, Aneesh Kumar K.V, hanth Aravamudan, akpm,
KAMEZAWA Hiroyuki, Christoph Lameter
In-Reply-To: <84144f020801230019i5ac6c8b1lfa5364672988b0c4@mail.gmail.com>
On Wed, Jan 23, Pekka Enberg wrote:
> Hi Christoph,
>
> On Jan 23, 2008 1:18 AM, Christoph Lameter <clameter@sgi.com> wrote:
> > My patch is useless (fascinating history of the changelog there through).
> > fallback_alloc calls kmem_getpages without GFP_THISNODE. This means that
> > alloc_pages_node() will try to allocate on the current node but fallback
> > to neighboring node if nothing is there....
>
> Sure, but I was referring to the scenario where current node _has_
> pages available but no ->nodelists. Olaf, did you try it?
Does not help.
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Juergen Beisert @ 2008-01-23 9:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mehlan, Markus (Ritter Elektronik)
In-Reply-To: <20080123002040.5049F24781@gemini.denx.de>
Wolfgang,
On Wednesday 23 January 2008 01:20, Wolfgang Denk wrote:
> In message <200801211728.22817.jbe@pengutronix.de> you wrote:
> > Is anybody out there with more MPC5200B experience? Can someone tell me
> > why some MPC5200B are need this patch and others not? We have two
> > different systems here (cards from different vendors) with the same
> > processor, one needs this BSDIS-patch and the other not. ???????????????
>
> Is it really exactly the same CPU revision? My guess is that one is
> rev. B and the other one is older...
The one who needs this patch (CPU card vendor 1):
MPC5200CVR400B, M62C REV 1, QCW0723T
The CPUs who do not need this patch (CPU card vendor 2):
SPC5200CBV400B, M62C REV 1, QAG0610C
MPC5200CVR400B, M62C REV 1, QAJ0613F
Best regards
Juergen Beisert
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [PATCH POWERPC] i2c: adds support for i2c bus on Frescale CPM1/CPM2 controllers
From: Jean Delvare @ 2008-01-23 10:23 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Scott Wood, linuxppc-dev, i2c, linux-kernel
In-Reply-To: <20071222001112.691b80c8@kernel.crashing.org>
On Sat, 22 Dec 2007 00:11:12 +0300, Vitaly Bordug wrote:
> On Fri, 21 Dec 2007 20:36:28 +0100
> Jochen Friedrich wrote:
>
> > Using the port of 2.4 code from Vitaly Bordug
> > <vitb@kernel.crashing.org> and the actual algorithm used by the i2c
> > driver of the DBox code on cvs.tuxboc.org from Tmbinc, Gillem
> > (htoa@gmx.net). Renamed i2c-rpx.c and i2c-algo-8xx.c to i2c-cpm.c and
> > converted the driver to an of_platform_driver.
> >
>
> I had an attempt a while ago to do this but haven't had enough time to get it completed, so
> I am glad to see it finally picked up. There was some sort of discussion that time, you seem to have some of those points
> addressed but something not, please
> check: http://lkml.org/lkml/2007/5/8/45
>
> (for instance, cpm_i2c_shutdown() and i2c_cpm_del_bus() are void because they cant' fail)
>
> Also, why this was directed to Scott? This is lm-sensors stuff and is
> Jean Delvare <khali@linux-fr.org> material...
This is _i2c_ stuff and doesn't have _anything_ to do with lm-sensors.
(Don't let the i2c list address fool you.)
As the i2c subsystem maintainer, I am very pleased when contributors
get their patches reviewed and tested by people with the knowledge and
access to the target architecture and hardware. So Jochen did the right
thing by sending this patch to Scott at first.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCHv2] i2c: adds support for i2c bus on Frescale CPM1/CPM2 controllers
From: Jean Delvare @ 2008-01-23 10:29 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Scott Wood, Stephen Rothwell, linux-kernel, linuxppc-dev
In-Reply-To: <20080103104121.58697148.sfr@canb.auug.org.au>
Hi Jochen,
Sorry for the late answer.
On Thu, 3 Jan 2008 10:41:21 +1100, Stephen Rothwell wrote:
> Hi Jochen,
>
> Just a few trivial things.
>
> On Wed, 02 Jan 2008 20:52:00 +0100 Jochen Friedrich <jochen@scram.de> wrote:
> >
> > +++ b/drivers/i2c/busses/i2c-cpm.c
> > +
> > +static irqreturn_t cpm_i2c_interrupt(int irq, void *dev_id)
> > +{
> > + struct i2c_adapter *adap;
> > + struct cpm_i2c *cpm;
> > + struct i2c_reg __iomem *i2c_reg;
> > + int i;
> > +
> > + adap = (struct i2c_adapter *) dev_id;
>
> This cast is unnecessary. In fact, you could just pass dev_id to the
> following call to i2c_get_adapdata() and eliminate adap completely.
>
> > + /* Get 'me going again.
> > + */
>
> For short comments, just make them one line. Similarly later as well.
>
> > + /* This chip can't do zero length writes. However, the i2c core uses
> > + them to scan for devices. The best we can do is to convert them
> > + into 1 byte reads */
>
> For multiline comments, we normally do
> /*
> * blah ...
> * more blah
> */
>
> > +static int cpm_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
> > +{
> > +
> > + while (tptr < num) {
> > + /* Check for outstanding messages */
> > + dev_dbg(&adap->dev, "test ready.\n");
> > + if (!(tbdf[tptr].cbd_sc & BD_SC_READY)) {
> > + dev_dbg(&adap->dev, "ready.\n");
> > + rmsg = &msgs[tptr];
> > + ret = cpm_i2c_check_message(adap, rmsg, tptr, rptr);
> > + tptr++;
> > + if (rmsg->flags & I2C_M_RD)
> > + rptr++;
> > + if (ret) {
> > + cpm_i2c_force_close(adap);
> > + mutex_unlock(&cpm->i2c_mutex);
> > + return ret;
> > + }
> > + } else {
> > + dev_dbg(&adap->dev, "not ready.\n");
> > + ret = wait_event_interruptible_timeout(cpm->i2c_wait,
> > + !(tbdf[tptr].cbd_sc & BD_SC_READY), 1 * HZ);
> > + if (ret == 0) {
> > + cpm_i2c_force_close(adap);
> > + dev_dbg(&adap->dev, "I2C read: timeout!\n");
> > + mutex_unlock(&cpm->i2c_mutex);
> > + return -EREMOTEIO;
> > + }
>
> You might want to consolidate the two error paths above using gotos to an
> error return section below.
>
> > +static void of_register_i2c_devices(struct i2c_adapter *adap,
> > + struct device_node *adap_node)
> > +{
> > + struct device_node *node = NULL;
> > +
> > + while ((node = of_get_next_child(adap_node, node))) {
>
> Use
> for_each_child_of_node(adap_node, node) {
> instead and you don't need to initialise "node" above.
>
> > +static struct of_device_id cpm_i2c_match[] = {
>
> const?
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.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Mel Gorman @ 2008-01-23 10:50 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: <20080123075821.GA17713@aepfle.de>
On (23/01/08 08:58), Olaf Hering didst pronounce:
> On Tue, Jan 22, Christoph Lameter wrote:
>
> > > 0xc0000000000fe018 is in setup_cpu_cache (/home/olaf/kernel/git/linux-2.6-numa/mm/slab.c:2111).
> > > 2106 BUG_ON(!cachep->nodelists[node]);
> > > 2107 kmem_list3_init(cachep->nodelists[node]);
> > > 2108 }
> > > 2109 }
> > > 2110 }
> >
> > if (cachep->nodelists[numa_node_id()])
> > return;
>
> Does not help.
>
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
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-clean/mm/slab.c linux-2.6.24-rc8-015_debug_slab/mm/slab.c
--- linux-2.6.24-rc8-clean/mm/slab.c 2008-01-16 04:22:48.000000000 +0000
+++ linux-2.6.24-rc8-015_debug_slab/mm/slab.c 2008-01-23 10:44:36.000000000 +0000
@@ -348,6 +348,7 @@ static int slab_early_init = 1;
static void kmem_list3_init(struct kmem_list3 *parent)
{
+ printk(" o kmem_list3_init\n");
INIT_LIST_HEAD(&parent->slabs_full);
INIT_LIST_HEAD(&parent->slabs_partial);
INIT_LIST_HEAD(&parent->slabs_free);
@@ -1236,6 +1237,7 @@ static int __cpuinit cpuup_prepare(long
* kmem_list3 and not this cpu's kmem_list3
*/
+ printk("cpuup_prepare %ld\n", cpu);
list_for_each_entry(cachep, &cache_chain, next) {
/*
* Set up the size64 kmemlist for cpu before we can
@@ -1243,6 +1245,7 @@ static int __cpuinit cpuup_prepare(long
* node has not already allocated this
*/
if (!cachep->nodelists[node]) {
+ printk(" o allocing %s %d\n", cachep->name, node);
l3 = kmalloc_node(memsize, GFP_KERNEL, node);
if (!l3)
goto bad;
@@ -1256,6 +1259,7 @@ static int __cpuinit cpuup_prepare(long
* protection here.
*/
cachep->nodelists[node] = l3;
+ printk(" o l3 setup\n");
}
spin_lock_irq(&cachep->nodelists[node]->list_lock);
@@ -1320,6 +1324,7 @@ static int __cpuinit cpuup_prepare(long
}
return 0;
bad:
+ printk(" o bad\n");
cpuup_canceled(cpu);
return -ENOMEM;
}
@@ -1405,6 +1410,7 @@ static void init_list(struct kmem_cache
spin_lock_init(&ptr->list_lock);
MAKE_ALL_LISTS(cachep, ptr, nodeid);
+ printk("init_list RESETTING %s node %d\n", cachep->name, nodeid);
cachep->nodelists[nodeid] = ptr;
local_irq_enable();
}
@@ -1427,10 +1433,23 @@ void __init kmem_cache_init(void)
numa_platform = 0;
}
+ printk("Online nodes\n");
+ for_each_online_node(node)
+ printk("o %d\n", node);
+ printk("Nodes with regular memory\n");
+ for_each_node_state(node, N_NORMAL_MEMORY)
+ printk("o %d\n", node);
+ printk("Current running CPU %d is associated with node %d\n",
+ smp_processor_id(),
+ cpu_to_node(smp_processor_id()));
+ printk("Current node is %d\n",
+ numa_node_id());
+
for (i = 0; i < NUM_INIT_LISTS; i++) {
kmem_list3_init(&initkmem_list3[i]);
if (i < MAX_NUMNODES)
cache_cache.nodelists[i] = NULL;
+ printk("kmem_cache_init Setting %s NULL %d\n", cache_cache.name, i);
}
/*
@@ -1468,6 +1487,8 @@ void __init kmem_cache_init(void)
cache_cache.colour_off = cache_line_size();
cache_cache.array[smp_processor_id()] = &initarray_cache.cache;
cache_cache.nodelists[node] = &initkmem_list3[CACHE_CACHE];
+ printk("kmem_cache_init Setting %s NULL %d\n", cache_cache.name, node);
+ printk("kmem_cache_init Setting %s initkmem_list3 %d\n", cache_cache.name, node);
/*
* struct kmem_cache size depends on nr_node_ids, which
@@ -1590,7 +1611,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,11 +1989,13 @@ static void __init set_up_list3s(struct
{
int node;
- for_each_node_state(node, N_NORMAL_MEMORY) {
+ printk("set_up_list3s %s index %d\n", cachep->name, index);
+ for_each_online_node(node) {
cachep->nodelists[node] = &initkmem_list3[index + node];
cachep->nodelists[node]->next_reap = jiffies +
REAPTIMEOUT_LIST3 +
((unsigned long)cachep) % REAPTIMEOUT_LIST3;
+ printk("set_up_list3s %s index %d\n", cachep->name, index);
}
}
@@ -2099,11 +2122,13 @@ static int __init_refok setup_cpu_cache(
g_cpucache_up = PARTIAL_L3;
} else {
int node;
- for_each_node_state(node, N_NORMAL_MEMORY) {
+ printk("setup_cpu_cache %s\n", cachep->name);
+ for_each_online_node(node) {
cachep->nodelists[node] =
kmalloc_node(sizeof(struct kmem_list3),
GFP_KERNEL, node);
BUG_ON(!cachep->nodelists[node]);
+ printk(" o allocated node %d\n", node);
kmem_list3_init(cachep->nodelists[node]);
}
}
@@ -2775,6 +2800,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 +3347,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,8 +3849,10 @@ 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) {
+ printk("alloc_kmemlist %s\n", cachep->name);
+ for_each_online_node(node) {
+ printk(" o node %d\n", node);
if (use_alien_caches) {
new_alien = alloc_alien_cache(node, cachep->limit);
if (!new_alien)
@@ -3837,6 +3873,7 @@ static int alloc_kmemlist(struct kmem_ca
l3 = cachep->nodelists[node];
if (l3) {
struct array_cache *shared = l3->shared;
+ printk(" o l3 exists\n");
spin_lock_irq(&l3->list_lock);
@@ -3856,10 +3893,12 @@ static int alloc_kmemlist(struct kmem_ca
free_alien_cache(new_alien);
continue;
}
+ printk(" o allocing l3\n");
l3 = kmalloc_node(sizeof(struct kmem_list3), GFP_KERNEL, node);
if (!l3) {
free_alien_cache(new_alien);
kfree(new_shared);
+ printk(" o allocing l3 failed\n");
goto fail;
}
@@ -3871,6 +3910,7 @@ static int alloc_kmemlist(struct kmem_ca
l3->free_limit = (1 + nr_cpus_node(node)) *
cachep->batchcount + cachep->num;
cachep->nodelists[node] = l3;
+ printk(" o setting node %d 0x%lX\n", node, (unsigned long)l3);
}
return 0;
@@ -3886,6 +3926,7 @@ fail:
free_alien_cache(l3->alien);
kfree(l3);
cachep->nodelists[node] = NULL;
+ printk(" o setting node %d FAIL NULL\n", node);
}
node--;
}
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* How to support removable CF card via IDE on MPC52xx
From: Henk Stegeman @ 2008-01-23 11:07 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
I have IDE working on my MPC5200B based system using the driver:
drivers/ide/ppc/mpc52xx_ide.
The IDE device is a compact flash card inserted in a compact flash slot on
the CPU board. Two separate pins (reset and card-detect) are provided to the
CPU to force a reset and to detect the presence of the compact-flash card.
Right now I don't use the card detection, the card is always in the slot,
but I want to be able to use the board without the card inserted.
What is the best way to let the kernel only use the compact flash card when
it is inserted?
Can/should I make use of PCMCIA, eventhough the interface is not PCMCIA
compatible? Can PCMCIA then make use of the allready working
drivers/ide/ppc/mpc52xx_ide driver?
Thanks in advance,
Henk Stegeman
[-- Attachment #2: Type: text/html, Size: 820 bytes --]
^ permalink raw reply
* Re: [PATCHv2] i2c: adds support for i2c bus on Frescale CPM1/CPM2 controllers
From: Jochen Friedrich @ 2008-01-23 11:23 UTC (permalink / raw)
To: Jean Delvare
Cc: Stephen Rothwell, linux-kernel, linuxppc-dev, Linux I2C,
Scott Wood
In-Reply-To: <20080123112941.23250948@hyperion.delvare>
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).
Note: will do. I just subscribed to this list.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] [POWERPC] Update TQM5200, CM5200 and Motion-PRO _defconfig and .dts files
From: Marian Balakowicz @ 2008-01-23 11:31 UTC (permalink / raw)
To: Olof Johansson, Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080118034103.GA17898@lixom.net>
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.
Cheers,
m.
^ permalink raw reply
* [PATCH v6] [POWERPC] Add LED driver for Promess Motion-PRO board.
From: Marian Balakowicz @ 2008-01-23 12:12 UTC (permalink / raw)
To: linuxppc-dev
Add support for two Motion-PRO board custom LEDs:
- motionpro-statusled
- motionpro-readyled
Signed-off-by: Jan Wrobel <wrr@semihalf.com>
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
---
Updated "static struct of_device_id mpled_match[]" definition
to "static const struct of_device_id mpled_match[]".
drivers/leds/Kconfig | 7 +
drivers/leds/Makefile | 3
drivers/leds/leds-motionpro.c | 250 +++++++++++++++++++++++++++++++++++++++++
include/asm-powerpc/mpc52xx.h | 5 +
4 files changed, 264 insertions(+), 1 deletions(-)
create mode 100644 drivers/leds/leds-motionpro.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ec568fa..1567ed6 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -55,6 +55,13 @@ config LEDS_TOSA
This option enables support for the LEDs on Sharp Zaurus
SL-6000 series.
+config LEDS_MOTIONPRO
+ tristate "Motion-PRO LEDs Support"
+ depends on LEDS_CLASS && PPC_MPC5200
+ help
+ This option enables support for status and ready LEDs connected
+ to GPIO lines on Motion-PRO board.
+
config LEDS_S3C24XX
tristate "LED Support for Samsung S3C24XX GPIO LEDs"
depends on LEDS_CLASS && ARCH_S3C2410
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index a60de1b..a56d399 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -18,7 +18,8 @@ obj-$(CONFIG_LEDS_H1940) += leds-h1940.o
obj-$(CONFIG_LEDS_COBALT_QUBE) += leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o
-obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_MOTIONPRO) += leds-motionpro.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
diff --git a/drivers/leds/leds-motionpro.c b/drivers/leds/leds-motionpro.c
new file mode 100644
index 0000000..cad7ccd
--- /dev/null
+++ b/drivers/leds/leds-motionpro.c
@@ -0,0 +1,250 @@
+/*
+ * LEDs driver for the Motion-PRO board.
+ *
+ * Copyright (C) 2007 Semihalf
+ * Jan Wrobel <wrr@semihalf.com>
+ * Marian Balakowicz <m8@semihalf.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc., 51
+ * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ *
+ * Decription:
+ * This driver enables control over Motion-PRO status and ready LEDs through
+ * sysfs. LEDs can be controlled by writing to sysfs files:
+ * class/leds/<led-name>/(brightness|delay_off|delay_on).
+ * See Documentation/leds-class.txt for more details.
+ * <led-name> is the set to the value of 'label' property of the
+ * corresponding GPT node.
+ *
+ * Before user issues first control command via sysfs, LED blinking is
+ * controlled by the kernel ('blink-delay' property of the GPT node
+ * in the device tree blob).
+ *
+ */
+
+#define DEBUG
+
+#include <linux/module.h>
+#include <linux/leds.h>
+#include <linux/of_platform.h>
+#include <asm/mpc52xx.h>
+
+/* LED control bits */
+#define LED_ON MPC52xx_GPT_OUTPUT_1
+
+/* LED mode */
+#define LED_MODE_KERNEL 1
+#define LED_MODE_USER 2
+
+struct motionpro_led {
+ spinlock_t led_lock; /* Protects the LED data */
+ struct mpc52xx_gpt __iomem *gpt;/* LED registers */
+ struct timer_list blink_timer; /* Used if blink_delay is nonzero */
+ unsigned int blink_delay; /* [ms], if set to 0 blinking is off */
+ unsigned int mode; /* kernel/user */
+ struct led_classdev mpled_cdev; /* LED class */
+};
+
+/*
+ * Timer event - blinks LED before user takes control over it
+ * with the first access via sysfs.
+ */
+static void mpled_timer_toggle(unsigned long data)
+{
+ struct motionpro_led *mpled = (struct motionpro_led *)data;
+
+ spin_lock_bh(&mpled->led_lock);
+ if (mpled->mode == LED_MODE_KERNEL) {
+ u32 val = in_be32(&mpled->gpt->mode);
+ val ^= LED_ON;
+ out_be32(&mpled->gpt->mode, val);
+
+ mod_timer(&mpled->blink_timer,
+ jiffies + msecs_to_jiffies(mpled->blink_delay));
+ }
+ spin_unlock_bh(&mpled->led_lock);
+}
+
+/*
+ * Turn on/off led according to user settings in sysfs.
+ * First call to this function disables kernel blinking.
+ */
+static void mpled_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct motionpro_led *mpled;
+ int old_mode;
+ u32 val;
+
+ mpled = container_of(led_cdev, struct motionpro_led, mpled_cdev);
+
+ spin_lock_bh(&mpled->led_lock);
+ /* disable kernel controll */
+ old_mode = mpled->mode;
+ if (old_mode == LED_MODE_KERNEL)
+ mpled->mode = LED_MODE_USER;
+
+ val = in_be32(&mpled->gpt->mode);
+ if (brightness)
+ val |= LED_ON;
+ else
+ val &= ~LED_ON;
+ out_be32(&mpled->gpt->mode, val);
+ spin_unlock_bh(&mpled->led_lock);
+
+ /* delete kernel mode blink timer, not needed anymore */
+ if ((old_mode == LED_MODE_KERNEL) && mpled->blink_delay)
+ del_timer(&mpled->blink_timer);
+}
+
+static void mpled_init_led(void __iomem *gpt_mode)
+{
+ u32 val = in_be32(gpt_mode);
+ val |= MPC52xx_GPT_ENABLE_OUTPUT;
+ val &= ~LED_ON;
+ out_be32(gpt_mode, val);
+}
+
+static int __devinit mpled_probe(struct of_device *op,
+ const struct of_device_id *match)
+{
+ struct motionpro_led *mpled;
+ const unsigned int *of_blink_delay;
+ const char *label;
+ int err;
+
+ dev_dbg(&op->dev, "mpled_probe: node=%s (op=%p, match=%p)\n",
+ op->node->name, op, match);
+
+ mpled = kzalloc(sizeof(*mpled), GFP_KERNEL);
+ if (!mpled)
+ return -ENOMEM;
+
+ mpled->gpt = of_iomap(op->node, 0);
+ if (!mpled->gpt) {
+ printk(KERN_ERR __FILE__ ": "
+ "Error mapping GPT registers for LED %s\n",
+ op->node->full_name);
+ err = -EIO;
+ goto err_free;
+ }
+
+ /* initialize GPT for LED use */
+ mpled_init_led(&mpled->gpt->mode);
+
+ spin_lock_init(&mpled->led_lock);
+ mpled->mode = LED_MODE_KERNEL;
+
+ /* get LED label, used to register led classdev */
+ label = of_get_property(op->node, "label", NULL);
+ if (label == NULL) {
+ printk(KERN_ERR __FILE__ ": "
+ "No label property provided for LED %s\n",
+ op->node->full_name);
+ err = -EINVAL;
+ goto err_free;
+ }
+ dev_dbg(&op->dev, "mpled_probe: label = '%s'\n", label);
+
+ /* get 'blink-delay' property if present */
+ of_blink_delay = of_get_property(op->node, "blink-delay", NULL);
+ mpled->blink_delay = of_blink_delay ? *of_blink_delay : 0;
+ dev_dbg(&op->dev, "mpled_probe: blink_delay = %d msec\n",
+ mpled->blink_delay);
+
+ /* initialize kernel blink_timer if blink_delay was provided */
+ if (mpled->blink_delay) {
+ init_timer(&mpled->blink_timer);
+ mpled->blink_timer.function = mpled_timer_toggle;
+ mpled->blink_timer.data = (unsigned long)mpled;
+
+ mod_timer(&mpled->blink_timer,
+ jiffies + msecs_to_jiffies(mpled->blink_delay));
+ }
+
+ /* register LED classdev */
+ mpled->mpled_cdev.name = label;
+ mpled->mpled_cdev.brightness_set = mpled_set;
+ mpled->mpled_cdev.default_trigger = "timer";
+
+ err = led_classdev_register(NULL, &mpled->mpled_cdev);
+ if (err) {
+ printk(KERN_ERR __FILE__ ": "
+ "Error registering class device for LED %s\n",
+ op->node->full_name);
+ goto err;
+ }
+
+ dev_set_drvdata(&op->dev, mpled);
+ return 0;
+
+err:
+ if (mpled->blink_delay)
+ del_timer(&mpled->blink_timer);
+ iounmap(mpled->gpt);
+err_free:
+ kfree(mpled);
+
+ return err;
+}
+
+static int mpled_remove(struct of_device *op)
+{
+ struct motionpro_led *mpled = dev_get_drvdata(&op->dev);
+
+ dev_dbg(&op->dev, "mpled_remove: (%p)\n", op);
+
+ if (mpled->blink_delay && (mpled->mode == LED_MODE_KERNEL))
+ del_timer(&mpled->blink_timer);
+
+ led_classdev_unregister(&mpled->mpled_cdev);
+
+ iounmap(mpled->gpt);
+ kfree(mpled);
+
+ return 0;
+}
+
+static const struct of_device_id mpled_match[] = {
+ { .compatible = "promess,motionpro-led", },
+ {},
+};
+
+static struct of_platform_driver mpled_driver = {
+ .match_table = mpled_match,
+ .probe = mpled_probe,
+ .remove = mpled_remove,
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = "leds-motionpro",
+ },
+};
+
+static int __init mpled_init(void)
+{
+ return of_register_platform_driver(&mpled_driver);
+}
+
+static void __exit mpled_exit(void)
+{
+ of_unregister_platform_driver(&mpled_driver);
+}
+
+module_init(mpled_init);
+module_exit(mpled_exit);
+
+MODULE_LICENSE("GPL")
+MODULE_DESCRIPTION("Motion-PRO LED driver");
+MODULE_AUTHOR("Jan Wrobel <wrr@semihalf.com>");
+MODULE_AUTHOR("Marian Balakowicz <m8@semihalf.com>");
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index 1c48c6d..de869ee 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -147,6 +147,11 @@ struct mpc52xx_gpio {
#define MPC52xx_GPIO_PSC_CONFIG_UART_WITH_CD 5
#define MPC52xx_GPIO_PCI_DIS (1<<15)
+/* Enables GPT register to operate as simple GPIO output register */
+#define MPC52xx_GPT_ENABLE_OUTPUT 0x00000024
+/* Puts 1 on GPT output pin */
+#define MPC52xx_GPT_OUTPUT_1 0x00000010
+
/* GPIO with WakeUp*/
struct mpc52xx_gpio_wkup {
u8 wkup_gpioe; /* GPIO_WKUP + 0x00 */
^ permalink raw reply related
* Re: crash in kmem_cache_init
From: Olaf Hering @ 2008-01-23 12:14 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: <20080123105044.GD21455@csn.ul.ie>
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.
boot: x
Please wait, loading kernel...
Allocated 00a00000 bytes for kernel @ 00200000
Elf64 kernel loaded...
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: debug xmon=on panic=1 loglevel=8
memory layout at init:
alloc_bottom : 0000000000ac1000
alloc_top : 0000000010000000
alloc_top_hi : 00000000da000000
rmo_top : 0000000010000000
ram_top : 00000000da000000
Looking for displays
found display : /pci@800000020000002/pci@2/pci@1/display@0, opening ... done
instantiating rtas at 0x000000000f6a1000 ... done
0000000000000000 : boot cpu 0000000000000000
0000000000000002 : starting cpu hw idx 0000000000000002... done
0000000000000004 : starting cpu hw idx 0000000000000004... done
0000000000000006 : starting cpu hw idx 0000000000000006... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000000cc2000 -> 0x0000000000cc34e4
Device tree struct 0x0000000000cc4000 -> 0x0000000000cd6000
Calling quiesce ...
returning from prom_init
Partition configured for 8 cpus.
Starting Linux PPC64 #52 SMP Wed Jan 23 13:05:38 CET 2008
-----------------------------------------------------
ppc64_pft_size = 0x1c
physicalMemorySize = 0xda000000
htab_hash_mask = 0x1fffff
-----------------------------------------------------
Linux version 2.6.24-rc8-ppc64 (olaf@lingonberry) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #52 SMP Wed Jan 23 13:05:38 CET 2008
[boot]0012 Setup Arch
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 8192 bytes
Zone PFN ranges:
DMA 0 -> 892928
Normal 892928 -> 892928
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
1: 0 -> 892928
Could not find start_pfn for node 0
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on. Total pages: 880720
Policy zone: DMA
Kernel command line: debug xmon=on panic=1 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 = 275.070000 MHz
time_init: processor frequency = 2197.800000 MHz
clocksource: timebase mult[e8ab05] shift[22] registered
clockevent: decrementer mult[466a] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg-1] -> 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 1
Memory: 3496632k/3571712k available (6188k kernel code, 75080k reserved, 1324k data, 1220k bss, 304k init)
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
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 0
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 1
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 2
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 3
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 4
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 5
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 6
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 7
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 8
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 9
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 10
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 11
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 12
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 13
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 14
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 15
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 16
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 17
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 18
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 19
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 20
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 21
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 22
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 23
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 24
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 25
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 26
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 27
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 28
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 29
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 30
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 31
o kmem_list3_init
kmem_cache_init Setting kmem_cache NULL 32
kmem_cache_init Setting kmem_cache NULL 0
kmem_cache_init Setting kmem_cache initkmem_list3 0
set_up_list3s size-32 index 1
set_up_list3s size-32 index 1
set_up_list3s size-32 index 1
set_up_list3s size-128 index 17
set_up_list3s size-128 index 17
set_up_list3s size-128 index 17
setup_cpu_cache size-32(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-64
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-64(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-128(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-256
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-256(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-512
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-512(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-1024
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-1024(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-2048
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-2048(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-4096
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-4096(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-8192
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-8192(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-16384
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-16384(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-32768
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-32768(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-65536
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-65536(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-131072
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-131072(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-262144
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-262144(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-524288
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-524288(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-1048576
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-1048576(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-2097152
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-2097152(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-4194304
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-4194304(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-8388608
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-8388608(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-16777216
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
setup_cpu_cache size-16777216(DMA)
o allocated node 0
o kmem_list3_init
o allocated node 1
o kmem_list3_init
init_list RESETTING kmem_cache node 0
init_list RESETTING size-32 node 0
init_list RESETTING size-128 node 0
init_list RESETTING size-32 node 1
init_list RESETTING size-128 node 1
alloc_kmemlist size-16777216(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-16777216
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-8388608(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-8388608
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-4194304(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-4194304
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-2097152(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-2097152
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-1048576(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-1048576
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-524288(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-524288
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-262144(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-262144
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-131072(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-131072
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-65536(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-65536
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-32768(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-32768
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-16384(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-16384
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-8192(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-8192
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-4096(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-4096
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-2048(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-2048
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-1024(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-1024
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-512(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-512
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-256(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-256
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-128(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-64(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-64
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-32(DMA)
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-128
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist size-32
o node 0
o l3 exists
o node 1
o l3 exists
alloc_kmemlist kmem_cache
o node 0
o l3 exists
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D802FA00
alloc_kmemlist numa_policy
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D802FC00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D802FD80
alloc_kmemlist shared_policy_node
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D802FF00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D803E180
Calibrating delay loop... 548.86 BogoMIPS (lpj=2744320)
alloc_kmemlist pid_1
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D803E300
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D803E480
alloc_kmemlist pid_namespace
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D803E600
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D803E780
alloc_kmemlist pgd_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D803E900
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D803EA80
alloc_kmemlist pud_pmd_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D803EC00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D803ED80
alloc_kmemlist anon_vma
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D803EF00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D804C180
alloc_kmemlist task_struct
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D804C300
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D804C480
alloc_kmemlist sighand_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D804C600
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D804C780
alloc_kmemlist signal_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D804C900
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D804CA80
alloc_kmemlist files_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D804CC00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D804CD80
alloc_kmemlist fs_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D804CF00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8057180
alloc_kmemlist vm_area_struct
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8057300
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8057480
alloc_kmemlist mm_struct
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8057600
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8057780
alloc_kmemlist buffer_head
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8057900
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8057A80
alloc_kmemlist idr_layer_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8057C80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8057E00
alloc_kmemlist key_jar
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8057F80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8066200
Security Framework initialized
Capability LSM initialized
Failure registering Root Plug module with the kernel
Failure registering Root Plug module with primary security module.
alloc_kmemlist names_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8066380
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8066500
alloc_kmemlist filp
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8066680
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8066800
alloc_kmemlist dentry
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8066980
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8066B00
alloc_kmemlist inode_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8066C80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8066E00
alloc_kmemlist mnt_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8066F80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8074200
Mount-cache hash table entries: 256
alloc_kmemlist sysfs_dir_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8074380
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8074500
alloc_kmemlist bdev_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8074700
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8074880
alloc_kmemlist radix_tree_node
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8074A00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8074B80
alloc_kmemlist sigqueue
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8074D00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8074E80
alloc_kmemlist proc_inode_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D808E100
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D808E280
alloc_kmemlist taskstats
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D808E400
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D808E580
alloc_kmemlist task_delay_info
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D808E700
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D808E880
cpuup_prepare 1
clockevent: decrementer mult[466a] shift[16] cpu[1]
Processor 1 found.
cpuup_prepare 2
clockevent: decrementer mult[466a] shift[16] cpu[2]
Processor 2 found.
cpuup_prepare 3
clockevent: decrementer mult[466a] shift[16] cpu[3]
Processor 3 found.
cpuup_prepare 4
clockevent: decrementer mult[466a] shift[16] cpu[4]
Processor 4 found.
cpuup_prepare 5
clockevent: decrementer mult[466a] shift[16] cpu[5]
Processor 5 found.
cpuup_prepare 6
clockevent: decrementer mult[466a] shift[16] cpu[6]
Processor 6 found.
cpuup_prepare 7
clockevent: decrementer mult[466a] shift[16] cpu[7]
Processor 7 found.
Brought up 8 CPUs
Node 0 CPUs: 0-3
Node 1 CPUs: 4-7
net_namespace: 120 bytes
alloc_kmemlist file_lock_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D82C6680
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D82C6800
alloc_kmemlist skbuff_head_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D82C6980
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D82C6B00
alloc_kmemlist skbuff_fclone_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D82C6D00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D82C6E80
alloc_kmemlist sock_inode_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8372180
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8372300
NET: Registered protocol family 16
IBM eBus Device Driver
PCI: Probing PCI hardware
IOMMU table initialized, virtual merging enabled
PCI: Probing PCI hardware done
Registering pmac pic with sysfs...
alloc_kmemlist bio
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D83E9580
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D83E9700
alloc_kmemlist biovec-1
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D83E9880
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D83E9A00
alloc_kmemlist biovec-4
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D83E9B80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D83E9D00
alloc_kmemlist biovec-16
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D83E9E80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D83F4100
alloc_kmemlist biovec-64
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D83F4300
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D83F4480
alloc_kmemlist biovec-128
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D83F4600
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D83F4780
alloc_kmemlist biovec-256
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D83F4900
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D83F4A80
alloc_kmemlist blkdev_requests
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8401580
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8401700
alloc_kmemlist blkdev_queue
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8401880
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8401A00
alloc_kmemlist blkdev_ioc
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8401B80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8401D00
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
alloc_kmemlist eventpoll_epi
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8439A80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8439C00
alloc_kmemlist eventpoll_pwq
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8439D80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8439F00
alloc_kmemlist TCP
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8486380
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8486500
alloc_kmemlist request_sock_TCP
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8486680
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8486800
alloc_kmemlist tw_sock_TCP
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8486980
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8486B00
alloc_kmemlist UDP
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8486D00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D8486E80
alloc_kmemlist RAW
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D849D180
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D849D300
NET: Registered protocol family 2
Time: timebase clocksource has been installed.
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
Switched to high resolution mode on CPU 2
Switched to high resolution mode on CPU 3
Switched to high resolution mode on CPU 4
Switched to high resolution mode on CPU 5
Switched to high resolution mode on CPU 6
Switched to high resolution mode on CPU 7
alloc_kmemlist arp_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D849D480
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D849D600
alloc_kmemlist ip_dst_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D849DC80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D849DE00
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
alloc_kmemlist xfrm_dst_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D84A8300
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D84A8480
alloc_kmemlist secpath_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D84A8600
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D84A8780
alloc_kmemlist inet_peer_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D84A8900
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D84A8A80
alloc_kmemlist tcp_bind_bucket
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D84A8C00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D84A8D80
TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 524288 bind 65536)
TCP reno registered
alloc_kmemlist UDP-Lite
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D84A8F80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D84C6200
alloc_kmemlist ip_mrt_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D84C6380
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D84C6500
alloc_kmemlist rtas_flash_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D8294880
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D84E5F80
alloc_kmemlist hugepte_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D84EA800
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D84EA680
alloc_kmemlist uid_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D84EA400
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D84EA280
alloc_kmemlist posix_timers_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D84EA100
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D84EAF00
alloc_kmemlist nsproxy
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D85BB180
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D85BB300
audit: initializing netlink socket (disabled)
audit(1201090162.460:1): initialized
RTAS daemon started
RTAS: event: 88, Type: Platform Error, Severity: 2
Total HugeTLB memory allocated, 0
alloc_kmemlist shmem_inode_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D85BB680
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D85BB800
alloc_kmemlist fasync_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D85BBA00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D85BBB80
alloc_kmemlist kiocb
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D85BBD00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D85BBE80
alloc_kmemlist kioctx
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D85EF180
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D85EF300
alloc_kmemlist inotify_watch_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D85EF880
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D85EFA00
alloc_kmemlist inotify_event_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D85EFB80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D85EFD00
VFS: Disk quotas dquot_6.5.1
alloc_kmemlist dquot
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D85EFE80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D85FD100
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
alloc_kmemlist dnotify_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D85FD280
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D85FD400
alloc_kmemlist reiser_inode_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D85FD600
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D85FD780
alloc_kmemlist ext3_xattr
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D85FD980
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D85FDB00
alloc_kmemlist ext3_inode_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D85FDD00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D85FDE80
alloc_kmemlist revoke_record
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6036100
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6036280
alloc_kmemlist revoke_table
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6036400
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6036580
alloc_kmemlist journal_head
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6036700
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6036880
alloc_kmemlist journal_handle
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6036A00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6036B80
alloc_kmemlist ext2_xattr
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6036D80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6036F00
alloc_kmemlist ext2_inode_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6046200
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6046380
alloc_kmemlist hugetlbfs_inode_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6046580
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6046700
alloc_kmemlist fat_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6046900
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6046A80
alloc_kmemlist fat_inode_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6046C80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6046E00
alloc_kmemlist isofs_inode_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6052100
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6052280
alloc_kmemlist mqueue_inode_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6052500
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6052680
alloc_kmemlist bsg_cmd
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6052880
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6052A00
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
alloc_kmemlist cfq_queue
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6052C00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6052D80
alloc_kmemlist cfq_io_context
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D6052F00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D6070180
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
rpaphp: Slot [0001:00:02.0](PCI location=U7879.001.DQD04M6-P1-C3) registered
rpaphp: Slot [0001:00:02.2](PCI location=U7879.001.DQD04M6-P1-C4) registered
rpaphp: Slot [0001:00:02.4](PCI location=U7879.001.DQD04M6-P1-C5) registered
rpaphp: Slot [0001:00:02.6](PCI location=U7879.001.DQD04M6-P1-C6) registered
rpaphp: Slot [0002:00:02.0](PCI location=U7879.001.DQD04M6-P1-C1) registered
rpaphp: Slot [0002:00:02.6](PCI location=U7879.001.DQD04M6-P1-C2) registered
matroxfb: Matrox G450 detected
PInS data found at offset 31168
PInS memtype = 5
matroxfb: 640x480x8bpp (virtual: 640x26214)
matroxfb: framebuffer at 0x40178000000, mapped to 0xd000080080080000, size 33554432
Console: switching to colour frame buffer device 80x30
fb0: MATROX frame buffer device
matroxfb_crtc2: secondary head of fb0 was registered as fb1
vio_register_driver: driver hvc_console registering
HVSI: registered 0 devices
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
input: Macintosh mouse button emulation as /devices/virtual/input/input0
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ehci_hcd 0000:c8:01.2: EHCI Host Controller
ehci_hcd 0000:c8:01.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:c8:01.2: irq 85, io mem 0x400a0002000
ehci_hcd 0000:c8:01.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 5 ports detected
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:c8:01.0: OHCI Host Controller
ohci_hcd 0000:c8:01.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:c8:01.0: irq 85, io mem 0x400a0001000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ohci_hcd 0000:c8:01.1: OHCI Host Controller
ohci_hcd 0000:c8:01.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:c8:01.1: irq 85, io mem 0x400a0000000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
mice: PS/2 mouse device common for all mice
EDAC MC: Ver: 2.1.0 Jan 23 2008
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
/home/olaf/kernel/git/linux-2.6.24-rc8/drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
oprofile: using ppc64/power5+ performance monitoring.
alloc_kmemlist flow_cache
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D612FA80
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D612FC00
alloc_kmemlist UNIX
o node 0
o allocing l3
o kmem_list3_init
o setting node 0 0xC0000000D612FE00
o node 1
o allocing l3
o kmem_list3_init
o setting node 1 0xC0000000D612FF80
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
registered taskstats version 1
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
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..
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Michel Dänzer @ 2008-01-23 12:18 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar; +Cc: linuxppc-dev
In-Reply-To: <1201013786.4726.28.camel@thor.sulgenrain.local>
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);
}
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply related
* Re: [PATCH] ppc: fix #ifdef-s in mediabay driver
From: Bartlomiej Zolnierkiewicz @ 2008-01-23 12:47 UTC (permalink / raw)
To: benh; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <1201061832.6807.64.camel@pasglop>
On Wednesday 23 January 2008, Benjamin Herrenschmidt wrote:
>
> On Wed, 2008-01-23 at 01:58 +0100, Bartlomiej Zolnierkiewicz wrote:
> > I'm more worried about breaking automatic build checking (make randconfig)
> > than a few extra bytes so if you remove all #ifdefs you'll have to either
> > make BLK_DEV_IDE_PMAC select PMAC_MEDIABAY or make PMAC_MEDIABAY depend
> > on BLK_DEV_IDE_PMAC (otherwise BLK_DEV_IDE=n && PMAC_MEDIABAY=y will fail
> > since mediabay.c is referencing IDE code).
>
> I was thinking about having the pmac arch code provide an exported
> function pointer to put the hook in to avoid that problem.
BTW the other pending IDE patches (yet to posted) include rework of IDE
hot-plug support for PMAC media-bay so ide_init_hwif_ports()/ide_register_hw()
/ide_unregister() calls in mediabay.c will be replaced by "something else".
^ permalink raw reply
* 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
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