* NAND and JFFS2 supports in Linux 2.4
From: Laurent Lagrange @ 2006-04-11 16:31 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I work on a custom 82xx board with a NAND flash :
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V
8-bit)
I have to KEEP a Linux 2.4 and can't migrate to a Linux 2.6 for this board.
This type of NAND flash and JFFS2 work fine with a Linux 2.6 but with a
Linux 2.4,
this is a little tricky :
Linux 2.4.18 or 2.4.25 do not support this device,
Linux 2.4.31 seems supporting this device but JFFS2 is not adapted,
Linux 2.4.32 does not support this device anymore.
On www.linux-mtd.infradead.org, it seems that Linux 2.4 is no more
supported.
Any help would be welcome
Thanks
Laurent
^ permalink raw reply
* Re: [PATCH 6/6] Break out memory initialisation code from page_alloc.c to mem_init.c
From: Mel Gorman @ 2006-04-11 16:59 UTC (permalink / raw)
To: Nick Piggin; +Cc: davej, tony.luck, ak, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <443B8DE7.4000900@yahoo.com.au>
On Tue, 11 Apr 2006, Nick Piggin wrote:
> Mel Gorman wrote:
>> page_alloc.c contains a large amount of memory initialisation code. This
>> patch
>> breaks out the initialisation code to a separate file to make page_alloc.c
>> a bit easier to read.
>>
>
> Seems like a very good idea to me.
>
If there is interest in treating this separetly, it can be broken out as a
standalone patch. In this form, it depends on the first patch from the
set.
>> +/*
>> + * mm/mem_init.c
>> + * Initialises the architecture independant view of memory. pgdats, zones,
>> etc
>> + *
>> + * Copyright (C) 1991, 1992, 1993, 1994 Linus Torvalds
>> + * Swap reorganised 29.12.95, Stephen Tweedie
>> + * Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999
>> + * Reshaped it to be a zoned allocator, Ingo Molnar, Red Hat, 1999
>> + * Discontiguous memory support, Kanoj Sarcar, SGI, Nov 1999
>> + * Zone balancing, Kanoj Sarcar, SGI, Jan 2000
>> + * Per cpu hot/cold page lists, bulk allocation, Martin J. Bligh, Sept
>> 2002
>> + * (lots of bits borrowed from Ingo Molnar & Andrew Morton)
>> + * Arch-independant zone size and hole calculation, Mel Gorman, IBM, Apr
>> 2006
>> + * (lots of bits taken from architecture code)
>> + */
>
> Maybe drop the duplicated changelog? (just retain copyrights I guess)
>
Makes sense.
+ * Copyright (C) 1991, 1992, 1993, 1994 Linus Torvalds
+ * Copyright (C) 1995, Stephen Tweedie
+ * Copyright (C) July 1999, Gerhard Wichert, Siemens AG
+ * Copyright (C) 1999, Ingo Molnar, Red Hat
+ * Copyright (C) 1999, 2000, Kanoj Sarcar, SGI
+ * Copyright (C) Sept 2000, Martin J. Bligh
+ * (lots of bits borrowed from Ingo Molnar & Andrew Morton)
+ * Copyright (C) Apr 2006, Mel Gorman, IBM
+ * (lots of bits taken from architecture-specific code)
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH 1/2] tickless idle cpus: core patch - v2
From: Paul Mackerras @ 2006-04-11 17:35 UTC (permalink / raw)
To: vatsa; +Cc: linuxppc-dev
In-Reply-To: <20060410121847.GB5564@in.ibm.com>
Srivatsa Vaddagiri writes:
> This is the v2 of the core patch to skip ticks when a CPU is idle.
> Changes since v1:
>
> - fix the buggy call to stop_hz_timer in idle_power4.S (hopefully it
> is correct now!).
It would be nice if we could arrange to call stop_hz_timer from the
top-level cpu_idle() function rather than having to call it from the
individual power_save() functions such as power4_idle(). Can you see
a problem with doing that?
Paul.
^ permalink raw reply
* Re: [PATCH] Set cpu explicitly in kernel compiles
From: Olaf Hering @ 2006-04-11 18:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, trini
In-Reply-To: <17460.39696.910677.444426@cargo.ozlabs.ibm.com>
On Thu, Apr 06, Paul Mackeras wrote:
> Olaf Hering writes:
>
> > --- linux-2.6.16-olh.orig/arch/powerpc/Makefile
> > +++ linux-2.6.16-olh/arch/powerpc/Makefile
> > @@ -107,6 +107,7 @@ endif
> > cpu-as-$(CONFIG_PPC64BRIDGE) += -Wa,-mppc64bridge
> > cpu-as-$(CONFIG_4xx) += -Wa,-m405
> > cpu-as-$(CONFIG_6xx) += -Wa,-maltivec
> > +cpu-as-$(CONFIG_6xx) += -mcpu=powerpc
>
> Is this really the right place for this? The cpu-as- thing is really
> for assembler options.
Compile the 32bit kernel with -mcpu=powerpc. This reduces the imagesize
when a compiler is used that defaults to -mtune=power4. It inserts lots
of nops to please the 64bit cpu instruction scheduling. But all these nops
are not needed for 32bit kernels.
Example with SLES10 gcc 4.1.0 and arch/powerpc/configs/pmac32_defconfig:
vmlinux vmlinux.strip vmlinux.gz
-O2 4980515 4187528 1846829
-Os 4618801 3827084 1673333
-O2 -mcpu=powerpc 4738851 3945868 1816253
-Os -mcpu=powerpc 4532785 3741068 1664688
Signed-off-by: Olaf Hering <olh@suse.de>
---
arch/powerpc/Makefile | 4 ++++
1 file changed, 4 insertions(+)
Index: linux-2.6.16-olh/arch/powerpc/Makefile
===================================================================
--- linux-2.6.16-olh.orig/arch/powerpc/Makefile
+++ linux-2.6.16-olh/arch/powerpc/Makefile
@@ -104,6 +104,10 @@ ifndef CONFIG_FSL_BOOKE
CFLAGS += -mstring
endif
+ifeq ($(CONFIG_6xx),y)
+CFLAGS += -mcpu=powerpc
+endif
+
cpu-as-$(CONFIG_PPC64BRIDGE) += -Wa,-mppc64bridge
cpu-as-$(CONFIG_4xx) += -Wa,-m405
cpu-as-$(CONFIG_6xx) += -Wa,-maltivec
^ permalink raw reply
* Re: Xilinx Virtex-2 PRO FPGA ppc 405 on ML310 board
From: Grant Likely @ 2006-04-11 19:46 UTC (permalink / raw)
To: Vincent Winstead; +Cc: linuxppc-embedded
In-Reply-To: <20060411125550.52660.qmail@web52002.mail.yahoo.com>
On 4/11/06, Vincent Winstead <vwinstead@yahoo.com> wrote:
>
> I'm having a real difficulty trying to get linux onto this board. So I'm
> finally turning to the community for help. The only people that have
> documented their approach to putting open source linux onto the ML310 boa=
rd
> have used bitkeeper to download the kernel for the project, but bitkeeper
> isn't used any more is it? I've been going straight to kernel.org and
> getting kernels from there and crosscompiling them on my machine to be
> transported to the ppc core on the ML310. Is this wrong? Is there a pat=
ch
> or some kernel source that I don't know about for PPC? Thanks!
Are you using 2.4 or 2.6?
Support for the ML300 & ML403 is in the mainline 2.6 git tree. As
long as you've got an xparameters.h file for your FPGA bitstream, you
should be able to port a 2.6 kernel really easily.
If you want to use 2.4, you can pull the linuxppc rsync mirror which
has ML300 support in it.
http://www.penguinppc.org/kernel/ (Look at the very bottom of the
page for the RSYNC mirror)
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
* Re: NAND and JFFS2 supports in Linux 2.4
From: Jaap-Jan Boor @ 2006-04-11 20:06 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000001c65d85$5e699890$5201a8c0@GEG2400>
Laurent,
Take a look at the 2.4 http://www.denx.de kernel, it has NAND and jffs2
support.
Jaap-Jan
On 11-apr-2006, at 18:31, Laurent Lagrange wrote:
>
> Hello,
>
> I work on a custom 82xx board with a NAND flash :
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND
> 128MiB 3,3V
> 8-bit)
>
> I have to KEEP a Linux 2.4 and can't migrate to a Linux 2.6 for
> this board.
>
> This type of NAND flash and JFFS2 work fine with a Linux 2.6 but
> with a
> Linux 2.4,
> this is a little tricky :
> Linux 2.4.18 or 2.4.25 do not support this device,
> Linux 2.4.31 seems supporting this device but JFFS2 is not adapted,
> Linux 2.4.32 does not support this device anymore.
>
> On www.linux-mtd.infradead.org, it seems that Linux 2.4 is no more
> supported.
>
> Any help would be welcome
> Thanks
> Laurent
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> --
> This message has been scanned for viruses and is believed to be clean
>
____
J.G.J. Boor Anton Philipsweg 1
Software Engineer 1223 KZ Hilversum
AimSys bv tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum jjboor at aimsys dot nl
^ permalink raw reply
* Re: [PATCH 2/2] Base pSeries PCIe support
From: Benjamin Herrenschmidt @ 2006-04-11 21:31 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060410103929.9664238d.moilanen@austin.ibm.com>
> I was able to validate that these patches do work, and we are receiving
> MSI interrupts correctly.
>
> Is it too late to get into 2.6.17?
Yes and it's totally broken anyway. The whole idea of "hiding" MSIs as
if they were LSIs is totally irrealistic in practice. Our firmware might
do it but we have to undo it.
Linux defines the semantics of a driver probe() routine to be called
with MSIs disabled by default.
This is very important as for a lot of devices (I'd say the vast
majority of the devices that claim to be MSI capable), enabling MSI is
either broken (various HW bugs related to using them, mostly ordering
issues) or requires all sort of additional tweaking on the device side
in addition to the standard config space stuffs.
Thus, we need to help whoever is currently ripping off the
drivers/pci/msi.c code which is way too Intel-centric (there's an SGI
guy working on it already) and implement an arch specific implementation
that undoes what the firmware did, and then re-assign MSIs as requested
by drviers.
Some of the Boeblingen folks have already been looking into it as part
of some bare-metal/bringup effort, but that doesn't include PAPR
implementation.
Ben.
^ permalink raw reply
* Re: NAND and JFFS2 supports in Linux 2.4
From: Josh Boyer @ 2006-04-11 21:19 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000001c65d85$5e699890$5201a8c0@GEG2400>
On Tue, 2006-04-11 at 18:31 +0200, Laurent Lagrange wrote:
> Hello,
>
> I work on a custom 82xx board with a NAND flash :
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V
> 8-bit)
>
> I have to KEEP a Linux 2.4 and can't migrate to a Linux 2.6 for this board.
>
> This type of NAND flash and JFFS2 work fine with a Linux 2.6 but with a
> Linux 2.4,
> this is a little tricky :
> Linux 2.4.18 or 2.4.25 do not support this device,
Those are entire too old.
> Linux 2.4.31 seems supporting this device but JFFS2 is not adapted,
NAND + JFFS2 + 2.4 is not a supported combination.
> Linux 2.4.32 does not support this device anymore.
Odd. Do you have a diff from .31 to .32?
> On www.linux-mtd.infradead.org, it seems that Linux 2.4 is no more
> supported.
Well, 2.4 is supported but no new features go in that tree. Including
NAND support in JFFS2. If there is a bug in the 2.4 code that is
present in MTD/JFFS2 it can certainly still be fixed.
>
> Any help would be welcome
You might try your luck with patching the latest 2.4 kernel with MTD
CVS. But be warned that quite a few things have changed, so you'd have
to essentially backport.
And keep in mind that it's not supported.
josh
^ permalink raw reply
* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Luck, Tony @ 2006-04-11 22:20 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, ak, linux-kernel, davej
In-Reply-To: <20060411103946.18153.83059.sendpatchset@skynet>
On Tue, Apr 11, 2006 at 11:39:46AM +0100, Mel Gorman wrote:
> The patches have only been *compile tested* for ia64 with a flatmem
> configuration. At attempt was made to boot test on an ancient RS/6000
> but the vanilla kernel does not boot so I have to investigate there.
The good news: Compilation is clean on the ia64 config variants that
I usually build (all 10 of them).
The bad (or at least consistent) news: It doesn't boot on an Intel
Tiger either (oops at kmem_cache_alloc+0x41).
-Tony
^ permalink raw reply
* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Mel Gorman @ 2006-04-11 23:23 UTC (permalink / raw)
To: Luck, Tony; +Cc: linuxppc-dev, ak, Linux Kernel Mailing List, davej
In-Reply-To: <20060411222029.GA7743@agluck-lia64.sc.intel.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1754 bytes --]
On Tue, 11 Apr 2006, Luck, Tony wrote:
> On Tue, Apr 11, 2006 at 11:39:46AM +0100, Mel Gorman wrote:
>
>> The patches have only been *compile tested* for ia64 with a flatmem
>> configuration. At attempt was made to boot test on an ancient RS/6000
>> but the vanilla kernel does not boot so I have to investigate there.
>
> The good news: Compilation is clean on the ia64 config variants that
> I usually build (all 10 of them).
>
One plus at least.
> The bad (or at least consistent) news: It doesn't boot on an Intel
> Tiger either (oops at kmem_cache_alloc+0x41).
>
Darn.
o Did it boot on other IA64 machines or was the Tiger the first boot failure?
o Possibly a stupid question but does the Tiger configuration use the
flatmem memory model, sparsemem or discontig?
If it's flatmem, I noticed I made a stupid mistake where vmem_map is not
getting set to (void *)0 for machines with small memory holes. Nothing
else really obvious jumped out at me.
I've attached a patch called "105-ia64_use_init_nodes.patch". Can you
reverse Patch 5/6 and apply this one instead please? I've also attached
107-debug.diff that applies on top of patch 6/6. It just prints out
debugging information during startup that may tell me where I went wrong
in arch/ia64. I'd really appreciate it if you could use both patches, let
me know if it still fails to boot and send me the console log of the
machine starting up if it fails so I can make guesses as to what is going
wrong.
Thanks a lot for trying the patches out on ia64. It was the one arch of
the set I had no chance to test with at all :/
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
[-- Attachment #2: 105-ia64_use_init_nodes.patch --]
[-- Type: TEXT/PLAIN, Size: 8361 bytes --]
diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc1-104-x86_64_use_init_nodes/arch/ia64/Kconfig linux-2.6.17-rc1-105-ia64_use_init_nodes/arch/ia64/Kconfig
--- linux-2.6.17-rc1-104-x86_64_use_init_nodes/arch/ia64/Kconfig 2006-04-03 04:22:10.000000000 +0100
+++ linux-2.6.17-rc1-105-ia64_use_init_nodes/arch/ia64/Kconfig 2006-04-11 23:31:38.000000000 +0100
@@ -352,6 +352,9 @@ config NUMA
Access). This option is for configuring high-end multiprocessor
server systems. If in doubt, say N.
+config ARCH_POPULATES_NODE_MAP
+ def_bool y
+
# VIRTUAL_MEM_MAP and FLAT_NODE_MEM_MAP are functionally equivalent.
# VIRTUAL_MEM_MAP has been retained for historical reasons.
config VIRTUAL_MEM_MAP
diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc1-104-x86_64_use_init_nodes/arch/ia64/mm/contig.c linux-2.6.17-rc1-105-ia64_use_init_nodes/arch/ia64/mm/contig.c
--- linux-2.6.17-rc1-104-x86_64_use_init_nodes/arch/ia64/mm/contig.c 2006-04-03 04:22:10.000000000 +0100
+++ linux-2.6.17-rc1-105-ia64_use_init_nodes/arch/ia64/mm/contig.c 2006-04-11 23:56:45.000000000 +0100
@@ -26,10 +26,6 @@
#include <asm/sections.h>
#include <asm/mca.h>
-#ifdef CONFIG_VIRTUAL_MEM_MAP
-static unsigned long num_dma_physpages;
-#endif
-
/**
* show_mem - display a memory statistics summary
*
@@ -212,18 +208,6 @@ count_pages (u64 start, u64 end, void *a
return 0;
}
-#ifdef CONFIG_VIRTUAL_MEM_MAP
-static int
-count_dma_pages (u64 start, u64 end, void *arg)
-{
- unsigned long *count = arg;
-
- if (start < MAX_DMA_ADDRESS)
- *count += (min(end, MAX_DMA_ADDRESS) - start) >> PAGE_SHIFT;
- return 0;
-}
-#endif
-
/*
* Set up the page tables.
*/
@@ -232,47 +216,24 @@ void __init
paging_init (void)
{
unsigned long max_dma;
- unsigned long zones_size[MAX_NR_ZONES];
#ifdef CONFIG_VIRTUAL_MEM_MAP
- unsigned long zholes_size[MAX_NR_ZONES];
+ unsigned long nid = 0;
unsigned long max_gap;
#endif
- /* initialize mem_map[] */
-
- memset(zones_size, 0, sizeof(zones_size));
-
num_physpages = 0;
efi_memmap_walk(count_pages, &num_physpages);
max_dma = virt_to_phys((void *) MAX_DMA_ADDRESS) >> PAGE_SHIFT;
#ifdef CONFIG_VIRTUAL_MEM_MAP
- memset(zholes_size, 0, sizeof(zholes_size));
-
- num_dma_physpages = 0;
- efi_memmap_walk(count_dma_pages, &num_dma_physpages);
-
- if (max_low_pfn < max_dma) {
- zones_size[ZONE_DMA] = max_low_pfn;
- zholes_size[ZONE_DMA] = max_low_pfn - num_dma_physpages;
- } else {
- zones_size[ZONE_DMA] = max_dma;
- zholes_size[ZONE_DMA] = max_dma - num_dma_physpages;
- if (num_physpages > num_dma_physpages) {
- zones_size[ZONE_NORMAL] = max_low_pfn - max_dma;
- zholes_size[ZONE_NORMAL] =
- ((max_low_pfn - max_dma) -
- (num_physpages - num_dma_physpages));
- }
- }
-
max_gap = 0;
+ efi_memmap_walk(register_active_ranges, &nid);
efi_memmap_walk(find_largest_hole, (u64 *)&max_gap);
if (max_gap < LARGE_GAP) {
vmem_map = (struct page *) 0;
- free_area_init_node(0, NODE_DATA(0), zones_size, 0,
- zholes_size);
+ free_area_init_nodes(max_dma, max_dma,
+ max_low_pfn, max_low_pfn);
} else {
unsigned long map_size;
@@ -284,19 +245,14 @@ paging_init (void)
efi_memmap_walk(create_mem_map_page_table, NULL);
NODE_DATA(0)->node_mem_map = vmem_map;
- free_area_init_node(0, NODE_DATA(0), zones_size,
- 0, zholes_size);
+ free_area_init_nodes(max_dma, max_dma,
+ max_low_pfn, max_low_pfn);
printk("Virtual mem_map starts at 0x%p\n", mem_map);
}
#else /* !CONFIG_VIRTUAL_MEM_MAP */
- if (max_low_pfn < max_dma)
- zones_size[ZONE_DMA] = max_low_pfn;
- else {
- zones_size[ZONE_DMA] = max_dma;
- zones_size[ZONE_NORMAL] = max_low_pfn - max_dma;
- }
- free_area_init(zones_size);
+ add_active_range(0, 0, max_low_pfn);
+ free_area_init_nodes(max_dma, max_dma, max_low_pfn, max_low_pfn);
#endif /* !CONFIG_VIRTUAL_MEM_MAP */
zero_page_memmap_ptr = virt_to_page(ia64_imva(empty_zero_page));
}
diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc1-104-x86_64_use_init_nodes/arch/ia64/mm/discontig.c linux-2.6.17-rc1-105-ia64_use_init_nodes/arch/ia64/mm/discontig.c
--- linux-2.6.17-rc1-104-x86_64_use_init_nodes/arch/ia64/mm/discontig.c 2006-04-03 04:22:10.000000000 +0100
+++ linux-2.6.17-rc1-105-ia64_use_init_nodes/arch/ia64/mm/discontig.c 2006-04-11 23:54:06.000000000 +0100
@@ -87,6 +87,7 @@ static int __init build_node_maps(unsign
min_low_pfn = min(min_low_pfn, bdp->node_boot_start>>PAGE_SHIFT);
max_low_pfn = max(max_low_pfn, bdp->node_low_pfn);
+ add_active_range(node, start, end);
return 0;
}
@@ -660,9 +661,8 @@ static __init int count_node_pages(unsig
void __init paging_init(void)
{
unsigned long max_dma;
- unsigned long zones_size[MAX_NR_ZONES];
- unsigned long zholes_size[MAX_NR_ZONES];
unsigned long pfn_offset = 0;
+ unsigned long max_pfn = 0;
int node;
max_dma = virt_to_phys((void *) MAX_DMA_ADDRESS) >> PAGE_SHIFT;
@@ -679,46 +679,17 @@ void __init paging_init(void)
#endif
for_each_online_node(node) {
- memset(zones_size, 0, sizeof(zones_size));
- memset(zholes_size, 0, sizeof(zholes_size));
-
num_physpages += mem_data[node].num_physpages;
-
- if (mem_data[node].min_pfn >= max_dma) {
- /* All of this node's memory is above ZONE_DMA */
- zones_size[ZONE_NORMAL] = mem_data[node].max_pfn -
- mem_data[node].min_pfn;
- zholes_size[ZONE_NORMAL] = mem_data[node].max_pfn -
- mem_data[node].min_pfn -
- mem_data[node].num_physpages;
- } else if (mem_data[node].max_pfn < max_dma) {
- /* All of this node's memory is in ZONE_DMA */
- zones_size[ZONE_DMA] = mem_data[node].max_pfn -
- mem_data[node].min_pfn;
- zholes_size[ZONE_DMA] = mem_data[node].max_pfn -
- mem_data[node].min_pfn -
- mem_data[node].num_dma_physpages;
- } else {
- /* This node has memory in both zones */
- zones_size[ZONE_DMA] = max_dma -
- mem_data[node].min_pfn;
- zholes_size[ZONE_DMA] = zones_size[ZONE_DMA] -
- mem_data[node].num_dma_physpages;
- zones_size[ZONE_NORMAL] = mem_data[node].max_pfn -
- max_dma;
- zholes_size[ZONE_NORMAL] = zones_size[ZONE_NORMAL] -
- (mem_data[node].num_physpages -
- mem_data[node].num_dma_physpages);
- }
-
pfn_offset = mem_data[node].min_pfn;
#ifdef CONFIG_VIRTUAL_MEM_MAP
NODE_DATA(node)->node_mem_map = vmem_map + pfn_offset;
#endif
- free_area_init_node(node, NODE_DATA(node), zones_size,
- pfn_offset, zholes_size);
+ if (mem_data[node].max_pfn > max_pfn)
+ max_pfn = mem_data[node].max_pfn;
}
+ free_area_init_nodes(max_dma, max_dma, max_pfn, max_pfn);
+
zero_page_memmap_ptr = virt_to_page(ia64_imva(empty_zero_page));
}
diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc1-104-x86_64_use_init_nodes/arch/ia64/mm/init.c linux-2.6.17-rc1-105-ia64_use_init_nodes/arch/ia64/mm/init.c
--- linux-2.6.17-rc1-104-x86_64_use_init_nodes/arch/ia64/mm/init.c 2006-04-03 04:22:10.000000000 +0100
+++ linux-2.6.17-rc1-105-ia64_use_init_nodes/arch/ia64/mm/init.c 2006-04-11 23:40:15.000000000 +0100
@@ -539,6 +539,16 @@ find_largest_hole (u64 start, u64 end, v
last_end = end;
return 0;
}
+
+int __init
+register_active_ranges(u64 start, u64 end, void *nid)
+{
+ BUG_ON(nid == NULL);
+ BUG_ON(*(unsigned long *)nid >= MAX_NUMNODES);
+
+ add_active_range(*(unsigned long *)nid, start, end);
+ return 0;
+}
#endif /* CONFIG_VIRTUAL_MEM_MAP */
static int __init
diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc1-104-x86_64_use_init_nodes/include/asm-ia64/meminit.h linux-2.6.17-rc1-105-ia64_use_init_nodes/include/asm-ia64/meminit.h
--- linux-2.6.17-rc1-104-x86_64_use_init_nodes/include/asm-ia64/meminit.h 2006-04-03 04:22:10.000000000 +0100
+++ linux-2.6.17-rc1-105-ia64_use_init_nodes/include/asm-ia64/meminit.h 2006-04-11 23:34:58.000000000 +0100
@@ -56,6 +56,7 @@ extern void efi_memmap_init(unsigned lon
extern unsigned long vmalloc_end;
extern struct page *vmem_map;
extern int find_largest_hole (u64 start, u64 end, void *arg);
+ extern int register_active_ranges (u64 start, u64 end, void *arg);
extern int create_mem_map_page_table (u64 start, u64 end, void *arg);
#endif
[-- Attachment #3: 107-debug.diff --]
[-- Type: TEXT/PLAIN, Size: 3852 bytes --]
diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc1-106-breakout_mem_init/mm/mem_init.c linux-2.6.17-rc1-107-debug/mm/mem_init.c
--- linux-2.6.17-rc1-106-breakout_mem_init/mm/mem_init.c 2006-04-11 23:49:52.000000000 +0100
+++ linux-2.6.17-rc1-107-debug/mm/mem_init.c 2006-04-11 23:52:00.000000000 +0100
@@ -645,13 +645,23 @@ void __init free_bootmem_with_active_reg
for_each_active_range_index_in_nid(i, nid) {
unsigned long size_pages = 0;
unsigned long end_pfn = early_node_map[i].end_pfn;
- if (early_node_map[i].start_pfn >= max_low_pfn)
+ if (early_node_map[i].start_pfn >= max_low_pfn) {
+ printk("start_pfn %lu >= %lu\n", early_node_map[i].start_pfn,
+ max_low_pfn);
continue;
+ }
- if (end_pfn > max_low_pfn)
+ if (end_pfn > max_low_pfn) {
+ printk("end_pfn %lu going back to %lu\n", early_node_map[i].end_pfn,
+ max_low_pfn);
end_pfn = max_low_pfn;
+ }
size_pages = end_pfn - early_node_map[i].start_pfn;
+ printk("free_bootmem_node(%d, %lu, %lu)\n",
+ early_node_map[i].nid,
+ PFN_PHYS(early_node_map[i].start_pfn),
+ PFN_PHYS(size_pages));
free_bootmem_node(NODE_DATA(early_node_map[i].nid),
PFN_PHYS(early_node_map[i].start_pfn),
PFN_PHYS(size_pages));
@@ -661,10 +671,15 @@ void __init free_bootmem_with_active_reg
void __init memory_present_with_active_regions(int nid)
{
unsigned int i;
- for_each_active_range_index_in_nid(i, nid)
+ for_each_active_range_index_in_nid(i, nid) {
+ printk("memory_present(%d, %lu, %lu)\n",
+ early_node_map[i].nid,
+ early_node_map[i].start_pfn,
+ early_node_map[i].end_pfn);
memory_present(early_node_map[i].nid,
early_node_map[i].start_pfn,
early_node_map[i].end_pfn);
+ }
}
void __init get_pfn_range_for_nid(unsigned int nid,
@@ -752,8 +767,16 @@ unsigned long __init zone_absent_pages_i
/* Increase the hole size if the hole is within the zone */
start_pfn = early_node_map[i].start_pfn;
if (pfn_range_in_zone(prev_end_pfn, start_pfn, zone_type)) {
- BUG_ON(prev_end_pfn > start_pfn);
+ if (prev_end_pfn > start_pfn) {
+ printk("prev_end > start_pfn : %lu > %lu\n",
+ prev_end_pfn,
+ start_pfn);
+ BUG();
+ }
+ //BUG_ON(prev_end_pfn > start_pfn);
hole_pages += start_pfn - prev_end_pfn;
+ printk("Hole found index %d: %lu -> %lu\n",
+ i, prev_end_pfn, start_pfn);
}
prev_end_pfn = early_node_map[i].end_pfn;
@@ -907,17 +930,21 @@ void __init add_active_range(unsigned in
unsigned int i;
unsigned long pages = end_pfn - start_pfn;
+ printk("add_active_range(%d, %lu, %lu): ",
+ nid, start_pfn, end_pfn);
/* Merge with existing active regions if possible */
for (i = 0; early_node_map[i].end_pfn; i++) {
if (early_node_map[i].nid != nid)
continue;
if (early_node_map[i].end_pfn == start_pfn) {
+ printk("Merging forward\n");
early_node_map[i].end_pfn += pages;
return;
}
if (early_node_map[i].start_pfn == (start_pfn + pages)) {
+ printk("Merging backwards\n");
early_node_map[i].start_pfn -= pages;
return;
}
@@ -933,6 +960,7 @@ void __init add_active_range(unsigned in
return;
}
+ printk("New\n");
early_node_map[i].nid = nid;
early_node_map[i].start_pfn = start_pfn;
early_node_map[i].end_pfn = end_pfn;
@@ -962,6 +990,14 @@ static void __init sort_node_map(void)
sort(early_node_map, num, sizeof(struct node_active_region),
cmp_node_active_region, NULL);
+
+ printk("Dumping sorted node map\n");
+ for (num = 0; early_node_map[num].end_pfn; num++) {
+ printk("entry %lu: %d %lu -> %lu\n", num,
+ early_node_map[num].nid,
+ early_node_map[num].start_pfn,
+ early_node_map[num].end_pfn);
+ }
}
unsigned long __init find_min_pfn(void)
^ permalink raw reply
* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Bob Picco @ 2006-04-11 23:29 UTC (permalink / raw)
To: Luck, Tony; +Cc: Mel Gorman, linuxppc-dev, ak, linux-kernel, davej
In-Reply-To: <20060411222029.GA7743@agluck-lia64.sc.intel.com>
luck wrote: [Tue Apr 11 2006, 06:20:29PM EDT]
> On Tue, Apr 11, 2006 at 11:39:46AM +0100, Mel Gorman wrote:
>
> > The patches have only been *compile tested* for ia64 with a flatmem
> > configuration. At attempt was made to boot test on an ancient RS/6000
> > but the vanilla kernel does not boot so I have to investigate there.
>
> The good news: Compilation is clean on the ia64 config variants that
> I usually build (all 10 of them).
>
> The bad (or at least consistent) news: It doesn't boot on an Intel
> Tiger either (oops at kmem_cache_alloc+0x41).
>
> -Tony
I had a reply queued to report the same failure with
DISCONTIG+NUMA+VIRTUAL_MEM_MAP. This was 2 CPU HP rx2600. I'll take a closer
look at the code tomorrow.
bob
^ permalink raw reply
* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Mel Gorman @ 2006-04-12 0:02 UTC (permalink / raw)
To: Bob Picco; +Cc: linuxppc-dev, ak, Luck, Tony, Linux Kernel Mailing List, davej
In-Reply-To: <20060411232944.GE23742@localhost>
On Tue, 11 Apr 2006, Bob Picco wrote:
> luck wrote: [Tue Apr 11 2006, 06:20:29PM EDT]
>> On Tue, Apr 11, 2006 at 11:39:46AM +0100, Mel Gorman wrote:
>>
>>> The patches have only been *compile tested* for ia64 with a flatmem
>>> configuration. At attempt was made to boot test on an ancient RS/6000
>>> but the vanilla kernel does not boot so I have to investigate there.
>>
>> The good news: Compilation is clean on the ia64 config variants that
>> I usually build (all 10 of them).
>>
>> The bad (or at least consistent) news: It doesn't boot on an Intel
>> Tiger either (oops at kmem_cache_alloc+0x41).
>>
>> -Tony
> I had a reply queued to report the same failure with
> DISCONTIG+NUMA+VIRTUAL_MEM_MAP. This was 2 CPU HP rx2600. I'll take a closer
> look at the code tomorrow.
>
hmm, ok, so discontig.c is in use which narrows things down. When
build_node_maps() is called, I assumed that the start and end pfn passed
in was for a valid page range. Was this a valid assumption? When I re-read
the comment, it implies that memory holes could be within this range which
would cause boot failures. If that is the case, the correct thing to do
was to call add_active_range() in count_node_pages() instead of
build_node_maps().
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Luck, Tony @ 2006-04-12 0:05 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, ak, Linux Kernel Mailing List, davej
In-Reply-To: <Pine.LNX.4.64.0604112352230.6624@skynet.skynet.ie>
On Wed, Apr 12, 2006 at 12:23:45AM +0100, Mel Gorman wrote:
> Darn.
>
> o Did it boot on other IA64 machines or was the Tiger the first boot failure?
I only tried to boot on the Tiger.
> o Possibly a stupid question but does the Tiger configuration use the
> flatmem memory model, sparsemem or discontig?
I built using arch/ia64/configs/tiger_defconfig - a FLATMEM config with
VIRT_MEM_MAP=y. The machine has 4G of memory, 2G at 0-2G, and 2G at 6G-8G
(so it is somewhat sparse ... but this is pretty normal for an ia64 with
>2G).
> If it's flatmem, I noticed I made a stupid mistake where vmem_map is not
> getting set to (void *)0 for machines with small memory holes. Nothing
> else really obvious jumped out at me.
>
> I've attached a patch called "105-ia64_use_init_nodes.patch". Can you
> reverse Patch 5/6 and apply this one instead please? I've also attached
> 107-debug.diff that applies on top of patch 6/6. It just prints out
> debugging information during startup that may tell me where I went wrong
> in arch/ia64. I'd really appreciate it if you could use both patches, let
> me know if it still fails to boot and send me the console log of the
> machine starting up if it fails so I can make guesses as to what is going
> wrong.
>
> Thanks a lot for trying the patches out on ia64. It was the one arch of
> the set I had no chance to test with at all :/
Ok, I cloned a branch from patch4, applied the new patch 5, git-cherry-picked
patch 6, and then applied the debug patch7.
Here's the console log:
Linux version 2.6.17-rc1-tiger-smpxx (aegl@linux-t10) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)) #2 SMP Tue Apr 11 16:45:31 PDT 2006
EFI v1.10 by INTEL: SALsystab=0x7fe54980 ACPI=0x7ff84000 ACPI 2.0=0x7ff83000 MPS=0x7ff82000 SMBIOS=0xf0000
Early serial console at I/O port 0x2f8 (options '115200')
Initial ramdisk at: 0xe0000001fedf5000 (1303568 bytes)
SAL 3.20: Intel Corp SR870BN4 version 3.0
SAL Platform features: BusLock IRQ_Redirection
SAL: AP wakeup using external interrupt vector 0xf0
No logical to physical processor mapping available
iosapic_system_init: Disabling PC-AT compatible 8259 interrupts
ACPI: Local APIC address c0000000fee00000
PLATFORM int CPEI (0x3): GSI 22 (level, low) -> CPU 0 (0xc618) vector 30
register_intr: changing vector 39 from IO-SAPIC-edge to IO-SAPIC-level
4 CPUs available, 4 CPUs total
MCA related initialization done
add_active_range(0, 16140901064512634880, 16140901066637049856): New
add_active_range(0, 16140901066641899520, 16140901066642489344): New
add_active_range(0, 16140901070938308608, 16140901073083760640): New
add_active_range(0, 16140901073084219392, 16140901073085480960): New
Dumping sorted node map
entry 0: 0 16140901064512634880 -> 16140901066637049856
entry 1: 0 16140901066641899520 -> 16140901066642489344
entry 2: 0 16140901070938308608 -> 16140901073083760640
entry 3: 0 16140901073084219392 -> 16140901073085480960
Virtual mem_map starts at 0x0000000000000000
SMP: Allowing 4 CPUs, 0 hotplug CPUs
Built 1 zonelists
Kernel command line: BOOT_IMAGE=scsi0:EFI\redhat\l-tiger-smpxx.gz root=LABEL=/ console=uart,io,0x2f8 ro
PID hash table entries: 16 (order: 4, 128 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 1 (order: -11, 8 bytes)
Inode-cache hash table entries: 1 (order: -11, 8 bytes)
Placing software IO TLB between 0x4a84000 - 0x8a84000
kernel BUG at arch/ia64/mm/init.c:609!
swapper[0]: bugcheck! 0 [1]
Modules linked in:
Pid: 0, CPU 0, comm: swapper
psr : 00001010084a6010 ifs : 800000000000040f ip : [<a0000001007dd620>] Not tainted
ip is at mem_init+0x80/0x580
unat: 0000000000000000 pfs : 000000000000040f rsc : 0000000000000003
rnat: a00000010095fd80 bsps: 00000000000002f9 pr : 80000000afb5666b
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f
csd : 0930ffff00090000 ssd : 0930ffff00090000
b0 : a0000001007dd620 b6 : a0000001007f6ba0 b7 : a0000001003c27e0
f6 : 0fffbccccccccc8c00000 f7 : 0ffdbf300000000000000
f8 : 10001c000000000000000 f9 : 10002a000000000000000
f10 : 0fffe9999999996900000 f11 : 1003e0000000000000000
r1 : a000000100b460d0 r2 : 0000000000000000 r3 : a00000010095cba0
r8 : 000000000000002a r9 : a00000010095cb90 r10 : 00000000000002f9
r11 : 00000000000be000 r12 : a00000010080fe10 r13 : a000000100808000
r14 : 0000000000004000 r15 : a00000010095cba8 r16 : 0000000000000001
r17 : a00000010095cb98 r18 : ffffffffffffffff r19 : a00000010095fd88
r20 : 00000000000000be r21 : a00000010095bd50 r22 : 0000000000000000
r23 : a00000010095cbb8 r24 : a00000010087f7e8 r25 : a00000010087f7e0
r26 : a000000100946308 r27 : 00000010084a6010 r28 : 00000000000002f9
r29 : 00000000000002f8 r30 : 0000000000000000 r31 : a00000010095cb68
Unable to handle kernel NULL pointer dereference (address 0000000000000000)
swapper[0]: Oops 11012296146944 [2]
Modules linked in:
Pid: 0, CPU 0, comm: swapper
psr : 0000121008022018 ifs : 8000000000000287 ip : [<a000000100116b81>] Not tainted
ip is at kmem_cache_alloc+0x41/0x100
unat: 0000000000000000 pfs : 0000000000000793 rsc : 0000000000000003
rnat: 0000000000000000 bsps: 0000000000000000 pr : 80000000afb56967
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0930ffff00090000 ssd : 0930ffff00090000
b0 : a00000010003d820 b6 : a00000010003e600 b7 : a00000010000c9d0
f6 : 1003ea08f5c3b783104ea f7 : 1003e9e3779b97f4a7c16
f8 : 1003e0a0000001000117f f9 : 1003e000000000000007f
f10 : 1003e0000000000000379 f11 : 1003e6db6db6db6db6db7
r1 : a000000100b460d0 r2 : 0000000000000000 r3 : a000000100949240
r8 : 0000000000000000 r9 : 0000000000000000 r10 : 0000000000000000
r11 : a000000100808f14 r12 : a00000010080f260 r13 : a000000100808000
r14 : 0000000000000000 r15 : 000000000000000f r16 : a00000010080f2f0
r17 : 0000000000000000 r18 : a000000100876bd8 r19 : a00000010080f2ec
r20 : a00000010080f2e8 r21 : 000000007fffffff r22 : 0000000000000000
r23 : 0000000000000050 r24 : a0000001000117f0 r25 : a0000001000117a0
r26 : a000000100885480 r27 : a000000100946fb0 r28 : a00000010087df40
r29 : 0000000000000002 r30 : 0000000000000002 r31 : 00000000000000c0
^ permalink raw reply
* The behavior of L2 cache controller for PPC440
From: Shawn Jin @ 2006-04-12 1:04 UTC (permalink / raw)
To: ppcembed
Hi,
I'm testing the error interrupts of a PPC440 L2 cache controller and
having some confusion about the bahvior of the tag parity error. I
hope here in the list there are some people had worked on this before
can shed some light on it.
I use the error injection bit in L2_CONFIG to generate tag parity
error. The L2 cache error handler comes from ibm440gx_common.c, which
uses CTP command to clear a tag error. However once a tag parity error
occurs, the handler keeps getting invoked and the error interrupt
keeps asserted. It looks like that the CTP command won't clear the tag
error or the tag error status bit in L2_STATUS.
The L2 cache controller spec only says that CTP command will reset the
tag trap address and way registers within the L2 design such that they
can trap a new error. From this statement I assume it doesn't clear
the status bit in L2_STATUS. If my assumption is correct, then the
L2_INTERRUPT will keep asserted until a CLEAR command invalidates the
trapped cache line. This is NOT implemented in the ibm440gx_common.c's
l2_error_handler().
However is it really necessary to use CLEAR command to invalidate the
cache line? The spec describes tag array parity in section 2.6, which
says tag parity errors are self correcting since the way with a tag
parity error will be LRUed out of the L2 cache. So it seems that no
explicit invalidation is required.
So my question is "Does or should the CTP command clear the status bit
in L2_STATUS?"
Thanks for your comments,
-Shawn.
^ permalink raw reply
* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Bob Picco @ 2006-04-12 1:38 UTC (permalink / raw)
To: Mel Gorman
Cc: davej, Luck, Tony, ak, Bob Picco, Linux Kernel Mailing List,
linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0604120053080.10268@skynet.skynet.ie>
Mel Gorman wrote: [Tue Apr 11 2006, 08:02:10PM EDT]
> On Tue, 11 Apr 2006, Bob Picco wrote:
>
> >luck wrote: [Tue Apr 11 2006, 06:20:29PM EDT]
> >>On Tue, Apr 11, 2006 at 11:39:46AM +0100, Mel Gorman wrote:
> >>
> >>>The patches have only been *compile tested* for ia64 with a flatmem
> >>>configuration. At attempt was made to boot test on an ancient RS/6000
> >>>but the vanilla kernel does not boot so I have to investigate there.
> >>
> >>The good news: Compilation is clean on the ia64 config variants that
> >>I usually build (all 10 of them).
> >>
> >>The bad (or at least consistent) news: It doesn't boot on an Intel
> >>Tiger either (oops at kmem_cache_alloc+0x41).
> >>
> >>-Tony
> >I had a reply queued to report the same failure with
> >DISCONTIG+NUMA+VIRTUAL_MEM_MAP. This was 2 CPU HP rx2600. I'll take a
> >closer
> >look at the code tomorrow.
> >
>
> hmm, ok, so discontig.c is in use which narrows things down. When
> build_node_maps() is called, I assumed that the start and end pfn passed
> in was for a valid page range. Was this a valid assumption? When I re-read
The addresses are a valid physical range. The caution should be that
filter_rsvd_memory converts the addresses from identity mapped to
physical. efi_memmap_walk calls back to function with identity mapped
addresses. What you've done seems okay.
BTW - I like want you are attempting to achieve.
> the comment, it implies that memory holes could be within this range which
> would cause boot failures. If that is the case, the correct thing to do
> was to call add_active_range() in count_node_pages() instead of
> build_node_maps().
Yes that helps because of granules and it boots. The patch below is applied
on top of your original post. But..
Index: linux-2.6.17-rc1/arch/ia64/mm/discontig.c
===================================================================
--- linux-2.6.17-rc1.orig/arch/ia64/mm/discontig.c 2006-04-11 20:36:15.000000000 -0400
+++ linux-2.6.17-rc1/arch/ia64/mm/discontig.c 2006-04-11 20:52:59.000000000 -0400
@@ -88,9 +88,6 @@ static int __init build_node_maps(unsign
min_low_pfn = min(min_low_pfn, bdp->node_boot_start>>PAGE_SHIFT);
max_low_pfn = max(max_low_pfn, bdp->node_low_pfn);
- /* Add a known active range */
- add_active_range(node, start, end);
-
return 0;
}
@@ -651,6 +648,8 @@ static __init int count_node_pages(unsig
mem_data[node].min_pfn = min(mem_data[node].min_pfn,
start >> PAGE_SHIFT);
+ add_active_range(node, start, end);
+
return 0;
}
Page free/avail accounting is off and I'm done for tonight. I believe it's how
you treat holes but haven't looked closely yet.
Let me wrap my head around this code again. It's been some time.
>
bob
^ permalink raw reply
* Re: question about Linux 2.6 with Xilinx ML-403
From: yding @ 2006-04-12 2:11 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0604071518i5f95b4dbtd232d8cb92ef4fb9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 926 bytes --]
Hi, Grant,
Thanks for the information.
I just checked out Linus's GIT tree from
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
linux-2.6.
Where is the location for Paul's GIT tree ? Just curious ...
Best Regards,
--
Ying Ding
Grant Likely wrote:
>On 4/7/06, yding <yding@lnxw.com> wrote:
>
>
>> HI, Grant,
>>
>> I found this message :
>>http://patchwork.ozlabs.org/linuxppc/patch?id=3841 on
>>Internet.
>> It looks like you created some patch files for supporting Linux 2.6 with
>>Xilinx ML-403.
>>
>>how can download the whole kernel source tree with your patched files (via
>>cvs or bitkeeper) ?
>>
>>
>
>I believe they are now in Linus' mainline git tree. If not, they are
>in Paul's powerpc git tree.
>
>BTW, please CC the linuxppc-embedded mailing list when emailing me directly.
>
>Cheers,
>g.
>--
>Grant Likely, B.Sc. P.Eng.
>Secret Lab Technologies Ltd.
>(403) 399-0195
>
>
>
[-- Attachment #2: Type: text/html, Size: 1559 bytes --]
^ permalink raw reply
* Re: question about Linux 2.6 with Xilinx ML-403
From: Grant Likely @ 2006-04-12 4:04 UTC (permalink / raw)
To: yding; +Cc: linuxppc-embedded
In-Reply-To: <443C61BA.1030404@lnxw.com>
On 4/11/06, yding <yding@lnxw.com> wrote:
> I just checked out Linus's GIT tree from
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> linux-2.6.
>
> Where is the location for Paul's GIT tree ? Just curious ...
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2/2] Base pSeries PCIe support
From: Christoph Hellwig @ 2006-04-12 4:05 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060331161330.3c723103.moilanen@austin.ibm.com>
On Fri, Mar 31, 2006 at 04:13:30PM -0600, Jake Moilanen wrote:
> This patch hooks our current interrupt subsystem and sets up a single
> vector MSI as if it was a LSI. Multiple MSI vectors is coming in the
> future.
This is broken. Linux drivers expect MSI to be disabled on ->probe.
There's at least two reasons for that:
(1) Many devices that claim to implement MSI are actually broken in
more or less subtile ways. and thus must use traditition INTx pins.
(2) MSI defines relaxed semantics for dma synchronization. Silently
enabling MSI could cause subtile data corruption.
^ permalink raw reply
* Re: [PATCH 1/2] Base pSeries PCIe support
From: Christoph Hellwig @ 2006-04-12 4:06 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060331160545.db3fa210.moilanen@austin.ibm.com>
On Fri, Mar 31, 2006 at 04:05:45PM -0600, Jake Moilanen wrote:
> +source "drivers/pci/pcie/Kconfig"
does it actually work on ppc64? last time I checked that code was
utterly x86-centric.
> - if (node->type == NULL || strcmp(node->type, "pci") != 0)
> +
> + if (node->type == NULL || ((strcmp(node->type, "pci") != 0) && (strcmp(node->type, "pciex") != 0)))
> continue;
please don't add superflous braces
^ permalink raw reply
* Check it out
From: vijesh.vh @ 2006-04-12 3:18 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 605 bytes --]
^ permalink raw reply
* Check it out
From: jefferxu @ 2006-04-12 6:25 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 586 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] tickless idle cpus: core patch - v2
From: Srivatsa Vaddagiri @ 2006-04-12 4:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17467.59608.503042.216312@cargo.ozlabs.ibm.com>
On Wed, Apr 12, 2006 at 03:35:20AM +1000, Paul Mackerras wrote:
> It would be nice if we could arrange to call stop_hz_timer from the
> top-level cpu_idle() function rather than having to call it from the
> individual power_save() functions such as power4_idle(). Can you see
> a problem with doing that?
I had considered doing that, but one problem with it is - how do we ensure that
start_hz_timer will be called before idle thread calls schedule? A problem
scenario is when the power_save() function returns without taking an interrupt
(as is possible in pseries_dedicated_idle_sleep?), since start_hz_timer is
currently called from only an interrupt context.
Now we could contemplate calling start_hz_timer directly from cpu_idle
when power_save() function returns - but how do we get the register
context required as an argument in start_hz_timer()?
--
Regards,
vatsa
^ permalink raw reply
* BFD 2.16.1 assertion fail
From: Sai prasanna @ 2006-04-12 7:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]
Date: Wed, 12 Apr 2006 00:04:59 -0700 (PDT)
From: Sai prasanna <saiprasannasp@yahoo.com>
Subject: BFD 2.16.1 assertion fail
To: linux project group <linux_projects_2006@yahoogroups.com>
CC: saiprasannasp@yahoo.com
Hi All,
I Have been trying to build across compiler for power-ppc-linux-gnu I have succesfully installed binutils-2.16.1, first phase gcc-4.0.3, glibc-2.3.6 and then when i finally tried to install the final gcc ima getting eror such as
/home/foo/build-install/powerpc-ppc-linux-gnu/bin/ld: BFD 2.16.1 assertion fail../../binutils-2.16.1/bfd/elf32-ppc.c:5397
collect2: ld returned 1 exit status
make[3]: *** [libmudflap.la] Error 1
make[3]: Leaving directory `/home/foo/build-gcc/powerpc-ppc-linux-gnu/libmudflap'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/foo/build-gcc/powerpc-ppc-linux-gnu/libmudflap'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/foo/build-gcc/powerpc-ppc-linux-gnu/libmudflap'
make: *** [all-target-libmudflap] Error 2
I have used the following gcc configuration opitons
[root@localhost build-gcc]# ../gcc-4.0.3/configure --host=i686-pc-linux-gnu --target=powerpc-ppc-linux-gnu --prefix=/home/foo/build-install --enable-languages=c,c++
Some one please help me with this.
Regards,
Sai
Sai Prasanna.S,
Department Of ComputerScience,
University Of Madras,
Chennai.
Ph: 9940357430
Email: saiprasannasp@yahoo.com
---------------------------------
Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2�/min with Yahoo! Messenger with Voice.
---------------------------------
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.
[-- Attachment #2: Type: text/html, Size: 2175 bytes --]
^ permalink raw reply
* Watchdog on MPC82xx
From: Bastos Fernandez Alexandre @ 2006-04-12 9:48 UTC (permalink / raw)
To: linuxppc-embedded list
Hi list,
I am trying to use the on-chip watchdog timer in the MPC8248 to
recover from system hangs.
I have been following the guidelines from the changes I have found
from Compulab.
In u-boot, the watchdog is activated and works fine. The changes in
the kernel are, basically, assigning the ppd_md.heartbeat to a function
which resets the watchdog. This is supposed to start reseting the wdt
after ppc_md.setup_arch is invoked, but this is not working, and the
kernel keeps rebooting during startup.
I have tried to catch the point when this happens to force a WD service
sequence before that, but I had no success.
So, can anyone give me some guidelines for this job? I have seen from
freescale docs that MPC83xx watchdog may be the same than MPC82xx one.
So, could I use the same approach than used on MPC83xx boards?
http://patchwork.ozlabs.org/linuxppc//patch?id=4118
Thanks in advance
Alex
^ permalink raw reply
* Re: BFD 2.16.1 assertion fail
From: Alan Modra @ 2006-04-12 8:53 UTC (permalink / raw)
To: Sai prasanna; +Cc: linuxppc-dev
In-Reply-To: <20060412073814.39382.qmail@web54313.mail.yahoo.com>
On Wed, Apr 12, 2006 at 12:38:14AM -0700, Sai prasanna wrote:
> /home/foo/build-install/powerpc-ppc-linux-gnu/bin/ld: BFD 2.16.1 assertion fail../../binutils-2.16.1/bfd/elf32-ppc.c:5397
You will likely be much better off with a new CVS binutils. 2.16.1 was
released almost a year ago, and a lot of bugs have been fixed since
then.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ 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