* Re: crash in kmem_cache_init
From: Mel Gorman @ 2008-01-22 22:50 UTC (permalink / raw)
To: Christoph Lameter
Cc: lee.schermerhorn, Olaf Hering, Linux MM, linux-kernel,
linuxppc-dev, Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan,
akpm, KAMEZAWA Hiroyuki
In-Reply-To: <Pine.LNX.4.64.0801221330390.1652@schroedinger.engr.sgi.com>
[-- Attachment #1: Type: text/plain, Size: 8266 bytes --]
On (22/01/08 13:34), Christoph Lameter didst pronounce:
> On Tue, 22 Jan 2008, Mel Gorman wrote:
>
> > > After you reverted the slab memoryless node patch there should be per node
> > > structures created for node 0 unless the node is marked offline. Is it? If
> > > so then you are booting a cpu that is associated with an offline node.
> > >
> >
> > I'll roll a patch that prints out the online states before startup and
> > see what it looks like.
>
> Ok. Great.
>
The dmesg output is below.
> >
> > > > Can you see a better solution than this?
> > >
> > > Well this means that bootstrap will work by introducing foreign objects
> > > into the per cpu queue (should only hold per cpu objects). They will
> > > later be consumed and then the queues will contain the right objects so
> > > the effect of the patch is minimal.
> > >
> >
> > By minimal, do you mean that you expect it to break in some other
> > respect later or minimal as in "this is bad but should not have no
> > adverse impact".
>
> Should not have any adverse impact after the objects from the cpu queue
> have been consumed. If the cache_reaper tries to shift objects back
> from the per cpu queue into slabs then BUG_ONs may be triggered. Make sure
> you run the tests with full debugging please.
>
I am not running a full range of tests at the moment. Just getting boot
first. I'll queue up a range of tests to run with DEBUG on now but it'll
be the morning before I have the results.
> > Whatever this was a problem fixed in the past or not, it's broken again now
> > :( . It's possible that there is a __GFP_THISNODE that can be dropped early
> > at boot-time that would also fix this problem in a way that doesn't
> > affect runtime (like altering cache_grow in my patch does).
>
> The dropping of GFP_THISNODE has the same effect as your patch.
The dropping of it totally? If so, this patch might fix a boot but it'll
potentially be a performance regression on NUMA machines that only have
nodes with memory, right?
> Objects from another node get into the per cpu queue. And on free we
> assume that per cpu queue objects are from the local node. If debug is on
> then we check that with BUG_ONs.
>
The interesting parts of the dmesg output are
Online nodes
o 0
o 2
Nodes with regular memory
o 2
Current running CPU 0 is associated with node 0
Current node is 0
So node 2 has regular memory but it's trying to use node 0 at a glance.
I've attached the patch I used against 2.6.24-rc8. It includes the revert.
Here is the full output
Please wait, loading kernel...
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded at 02400000, size: 1192 Kbytes
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: ro console=hvc0 autobench_args: root=/dev/sda6 ABAT:1201041303 loglevel=8
memory layout at init:
alloc_bottom : 000000000252a000
alloc_top : 0000000008000000
alloc_top_hi : 0000000100000000
rmo_top : 0000000008000000
ram_top : 0000000100000000
Looking for displays
instantiating rtas at 0x00000000077d9000 ... done
0000000000000000 : boot cpu 0000000000000000
0000000000000002 : starting cpu hw idx 0000000000000002... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x000000000262b000 -> 0x000000000262c1d3
Device tree struct 0x000000000262d000 -> 0x0000000002635000
Calling quiesce ...
returning from prom_init
Partition configured for 4 cpus.
Starting Linux PPC64 #1 SMP Tue Jan 22 17:15:48 EST 2008
-----------------------------------------------------
ppc64_pft_size = 0x1a
physicalMemorySize = 0x100000000
htab_hash_mask = 0x7ffff
-----------------------------------------------------
Linux version 2.6.24-rc8-autokern1 (root@gekko-lp3.ltc.austin.ibm.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)) #1 SMP Tue Jan 22 17:15:48 EST 2008
[boot]0012 Setup Arch
EEH: PCI Enhanced I/O Error Handling Enabled
PPC64 nvram contains 7168 bytes
Zone PFN ranges:
DMA 0 -> 1048576
Normal 1048576 -> 1048576
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
2: 0 -> 1048576
Could not find start_pfn for node 0
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on. Total pages: 1034240
Policy zone: DMA
Kernel command line: ro console=hvc0 autobench_args: root=/dev/sda6 ABAT:1201041303 loglevel=8
[boot]0020 XICS Init
xics: no ISA interrupt controller
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 238.059000 MHz
time_init: processor frequency = 1904.472000 MHz
clocksource: timebase mult[10cd746] shift[22] registered
clockevent: decrementer mult[3cf1] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [hvc0]
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
freeing bootmem node 2
Memory: 4105560k/4194304k available (5004k kernel code, 88744k reserved, 876k data, 559k bss, 272k init)
Online nodes
o 0
o 2
Nodes with regular memory
o 2
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 initkmem_list3 0
Unable to handle kernel paging request for data at address 0x00000040
Faulting instruction address: 0xc0000000003c8c00
cpu 0x0: Vector: 300 (Data Access) at [c0000000005c3840]
pc: c0000000003c8c00: __lock_text_start+0x20/0x88
lr: c0000000000dadec: .cache_grow+0x7c/0x338
sp: c0000000005c3ac0
msr: 8000000000009032
dar: 40
dsisr: 40000000
current = 0xc000000000500f10
paca = 0xc000000000501b80
pid = 0, comm = swapper
enter ? for help
[c0000000005c3b40] c0000000000dadec .cache_grow+0x7c/0x338
[c0000000005c3c00] c0000000000db54c .fallback_alloc+0x1c0/0x224
[c0000000005c3cb0] c0000000000db958 .kmem_cache_alloc+0xe0/0x14c
[c0000000005c3d50] c0000000000dcccc .kmem_cache_create+0x230/0x4cc
[c0000000005c3e30] c0000000004c05f4 .kmem_cache_init+0x310/0x640
[c0000000005c3ee0] c00000000049f8d8 .start_kernel+0x304/0x3fc
[c0000000005c3f90] c000000000008594 .start_here_common+0x54/0xc0
0:mon>
[-- Attachment #2: debug-slab-with-revert.diff --]
[-- Type: text/x-diff, Size: 5708 bytes --]
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc8-clean/mm/slab.c linux-2.6.24-rc8-005-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-005-debug-slab/mm/slab.c 2008-01-22 21:36:50.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]);
}
}
@@ -3815,8 +3840,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 +3864,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 +3884,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 +3901,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 +3917,7 @@ fail:
free_alien_cache(l3->alien);
kfree(l3);
cachep->nodelists[node] = NULL;
+ printk(" o setting node %d FAIL NULL\n", node);
}
node--;
}
^ permalink raw reply
* Re: [PATCH 1/3 v3] Add StorCenter DTS first draft.
From: Jon Loeliger @ 2008-01-22 22:54 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <fa686aa40801221449p28889ea5r68bd726726558dc0@mail.gmail.com>
Grant Likely wrote:
> On 1/22/08, Jon Loeliger <jdl@jdl.com> wrote:
>> Based on the Kurobox DTS files.
>>
>> Signed-off-by: Andy Wilcox <andy@protium.com>
>> Signed-off-by: Jon Loeliger <jdl@jdl.com>
>
> Comments below
>
>> +
>> +/ {
>> + model = "StorCenter";
>> + compatible = "storcenter";
>
> Be specific! "iomega,storcenter". Even better if you put in the model number.
As I mentioned vefore, there is no further model number.
That _is_ the model name.
>> +
>> + soc@fc000000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + device_type = "soc";
>
> device_type should be dropped (but I know that requires changes to the
> existing mpc82xx support code).
And when the code is fixed, we can fix the DTS too... :-)
>> + compatible = "fsl,mpc8241", "mpc10x";
>
> fsl,mpc8241-immr would be better; this node describes the internally
> memory mapped registers; not the entire soc.
Uh, whatever? :-) 'Cuz how many other DTS files say that?
>> +
>> + mpic: interrupt-controller@40000 {
>> + #interrupt-cells = <2>;
>> + #address-cells = <0>;
>
> Is #address-cells needed? There are no child nodes.
I thought so. Could be wrong.
>> + chosen {
>> + linux,stdout-path = "/soc/serial@4500";
>
> /soc@fc000000/ perhaps?
Not really necessary to specify the unit number.
jdl
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Christoph Lameter @ 2008-01-22 22:57 UTC (permalink / raw)
To: Mel Gorman
Cc: lee.schermerhorn, Olaf Hering, Linux MM, linux-kernel,
linuxppc-dev, Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan,
akpm, KAMEZAWA Hiroyuki
In-Reply-To: <20080122225046.GA866@csn.ul.ie>
On Tue, 22 Jan 2008, Mel Gorman wrote:
> > > Whatever this was a problem fixed in the past or not, it's broken again now
> > > :( . It's possible that there is a __GFP_THISNODE that can be dropped early
> > > at boot-time that would also fix this problem in a way that doesn't
> > > affect runtime (like altering cache_grow in my patch does).
> >
> > The dropping of GFP_THISNODE has the same effect as your patch.
>
> The dropping of it totally? If so, this patch might fix a boot but it'll
> potentially be a performance regression on NUMA machines that only have
> nodes with memory, right?
No the dropping during early allocations.,
> o 0
> o 2
> Nodes with regular memory
> o 2
> Current running CPU 0 is associated with node 0
> Current node is 0
>
> So node 2 has regular memory but it's trying to use node 0 at a glance.
> I've attached the patch I used against 2.6.24-rc8. It includes the revert.
We need the current processor to be attached to a node that has
memory. We cannot fall back that early because the structures for the
other nodes do not exist yet.
> Online nodes
> o 0
> o 2
> Nodes with regular memory
> o 2
> Current running CPU 0 is associated with node 0
> Current node is 0
> o kmem_list3_init
This needs to be node 2.
> [c0000000005c3b40] c0000000000dadec .cache_grow+0x7c/0x338
> [c0000000005c3c00] c0000000000db54c .fallback_alloc+0x1c0/0x224
Fallback during bootstrap.
^ permalink raw reply
* [PATCH] ppc: fix #ifdef-s in mediabay driver
From: Bartlomiej Zolnierkiewicz @ 2008-01-22 23:12 UTC (permalink / raw)
To: linux-ide; +Cc: linuxppc-dev, linux-kernel
* Replace incorrect CONFIG_BLK_DEV_IDE #ifdef in
check_media_bay() by CONFIG_MAC_FLOPPY one.
* Replace incorrect CONFIG_BLK_DEV_IDE #ifdef-s by
CONFIG_BLK_DEV_IDE_PMAC ones.
* check_media_bay() is used only by drivers/block/swim3.c
so make this function available only if CONFIG_MAC_FLOPPY
is defined.
* check_media_bay_by_base() and media_bay_set_ide_infos()
are used only by drivers/ide/ppc/pmac.c so so make these
functions available only if CONFIG_MAC_FLOPPY is defined.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
Ben, IMO this patch is safe for 2.6.24 (assuming that it builds fine :),
otherwise I would like to ask for permission to merge it through IDE
tree since I have other pending IDE patches depending on this one.
drivers/macintosh/mediabay.c | 46 ++++++++++++++++++-----------------------
include/asm-powerpc/mediabay.h | 13 ++++++++---
2 files changed, 30 insertions(+), 29 deletions(-)
Index: b/drivers/macintosh/mediabay.c
===================================================================
--- a/drivers/macintosh/mediabay.c
+++ b/drivers/macintosh/mediabay.c
@@ -78,12 +78,14 @@ struct media_bay_info {
int cached_gpio;
int sleeping;
struct semaphore lock;
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
void __iomem *cd_base;
- int cd_index;
int cd_irq;
int cd_retry;
#endif
+#if defined(CONFIG_BLK_DEV_IDE_PMAC) || defined(CONFIG_MAC_FLOPPY)
+ int cd_index;
+#endif
};
#define MAX_BAYS 2
@@ -91,7 +93,7 @@ struct media_bay_info {
static struct media_bay_info media_bays[MAX_BAYS];
int media_bay_count = 0;
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
/* check the busy bit in the media-bay ide interface
(assumes the media-bay contains an ide device) */
#define MB_IDE_READY(i) ((readb(media_bays[i].cd_base + 0x70) & 0x80) == 0)
@@ -401,7 +403,7 @@ static void poll_media_bay(struct media_
set_mb_power(bay, id != MB_NO);
bay->content_id = id;
if (id == MB_NO) {
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
bay->cd_retry = 0;
#endif
printk(KERN_INFO "media bay %d is empty\n", bay->index);
@@ -414,9 +416,9 @@ static void poll_media_bay(struct media_
}
}
+#ifdef CONFIG_MAC_FLOPPY
int check_media_bay(struct device_node *which_bay, int what)
{
-#ifdef CONFIG_BLK_DEV_IDE
int i;
for (i=0; i<media_bay_count; i++)
@@ -426,14 +428,14 @@ int check_media_bay(struct device_node *
media_bays[i].cd_index = -1;
return -EINVAL;
}
-#endif /* CONFIG_BLK_DEV_IDE */
return -ENODEV;
}
EXPORT_SYMBOL(check_media_bay);
+#endif /* CONFIG_MAC_FLOPPY */
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
int check_media_bay_by_base(unsigned long base, int what)
{
-#ifdef CONFIG_BLK_DEV_IDE
int i;
for (i=0; i<media_bay_count; i++)
@@ -443,15 +445,13 @@ int check_media_bay_by_base(unsigned lon
media_bays[i].cd_index = -1;
return -EINVAL;
}
-#endif
-
+
return -ENODEV;
}
int media_bay_set_ide_infos(struct device_node* which_bay, unsigned long base,
- int irq, int index)
+ int irq, int index)
{
-#ifdef CONFIG_BLK_DEV_IDE
int i;
for (i=0; i<media_bay_count; i++) {
@@ -483,10 +483,10 @@ int media_bay_set_ide_infos(struct devic
return -ENODEV;
}
}
-#endif /* CONFIG_BLK_DEV_IDE */
-
+
return -ENODEV;
}
+#endif /* CONFIG_BLK_DEV_IDE_PMAC */
static void media_bay_step(int i)
{
@@ -521,14 +521,13 @@ static void media_bay_step(int i)
bay->state = mb_resetting;
MBDBG("mediabay%d: waiting reset (kind:%d)\n", i, bay->content_id);
break;
-
case mb_resetting:
if (bay->content_id != MB_CD) {
MBDBG("mediabay%d: bay is up (kind:%d)\n", i, bay->content_id);
bay->state = mb_up;
break;
}
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
MBDBG("mediabay%d: waiting IDE reset (kind:%d)\n", i, bay->content_id);
bay->ops->un_reset_ide(bay);
bay->timer = msecs_to_jiffies(MB_IDE_WAIT);
@@ -536,16 +535,14 @@ static void media_bay_step(int i)
#else
printk(KERN_DEBUG "media-bay %d is ide (not compiled in kernel)\n", i);
set_mb_power(bay, 0);
-#endif /* CONFIG_BLK_DEV_IDE */
+#endif /* CONFIG_BLK_DEV_IDE_PMAC */
break;
-
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
case mb_ide_resetting:
bay->timer = msecs_to_jiffies(MB_IDE_TIMEOUT);
bay->state = mb_ide_waiting;
MBDBG("mediabay%d: waiting IDE ready (kind:%d)\n", i, bay->content_id);
break;
-
case mb_ide_waiting:
if (bay->cd_base == NULL) {
bay->timer = 0;
@@ -587,11 +584,10 @@ static void media_bay_step(int i)
bay->timer = 0;
}
break;
-#endif /* CONFIG_BLK_DEV_IDE */
-
+#endif /* CONFIG_BLK_DEV_IDE_PMAC */
case mb_powering_down:
bay->state = mb_empty;
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
if (bay->cd_index >= 0) {
printk(KERN_DEBUG "Unregistering mb %d ide, index:%d\n", i,
bay->cd_index);
@@ -607,7 +603,7 @@ static void media_bay_step(int i)
bay->content_id = MB_NO;
}
}
-#endif /* CONFIG_BLK_DEV_IDE */
+#endif /* CONFIG_BLK_DEV_IDE_PMAC */
MBDBG("mediabay%d: end of power down\n", i);
break;
}
@@ -745,7 +741,7 @@ static int media_bay_resume(struct macio
bay->last_value = bay->content_id;
bay->value_count = msecs_to_jiffies(MB_STABLE_DELAY);
bay->timer = msecs_to_jiffies(MB_POWER_DELAY);
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
bay->cd_retry = 0;
#endif
do {
@@ -835,7 +831,7 @@ static int __init media_bay_init(void)
for (i=0; i<MAX_BAYS; i++) {
memset((char *)&media_bays[i], 0, sizeof(struct media_bay_info));
media_bays[i].content_id = -1;
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
media_bays[i].cd_index = -1;
#endif
}
Index: b/include/asm-powerpc/mediabay.h
===================================================================
--- a/include/asm-powerpc/mediabay.h
+++ b/include/asm-powerpc/mediabay.h
@@ -17,15 +17,20 @@
#define MB_POWER 6 /* media bay contains a Power device (???) */
#define MB_NO 7 /* media bay contains nothing */
+#idef CONFIG_MAC_FLOPPY
int check_media_bay(struct device_node *which_bay, int what);
-int check_media_bay_by_base(unsigned long base, int what);
+#endif
+
/* Number of bays in the machine or 0 */
extern int media_bay_count;
-/* called by pmac-ide.c to register IDE controller for media bay */
-extern int media_bay_set_ide_infos(struct device_node* which_bay,
- unsigned long base, int irq, int index);
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
+int check_media_bay_by_base(unsigned long base, int what);
+/* called by IDE PMAC host driver to register IDE controller for media bay */
+int media_bay_set_ide_infos(struct device_node *which_bay, unsigned long base,
+ int irq, int index);
+#endif
#endif /* __KERNEL__ */
#endif /* _PPC_MEDIABAY_H */
^ permalink raw reply
* Re: [PATCH v3] create modalias file in sysfs for bus of_platform
From: Stephen Rothwell @ 2008-01-22 23:03 UTC (permalink / raw)
To: Olaf Hering; +Cc: sparclinux, linuxppc-dev
In-Reply-To: <20080122190939.GA14124@aepfle.de>
[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]
[Adding sparclinux cc]
I withdraw the comment about drivers/macintosh/macio_sysfs.c, I didn't
realise that it was a whole other bus.
On Tue, 22 Jan 2008 20:09:39 +0100 Olaf Hering <olaf@aepfle.de> wrote:
>
> Create /sys/bus/of_platform/devices/*/modalias file to allow autoloading
> of modules. modalias files are already present for many other bus types.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> ---
> drivers/of/device.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -86,7 +86,20 @@ static ssize_t dev_show_devspec(struct d
> return sprintf(buf, "%s", ofdev->node->full_name);
> }
>
> +static ssize_t dev_show_modalias(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct of_device *ofdev = to_of_device(dev);
> + ssize_t len = 0;
> +
> + len = of_device_get_modalias(ofdev, buf, PAGE_SIZE - 2);
> + buf[len] = '\n';
> + buf[len+1] = 0;
> + return len+1;
> +}
> +
> static DEVICE_ATTR(devspec, S_IRUGO, dev_show_devspec, NULL);
> +static DEVICE_ATTR(modalias, S_IRUGO, dev_show_modalias, NULL);
>
> /**
> * of_release_dev - free an of device structure when all users of it are finished.
> @@ -116,6 +129,11 @@ int of_device_register(struct of_device
> return rc;
>
> rc = device_create_file(&ofdev->dev, &dev_attr_devspec);
> + if (rc) {
> + device_unregister(&ofdev->dev);
> + return rc;
> + }
> + rc = device_create_file(&ofdev->dev, &dev_attr_modalias);
> if (rc)
> device_unregister(&ofdev->dev);
>
> @@ -126,6 +144,7 @@ EXPORT_SYMBOL(of_device_register);
> void of_device_unregister(struct of_device *ofdev)
> {
> device_remove_file(&ofdev->dev, &dev_attr_devspec);
> + device_remove_file(&ofdev->dev, &dev_attr_modalias);
> device_unregister(&ofdev->dev);
> }
> EXPORT_SYMBOL(of_device_unregister);
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Mel Gorman @ 2008-01-22 23:10 UTC (permalink / raw)
To: Christoph Lameter
Cc: lee.schermerhorn, Olaf Hering, Linux MM, linux-kernel,
linuxppc-dev, Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan,
akpm, KAMEZAWA Hiroyuki
In-Reply-To: <Pine.LNX.4.64.0801221453480.2271@schroedinger.engr.sgi.com>
On (22/01/08 14:57), Christoph Lameter didst pronounce:
> On Tue, 22 Jan 2008, Mel Gorman wrote:
>
> > > > Whatever this was a problem fixed in the past or not, it's broken again now
> > > > :( . It's possible that there is a __GFP_THISNODE that can be dropped early
> > > > at boot-time that would also fix this problem in a way that doesn't
> > > > affect runtime (like altering cache_grow in my patch does).
> > >
> > > The dropping of GFP_THISNODE has the same effect as your patch.
> >
> > The dropping of it totally? If so, this patch might fix a boot but it'll
> > potentially be a performance regression on NUMA machines that only have
> > nodes with memory, right?
>
> No the dropping during early allocations.,
>
We can live with that if the machine otherwise survives during tests.
They are kicked off at the moment with CONFIG_SLAB_DEBUG set but the point
is moot if the patch doesn't work for Olaf. Am still waiting to hear if
the two patches in combination work for him.
> > o 0
> > o 2
> > Nodes with regular memory
> > o 2
> > Current running CPU 0 is associated with node 0
> > Current node is 0
> >
> > So node 2 has regular memory but it's trying to use node 0 at a glance.
> > I've attached the patch I used against 2.6.24-rc8. It includes the revert.
>
> We need the current processor to be attached to a node that has
> memory. We cannot fall back that early because the structures for the
> other nodes do not exist yet.
>
Or bodge it early in the boot process so that a node with memory is
always used.
> > Online nodes
> > o 0
> > o 2
> > Nodes with regular memory
> > o 2
> > Current running CPU 0 is associated with node 0
> > Current node is 0
> > o kmem_list3_init
>
> This needs to be node 2.
>
Rather it should be 2. I'll admit the physical setup of this machine is
.... less than ideal but clearly it's something that can happen even if
it's a bad idea.
> > [c0000000005c3b40] c0000000000dadec .cache_grow+0x7c/0x338
> > [c0000000005c3c00] c0000000000db54c .fallback_alloc+0x1c0/0x224
>
> Fallback during bootstrap.
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] [POWERPC]: constify function pointer tables
From: Stephen Rothwell @ 2008-01-22 23:11 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0801222042360.5722@fbirervta.pbzchgretzou.qr>
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
Hi Jan,
Good idea ... but ...
On Tue, 22 Jan 2008 20:43:09 +0100 (CET) Jan Engelhardt <jengelh@computergmbh.de> wrote:
>
> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
> index 2de00f8..57d4f28 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -296,7 +296,7 @@ static void c_stop(struct seq_file *m, void *v)
> {
> }
>
> -struct seq_operations cpuinfo_op = {
> +const struct seq_operations cpuinfo_op = {
This is declared non const in fs/proc/proc_misc.c (one of the reasons why
it should be decalred in a header file ...)
The others look good, though.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Christoph Lameter @ 2008-01-22 23:12 UTC (permalink / raw)
To: Pekka Enberg
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: <47967560.8080101@cs.helsinki.fi>
On Wed, 23 Jan 2008, Pekka Enberg wrote:
> When we call fallback_alloc() because the current node has ->nodelists set to
> NULL, we end up calling kmem_getpages() with -1 as the node id which is then
> translated to numa_node_id() by alloc_pages_node. But the reason we called
> fallback_alloc() in the first place is because numa_node_id() doesn't have a
> ->nodelist which makes cache_grow() oops.
Right, if nodeid == -1 then we need to call alloc_pages...
Essentiall a revert of 50c85a19e7b3928b5b5188524c44ffcbacdd4e35 from 2005.
But I doubt that this is it. The fallback logic was added later and it
worked fine.
---
mm/slab.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6/mm/slab.c
===================================================================
--- linux-2.6.orig/mm/slab.c 2008-01-22 15:05:26.185452369 -0800
+++ linux-2.6/mm/slab.c 2008-01-22 15:05:59.301637009 -0800
@@ -1668,7 +1668,11 @@ static void *kmem_getpages(struct kmem_c
if (cachep->flags & SLAB_RECLAIM_ACCOUNT)
flags |= __GFP_RECLAIMABLE;
- page = alloc_pages_node(nodeid, flags, cachep->gfporder);
+ if (nodeid == -1)
+ page = alloc_pages(flags, cachep->gfporder);
+ else
+ page = alloc_pages_node(nodeid, flags, cachep->gfporder);
+
if (!page)
return NULL;
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Pekka Enberg @ 2008-01-22 22:59 UTC (permalink / raw)
To: Mel Gorman
Cc: lee.schermerhorn, Olaf Hering, Linux MM, linux-kernel,
linuxppc-dev, Aneesh Kumar K.V, hanth Aravamudan, akpm,
KAMEZAWA Hiroyuki, Christoph Lameter
In-Reply-To: <20080122225046.GA866@csn.ul.ie>
Hi,
Mel Gorman wrote:
> Faulting instruction address: 0xc0000000003c8c00
> cpu 0x0: Vector: 300 (Data Access) at [c0000000005c3840]
> pc: c0000000003c8c00: __lock_text_start+0x20/0x88
> lr: c0000000000dadec: .cache_grow+0x7c/0x338
> sp: c0000000005c3ac0
> msr: 8000000000009032
> dar: 40
> dsisr: 40000000
> current = 0xc000000000500f10
> paca = 0xc000000000501b80
> pid = 0, comm = swapper
> enter ? for help
> [c0000000005c3b40] c0000000000dadec .cache_grow+0x7c/0x338
> [c0000000005c3c00] c0000000000db54c .fallback_alloc+0x1c0/0x224
> [c0000000005c3cb0] c0000000000db958 .kmem_cache_alloc+0xe0/0x14c
> [c0000000005c3d50] c0000000000dcccc .kmem_cache_create+0x230/0x4cc
> [c0000000005c3e30] c0000000004c05f4 .kmem_cache_init+0x310/0x640
> [c0000000005c3ee0] c00000000049f8d8 .start_kernel+0x304/0x3fc
> [c0000000005c3f90] c000000000008594 .start_here_common+0x54/0xc0
> 0:mon>
I mentioned this already but received no response (maybe I am missing
something totally obvious here):
When we call fallback_alloc() because the current node has ->nodelists
set to NULL, we end up calling kmem_getpages() with -1 as the node id
which is then translated to numa_node_id() by alloc_pages_node. But the
reason we called fallback_alloc() in the first place is because
numa_node_id() doesn't have a ->nodelist which makes cache_grow() oops.
Pekka
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Christoph Lameter @ 2008-01-22 23:14 UTC (permalink / raw)
To: Mel Gorman
Cc: lee.schermerhorn, Olaf Hering, Linux MM, linux-kernel,
linuxppc-dev, Pekka Enberg, Aneesh Kumar K.V, hanth Aravamudan,
akpm, KAMEZAWA Hiroyuki
In-Reply-To: <20080122231058.GB866@csn.ul.ie>
On Tue, 22 Jan 2008, Mel Gorman wrote:
> Rather it should be 2. I'll admit the physical setup of this machine is
> .... less than ideal but clearly it's something that can happen even if
> it's a bad idea.
Ok. Lets hope that Pekka's find does the trick. But this would mean that
fallback gets memory from node 2 for the page allocator. Then fallback
alloc is going to try to insert it into the l3 of node 2 which is not
there yet. So another ooops. Sigh.
^ permalink raw reply
* Re: [PATCH 1/3 v3] Add StorCenter DTS first draft.
From: Grant Likely @ 2008-01-22 23:16 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <47967436.9070704@freescale.com>
On 1/22/08, Jon Loeliger <jdl@freescale.com> wrote:
> Grant Likely wrote:
> > On 1/22/08, Jon Loeliger <jdl@jdl.com> wrote:
> >> Based on the Kurobox DTS files.
> >>
> >> Signed-off-by: Andy Wilcox <andy@protium.com>
> >> Signed-off-by: Jon Loeliger <jdl@jdl.com>
> >
> > Comments below
> >
> >> +
> >> +/ {
> >> + model = "StorCenter";
> >> + compatible = "storcenter";
> >
> > Be specific! "iomega,storcenter". Even better if you put in the model number.
>
> As I mentioned vefore, there is no further model number.
> That _is_ the model name.
/me has a short memory.
> >> + compatible = "fsl,mpc8241", "mpc10x";
> >
> > fsl,mpc8241-immr would be better; this node describes the internally
> > memory mapped registers; not the entire soc.
>
> Uh, whatever? :-) 'Cuz how many other DTS files say that?
True, we haven't been doing this until recently; but we've also been
stumbling about over the last 2 years figuring out how best to use
this fancy device tree thing in embedded systems effectively. Best
practices are starting to emerge (wadda you know, the open firmware
recommended practices actually have good thought behind them) and
being specific with the compatible property is one aspect. I'm moving
the 5200 over to specifying -immr and some of the other soc ports are
doing so also. Chat with Scott Wood.
> >> + linux,stdout-path = "/soc/serial@4500";
> >
> > /soc@fc000000/ perhaps?
>
> Not really necessary to specify the unit number.
Okay, I wasn't sure if we could get away with that with the fdt.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: crash in kmem_cache_init
From: Christoph Lameter @ 2008-01-22 23:18 UTC (permalink / raw)
To: Pekka Enberg
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.0801221501240.2565@schroedinger.engr.sgi.com>
On Tue, 22 Jan 2008, Christoph Lameter wrote:
> But I doubt that this is it. The fallback logic was added later and it
> worked fine.
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....
^ permalink raw reply
* Re: [PATCH 2/2] MPC8641 HPCN: publish all soc and flash devices
From: Stephen Rothwell @ 2008-01-22 23:26 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <1201020432.5716.159.camel@rhino>
[-- Attachment #1: Type: text/plain, Size: 280 bytes --]
Hi Wade,
On Tue, 22 Jan 2008 09:47:12 -0700 Wade Farnsworth <wfarnsworth@mvista.com> wrote:
>
> +static struct of_device_id mpc86xx_ids[] = {
__initdata, please.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] MPC8641 HPCN: call of_platform_bus_probe()
From: Stephen Rothwell @ 2008-01-22 23:28 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <1201033065.5716.175.camel@rhino>
[-- Attachment #1: Type: text/plain, Size: 274 bytes --]
On Tue, 22 Jan 2008 13:17:45 -0700 Wade Farnsworth <wfarnsworth@mvista.com> wrote:
>
> +static struct of_device_id of_bus_ids[] = {
You forgot the __initdata.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] MPC8641 HPCN: call of_platform_bus_probe()
From: Kumar Gala @ 2008-01-22 23:36 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080123102800.409e146f.sfr@canb.auug.org.au>
On Jan 22, 2008, at 5:28 PM, Stephen Rothwell wrote:
> On Tue, 22 Jan 2008 13:17:45 -0700 Wade Farnsworth <wfarnsworth@mvista.com
> > wrote:
>>
>> +static struct of_device_id of_bus_ids[] = {
>
> You forgot the __initdata.
I've fixed it.
- k
^ permalink raw reply
* Re: [PATCH 2/3 v3] Add initial iomega StorCenter board port.
From: Stephen Rothwell @ 2008-01-22 23:51 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1JHRkl-0005e5-RX@jdl.com>
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
Hi Jon,
On Tue, 22 Jan 2008 16:37:59 -0600 Jon Loeliger <jdl@jdl.com> wrote:
>
> +++ b/arch/powerpc/platforms/embedded6xx/storcenter.c
> +extern void _nmask_and_or_msr(unsigned long nmask, unsigned long or_val);
This clearly needs to be decalred in some header file. (I know you did
not introduce it.) In arch/ppc, it was declared in asm/system.h (but I
don't know if that is appropriate for arch/powerpc). Maybe you could do
a preceeding patch that does this and fixes the other user.
> +static void __init storcenter_init_IRQ(void)
> +{
> + struct mpic *mpic;
> + struct device_node *dnp;
> + const void *prop;
> + int size;
> + phys_addr_t paddr;
> +
> + dnp = of_find_node_by_type(NULL, "open-pic");
> + if (dnp == NULL)
> + return;
> +
> + prop = of_get_property(dnp, "reg", &size);
> + paddr = (phys_addr_t)of_translate_address(dnp, prop);
What happens of "prop" is NULL?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc: fix #ifdef-s in mediabay driver
From: Benjamin Herrenschmidt @ 2008-01-22 23:59 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <200801230012.38516.bzolnier@gmail.com>
On Wed, 2008-01-23 at 00:12 +0100, Bartlomiej Zolnierkiewicz wrote:
> * Replace incorrect CONFIG_BLK_DEV_IDE #ifdef in
> check_media_bay() by CONFIG_MAC_FLOPPY one.
>
> * Replace incorrect CONFIG_BLK_DEV_IDE #ifdef-s by
> CONFIG_BLK_DEV_IDE_PMAC ones.
>
> * check_media_bay() is used only by drivers/block/swim3.c
> so make this function available only if CONFIG_MAC_FLOPPY
> is defined.
>
> * check_media_bay_by_base() and media_bay_set_ide_infos()
> are used only by drivers/ide/ppc/pmac.c so so make these
> functions available only if CONFIG_MAC_FLOPPY is defined.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
> Ben, IMO this patch is safe for 2.6.24 (assuming that it builds fine :),
> otherwise I would like to ask for permission to merge it through IDE
> tree since I have other pending IDE patches depending on this one.
I'd rather avoid touching 2.6.24 unless it actually fixes a bug or
regression...
I'm tempted to actually remove all ifdef's ... if you have a media-bay,
then there are about 99% chances it contains an IDE device, with the
remaining percent being split with putting a floppy or a battery in. I
doubt anybody will care building a kernel without the support for these
and with the mediabay support, and still want to save a handful of bytes
in that driver.
Ben.
^ permalink raw reply
* Re: [MPC5200] problem running FEC and ATA
From: Wolfgang Denk @ 2008-01-23 0:20 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev, Mehlan, Markus (Ritter Elektronik)
In-Reply-To: <200801211728.22817.jbe@pengutronix.de>
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...
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
It would be illogical to assume that all conditions remain stable
-- Spock, "The Enterprise" Incident", stardate 5027.3
^ permalink raw reply
* Re: [PATCH 1/3 v3] Add StorCenter DTS first draft.
From: Benjamin Herrenschmidt @ 2008-01-23 0:33 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <fa686aa40801221449p28889ea5r68bd726726558dc0@mail.gmail.com>
> > +
> > + mpic: interrupt-controller@40000 {
> > + #interrupt-cells = <2>;
> > + #address-cells = <0>;
>
> Is #address-cells needed? There are no child nodes.
It's preferrable for interrupt controllers as #address-cells of the
parent interrupt controller defines the size of the interrupt unit
specifier in the child in the interrupt tree.
I think there's an ongoing argument as to whether the absence of
#address-cells should be the same as #address-cells = 0 in that specific
case but I'm not sure the code does the right thing so let's have it
explicit.
Ben.
^ permalink raw reply
* Re: [PATCH 0/6] PS3: gelic: gelic updates for 2.6.25
From: Benjamin Herrenschmidt @ 2008-01-23 0:40 UTC (permalink / raw)
To: John W. Linville; +Cc: Geert.Uytterhoeven, netdev, Linux/PPC Development
In-Reply-To: <20080122211239.GC3206@tuxdriver.com>
On Tue, 2008-01-22 at 16:12 -0500, John W. Linville wrote:
> On Thu, Dec 13, 2007 at 07:38:28PM +0900, Masakazu Mokuno wrote:
>
> > Here is a set of updates for PS3 gelic network driver.
> > This patch set requires other patches which were already submitted by
> > Geert (http://marc.info/?l=linux-kernel&m=119626095605487).
> >
> > [1] PS3: gelic: Fix the wrong dev_id passed
> > [2] PS3: gelic: Add endianness macros
> > [3] PS3: gelic: Code cleanup
> > [4] PS3: gelic: Remove duplicated ethtool handers
> > [5] PS3: gelic: Add support for port link status
> > [6] PS3: gelic: Add support for dual network interface
> >
> > This is also a set of prerequisite for new wireless driver for PS3, which
> > I'll submit later.
>
> These seem to not have been applied, but I couldn't find any stated
> reason. Did they just get lost? Withdrawn?
>
> Will these be applied? There is a wireless patch that depends on them.
> If not, will the wireless portion be refactored to not require these
> patches?
The list of 6 patches above are the patches that Masakazu Mukono is
submitting, the pre-reqs are different patches (see the linked URL),
though I can't see them in either (they should probably go through
paulus for-2.6.25). Geert, what's up with these ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] ppc: fix #ifdef-s in mediabay driver
From: Bartlomiej Zolnierkiewicz @ 2008-01-23 0:58 UTC (permalink / raw)
To: benh; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <1201046394.6807.49.camel@pasglop>
Hi,
On Wednesday 23 January 2008, Benjamin Herrenschmidt wrote:
>
> On Wed, 2008-01-23 at 00:12 +0100, Bartlomiej Zolnierkiewicz wrote:
> > * Replace incorrect CONFIG_BLK_DEV_IDE #ifdef in
> > check_media_bay() by CONFIG_MAC_FLOPPY one.
> >
> > * Replace incorrect CONFIG_BLK_DEV_IDE #ifdef-s by
> > CONFIG_BLK_DEV_IDE_PMAC ones.
> >
> > * check_media_bay() is used only by drivers/block/swim3.c
> > so make this function available only if CONFIG_MAC_FLOPPY
> > is defined.
> >
> > * check_media_bay_by_base() and media_bay_set_ide_infos()
> > are used only by drivers/ide/ppc/pmac.c so so make these
> > functions available only if CONFIG_MAC_FLOPPY is defined.
> >
> > Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > ---
> > Ben, IMO this patch is safe for 2.6.24 (assuming that it builds fine :),
> > otherwise I would like to ask for permission to merge it through IDE
> > tree since I have other pending IDE patches depending on this one.
>
> I'd rather avoid touching 2.6.24 unless it actually fixes a bug or
> regression...
Well, it is a bugfix for PMAC_MEDIABAY=y && BLK_DEV_IDE=n && MAC_FLOPPY=y. :)
> I'm tempted to actually remove all ifdef's ... if you have a media-bay,
> then there are about 99% chances it contains an IDE device, with the
> remaining percent being split with putting a floppy or a battery in. I
> doubt anybody will care building a kernel without the support for these
> and with the mediabay support, and still want to save a handful of bytes
> in that driver.
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).
Thanks,
Bart
^ permalink raw reply
* Re: [PATCH 0/6] PS3: gelic: gelic updates for 2.6.25
From: John W. Linville @ 2008-01-23 0:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Geert.Uytterhoeven, netdev, Linux/PPC Development
In-Reply-To: <1201048834.6807.55.camel@pasglop>
On Wed, Jan 23, 2008 at 11:40:34AM +1100, Benjamin Herrenschmidt wrote:
>
> On Tue, 2008-01-22 at 16:12 -0500, John W. Linville wrote:
> > On Thu, Dec 13, 2007 at 07:38:28PM +0900, Masakazu Mokuno wrote:
> >
> > > Here is a set of updates for PS3 gelic network driver.
> > > This patch set requires other patches which were already submitted by
> > > Geert (http://marc.info/?l=linux-kernel&m=119626095605487).
> > >
> > > [1] PS3: gelic: Fix the wrong dev_id passed
> > > [2] PS3: gelic: Add endianness macros
> > > [3] PS3: gelic: Code cleanup
> > > [4] PS3: gelic: Remove duplicated ethtool handers
> > > [5] PS3: gelic: Add support for port link status
> > > [6] PS3: gelic: Add support for dual network interface
> > >
> > > This is also a set of prerequisite for new wireless driver for PS3, which
> > > I'll submit later.
> >
> > These seem to not have been applied, but I couldn't find any stated
> > reason. Did they just get lost? Withdrawn?
> >
> > Will these be applied? There is a wireless patch that depends on them.
> > If not, will the wireless portion be refactored to not require these
> > patches?
>
> The list of 6 patches above are the patches that Masakazu Mukono is
> submitting, the pre-reqs are different patches (see the linked URL),
> though I can't see them in either (they should probably go through
> paulus for-2.6.25). Geert, what's up with these ?
The wireless patch depends on the patches 1-6, which then depend on
Geert's patches.
I thought Geert's had been applied, but I guess I was looking at
it wrong. Is there a powerpc tree that has them? Perhaps 1-6 above
and the wireless patch should just be applied to that tree (if there
is one) and all merged together?
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH 1/3 v3] Add StorCenter DTS first draft.
From: Josh Boyer @ 2008-01-23 1:39 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Loeliger, Jon
In-Reply-To: <1201048396.6807.52.camel@pasglop>
On Wed, 23 Jan 2008 11:33:16 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > > +
> > > + mpic: interrupt-controller@40000 {
> > > + #interrupt-cells = <2>;
> > > + #address-cells = <0>;
> >
> > Is #address-cells needed? There are no child nodes.
>
> It's preferrable for interrupt controllers as #address-cells of the
> parent interrupt controller defines the size of the interrupt unit
> specifier in the child in the interrupt tree.
>
> I think there's an ongoing argument as to whether the absence of
> #address-cells should be the same as #address-cells = 0 in that specific
> case but I'm not sure the code does the right thing so let's have it
> explicit.
The code doesn't handle the lack of #address-cells in nodes where
there is an interrupt-map. It pukes if there is no reg property and
addrsize != 0. In the absence of the #address-cells property, it will
try to look at the parent's #address-cells, and if that lacks it, it
will assign 2 which it then merrily decides is incorrect.
josh
^ permalink raw reply
* Re: [PATCH 1/3 v3] Add StorCenter DTS first draft.
From: Scott Wood @ 2008-01-23 0:47 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <1201048396.6807.52.camel@pasglop>
Benjamin Herrenschmidt wrote:
> I think there's an ongoing argument as to whether the absence of
> #address-cells should be the same as #address-cells = 0 in that specific
> case but I'm not sure the code does the right thing so let's have it
> explicit.
I've had no problems leaving it out.
-Scott
^ permalink raw reply
* BDI Problems
From: Zhou Rui @ 2008-01-23 1:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi, all:
I am using BDI2000 with PowerPC. Sometimes, when I try
to change configuration of BDI2000 for different
PowerPC boards, the configuring procedure may meet the
following errors:
root@laz:/home/zhour/bdi2000sw/bdisetup2007#
./bdisetup -v -p/dev/ttyS0 -b115
Connecting to BDI loader failed (-1201)
I also have tried /dev/ttyS1 and got the same result,
and I am sure there is not any other programs
occupying the serial ports. So would anyone give me
some advice about this?
Another problem is "PPC: JTAG instruction stuff
overrun" during debugging. For this error, I found an
explanation (http://www.ultsol.com/faq_p202.htm):
"When in debug mode the PPC4xx fetches normal PPC
instructions from the JTAG port. The error "# PPC:
JTAG instruction stuff overrun" is raised when the
processor stops fetching from the JTAG port, possibly
because the processor hangs at an un-terminated memory
transfer." The proposed resolution is based on the
modification of configuration file. However, I have
tried that but it seems to have no effect.
Best wishes
Best wishes
Zhou Rui
Distributed and Embedded System Lab
Room 532, Information Building
School of Information Science
Lanzhou University, P. R. China
Tel: 86-0931-8912025
Zip Code: 730000
___________________________________________________________
雅虎邮箱传递新年祝福，个性贺卡送亲朋！
http://cn.mail.yahoo.com/gc/index.html?entry=5&souce=mail_mailletter_tagline
^ 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