* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Mel Gorman @ 2006-04-12 17:32 UTC (permalink / raw)
To: Luck, Tony; +Cc: linuxppc-dev, ak, Linux Kernel Mailing List, bob.picco, davej
In-Reply-To: <20060412170726.GA11143@agluck-lia64.sc.intel.com>
On Wed, 12 Apr 2006, Luck, Tony wrote:
> On Wed, Apr 12, 2006 at 05:00:32PM +0100, Mel Gorman wrote:
>> Patch is attached as 105-ia64_use_init_nodes.patch until I beat sense into
>> my mail setup. I've added Bob Picco to the cc list as he will hit the same
>> issue with whitespace corruption.
>
> Next I tried building a "generic" kernel (using arch/ia64/defconfig). This
> has NUMA=y and DISCONTIG=y). This crashes with the following console log.
>
>
> <snipped>
> add_active_range(0, 0, 4096): New
> add_active_range(0, 0, 131072): New
> add_active_range(0, 0, 131072): New
> add_active_range(0, 393216, 523264): New
> add_active_range(0, 393216, 523264): New
> add_active_range(0, 393216, 524288): New
> add_active_range(0, 393216, 524288): New
This is where it started going wrong. I did not expect add_active_range()
to be called with overlapping PFNs so they were not getting merged. If
they were getting merged correctly, I'd expect the output to be
add_active_range(0, 0, 4096): New
add_active_range(0, 0, 131072): Merging forward
add_active_range(0, 0, 131072): Merging forward
add_active_range(0, 393216, 523264): New
add_active_range(0, 393216, 523264): Merging forward
add_active_range(0, 393216, 524288): Merging forward
add_active_range(0, 393216, 524288): Merging forward
> Virtual mem_map starts at 0xa0007ffffe400000
> Dumping sorted node map
> entry 0: 0 0 -> 131072
> entry 1: 0 0 -> 4096
> entry 2: 0 0 -> 131072
> entry 3: 0 393216 -> 523264
> entry 4: 0 393216 -> 524288
> entry 5: 0 393216 -> 524288
> entry 6: 0 393216 -> 523264
> Hole found index 0: 0 -> 0
> prev_end > start_pfn : 131072 > 0
And here is where it goes BLAM. Without the debugging patch, the check is
just;
BUG_ON(prev_end_pfn > start_pfn);
The error I was *expecting* to catch was an unsorted node map. It's just
nice it caught this situation as well. It'll take a while to fix this up
properly.
Thanks
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] 2 of 3 kdump-ppc64-soft-reset-fixes
From: Olaf Hering @ 2006-04-12 17:15 UTC (permalink / raw)
To: David Wilder; +Cc: akpm, fastboot, mchintage, linuxppc-dev, paulus
In-Reply-To: <443ADCCE.1070504@us.ibm.com>
On Mon, Apr 10, David Wilder wrote:
> +++ 2617-rc1/arch/powerpc/kernel/crash.c 2006-04-05 13:24:19.000000000 -0700
> @@ -185,15 +277,14 @@ void default_machine_crash_shutdown(stru
> * The kernel is broken so disable interrupts.
> */
> local_irq_disable();
> -
> - if (ppc_md.kexec_cpu_down)
> - ppc_md.kexec_cpu_down(1, 0);
> -
> /*
> * Make a note of crashing cpu. Will be used in machine_kexec
> * such that another IPI will not be sent.
This change conflicts with the patch for interrupt shutdown. I guess
both patches are needed, as each one fixes a different bug?
http://ozlabs.org/pipermail/linuxppc-dev/2006-April/021855.html
[PATCH] powerpc: Disable and EOI interrupts in machine_crash_shutdown()
^ permalink raw reply
* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Luck, Tony @ 2006-04-12 17:07 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, ak, Linux Kernel Mailing List, bob.picco, davej
In-Reply-To: <Pine.LNX.4.64.0604121657380.24819@skynet.skynet.ie>
On Wed, Apr 12, 2006 at 05:00:32PM +0100, Mel Gorman wrote:
> Patch is attached as 105-ia64_use_init_nodes.patch until I beat sense into
> my mail setup. I've added Bob Picco to the cc list as he will hit the same
> issue with whitespace corruption.
Next I tried building a "generic" kernel (using arch/ia64/defconfig). This
has NUMA=y and DISCONTIG=y). This crashes with the following console log.
-Tony
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 Wed Apr 12 09:41:12 PDT 2006
EFI v1.10 by INTEL: SALsystab=0x7fe54980 ACPI=0x7ff84000 ACPI 2.0=0x7ff83000 MPS=0x7ff82000 SMBIOS=0xf0000
booting generic kernel on platform dig
Early serial console at I/O port 0x2f8 (options '115200')
Initial ramdisk at: 0xe0000001fedf5000 (1303564 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, 0, 4096): New
add_active_range(0, 0, 131072): New
add_active_range(0, 0, 131072): New
add_active_range(0, 393216, 523264): New
add_active_range(0, 393216, 523264): New
add_active_range(0, 393216, 524288): New
add_active_range(0, 393216, 524288): New
Virtual mem_map starts at 0xa0007ffffe400000
Dumping sorted node map
entry 0: 0 0 -> 131072
entry 1: 0 0 -> 4096
entry 2: 0 0 -> 131072
entry 3: 0 393216 -> 523264
entry 4: 0 393216 -> 524288
entry 5: 0 393216 -> 524288
entry 6: 0 393216 -> 523264
Hole found index 0: 0 -> 0
prev_end > start_pfn : 131072 > 0
kernel BUG at mm/mem_init.c:775!
swapper[0]: bugcheck! 0 [1]
Modules linked in:
Pid: 0, CPU 0, comm: swapper
psr : 00001010084a2010 ifs : 800000000000048d ip : [<a000000100803b40>] Not tainted
ip is at zone_absent_pages_in_node+0x1c0/0x260
unat: 0000000000000000 pfs : 000000000000048d rsc : 0000000000000003
rnat: 0000000000000090 bsps: 000000000001003e pr : 80000000afb566ab
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f
csd : 0930ffff00090000 ssd : 0930ffff00090000
b0 : a000000100803b40 b6 : a0000001003bfe00 b7 : a0000001003bfbc0
f6 : 0fffbccccccccc8c00000 f7 : 0ffdc8dc0000000000000
f8 : 10001e000000000000000 f9 : 10002a000000000000000
f10 : 0fffeb33333332fa80000 f11 : 1003e0000000000000000
r1 : a000000100bfb890 r2 : 0000000000000000 r3 : a000000100a125d8
r8 : 0000000000000024 r9 : a000000100a125c8 r10 : 0000000000000fff
r11 : 0000000000ffffff r12 : a00000010084fd60 r13 : a000000100848000
r14 : 0000000000004000 r15 : a000000100a125e0 r16 : 00000000000002f9
r17 : a000000100a125d0 r18 : ffffffffffffffff r19 : 0000000000000000
r20 : a000000100a37a20 r21 : a000000100a117c0 r22 : 0000000000000000
r23 : a000000100a125f0 r24 : a0000001008cfaa8 r25 : a0000001008cfaa0
r26 : a0000001009fbae0 r27 : 00000010084a2010 r28 : a000000100ac9221
r29 : 0000000000000809 r30 : 0000000000000000 r31 : a000000100a125a0
Unable to handle kernel NULL pointer dereference (address 0000000000000000)
swapper[0]: Oops 8813272891392 [2]
Modules linked in:
Pid: 0, CPU 0, comm: swapper
psr : 0000101008022018 ifs : 8000000000000308 ip : [<a000000100124940>] Not tainted
ip is at kmem_cache_alloc+0xa0/0x160
unat: 0000000000000000 pfs : 0000000000000793 rsc : 0000000000000003
rnat: 0000000000000000 bsps: 0000000000000000 pr : 80000000afb56967
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0930ffff00090000 ssd : 0930ffff00090000
b0 : a00000010003e6c0 b6 : a00000010003f4a0 b7 : a00000010000d090
f6 : 1003ea321ff35f9fb4c36 f7 : 1003e9e3779b97f4a7c16
f8 : 1003e0a00000010001231 f9 : 1003e000000000000007f
f10 : 1003e0000000000000379 f11 : 1003e6db6db6db6db6db7
r1 : a000000100bfb890 r2 : 0000000000000000 r3 : a000000100848018
r8 : 0000000000000000 r9 : 0000000000000000 r10 : 0000000000000000
r11 : 0000000000000000 r12 : a00000010084f1b0 r13 : a000000100848000
r14 : 0000000000000000 r15 : 0000000018000000 r16 : a00000010084f240
r17 : a000000100848f64 r18 : a0000001008c6cb8 r19 : a00000010084f23c
r20 : a00000010084f238 r21 : 000000007fffffff r22 : 0000000000000000
r23 : 0000000000000050 r24 : a000000100012310 r25 : a0000001000122c0
r26 : a0000001008d7870 r27 : a0000001009fc818 r28 : a0000001008ce020
r29 : 0000000000000002 r30 : 0000000000000002 r31 : 00000000000000c8
^ permalink raw reply
* RE: question about Linux 2.6 with Xilinx ML-403
From: Martin, Tim @ 2006-04-12 16:49 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
Grant,
I know I could probably figure this out by looking at the GIT tree
directly (which I'm planning to do) but could you summarize how much
(which devices) of the ML-403 is supported by your patches?
Serial? (which Xilinx core)
Ethernet? (Hard-Core PLB TEMAC?, Soft-Core PLB EMAC? Localink TEMAC? Is
10/100/1000 supported, or is there only 1 rate e.g. 1000 supported?)
Anything else (GPIO buttons/switches?)
Thanks,
Tim
-----Original Message-----
From: linuxppc-embedded-bounces+tmartin=3Dviasat.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+tmartin=3Dviasat.com@ozlabs.org] On
Behalf Of Grant Likely
Sent: Tuesday, April 11, 2006 9:05 PM
To: yding
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: question about Linux 2.6 with Xilinx ML-403
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
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Luck, Tony @ 2006-04-12 16:36 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, ak, Linux Kernel Mailing List, bob.picco, davej
In-Reply-To: <Pine.LNX.4.64.0604121657380.24819@skynet.skynet.ie>
On Wed, Apr 12, 2006 at 05:00:32PM +0100, Mel Gorman wrote:
> Patch is attached as 105-ia64_use_init_nodes.patch until I beat sense into
> my mail setup. I've added Bob Picco to the cc list as he will hit the same
> issue with whitespace corruption.
Ok! That boots on the tiger_defconfig.
Some stuff is weird in the dmesg output though. You report about
twice as many pages in each zone, but then the total memory is
about right. Here's the diff of my regular kernel (got a bunch of
patches post-2.6.17-rc1) against a 2.6.17-rc1 with your patches
applied. Note also that the Dentry and Inode caches allocated
twice as much space (presumably based on the belief that there
is more memory). My guess is that you are counting the holes.
-Tony
19,21c20,37
< On node 0 totalpages: 260725
< DMA zone: 129700 pages, LIFO batch:7
< Normal zone: 131025 pages, LIFO batch:7
---
> add_active_range(0, 1024, 130688): New
> add_active_range(0, 130984, 131020): New
> add_active_range(0, 393216, 524164): New
> add_active_range(0, 524192, 524269): New
> Dumping sorted node map
> entry 0: 0 1024 -> 130688
> entry 1: 0 130984 -> 131020
> entry 2: 0 393216 -> 524164
> entry 3: 0 524192 -> 524269
> Hole found index 0: 1024 -> 1024
> Hole found index 1: 130688 -> 130984
> Hole found index 3: 524164 -> 524192
> On node 0 totalpages: 522921
> Hole found index 0: 1024 -> 1024
> Hole found index 1: 130688 -> 130984
> DMA zone: 260824 pages, LIFO batch:7
> Hole found index 3: 524164 -> 524192
> Normal zone: 262097 pages, LIFO batch:7
25c41
< Kernel command line: BOOT_IMAGE=scsi0:EFI\redhat\l-tiger-smp.gz root=LABEL=/ console=tty1 console=ttyS1,115200 ro
---
> Kernel command line: BOOT_IMAGE=scsi0:EFI\redhat\l-tiger-smpxx.gz root=LABEL=/ console=uart,io,0x2f8 ro
29,30c45,46
< Dentry cache hash table entries: 524288 (order: 8, 4194304 bytes)
< Inode-cache hash table entries: 262144 (order: 7, 2097152 bytes)
---
> Dentry cache hash table entries: 1048576 (order: 9, 8388608 bytes)
> Inode-cache hash table entries: 524288 (order: 8, 4194304 bytes)
32c48
< Memory: 4070560k/4171600k available (6836k code, 99792k reserved, 2749k data, 256k init)
---
> Memory: 4064416k/4171600k available (6832k code, 105936k reserved, 2753k data, 256k init)
^ permalink raw reply
* U-Boot on 440EP Bamboo board, anybody succeed?
From: Andriy Korud @ 2006-04-12 16:22 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm trying to run U-Boot 1.1.4 on original 440EP Bamboo board and have =
two major problems:
1. Ethernets don't work, just "Net: No ethernet found" on boot. In =
PIBS works.=20
2. When trying to boot uImage (loaded via USB, as eth doesn't work), it =
just hang after "Uncompressing Kernel Image ... OK". The same bzImage =
runs in PIBS.=20
U-Boot 1.1.4, Linux 2.6.16, compiled with gcc 3.4.5.
Does anybody succeed to run U-Boot on this board?
thanks in advance,=20
--
Andriy Korud=20
^ permalink raw reply
* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Luck, Tony @ 2006-04-12 15:54 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, ak, Linux Kernel Mailing List, davej
In-Reply-To: <Pine.LNX.4.64.0604121001590.24819@skynet.skynet.ie>
> That seems to register memory about the 0-2G mark and 6-8G with some small
> holes here and there. Sounds like what you expected to happen. In case the
> 1:1 virt->phys mapping is not always true on IA64, I decided to use __pa()
> instead of PAGE_OFFSET like;
>
> add_active_range(node, __pa(start) >> PAGE_SHIFT, __pa(end) >> PAGE_SHIFT);
>
> Is this the correct thing to do or is "start - PAGE_OFFSET" safer?
> Optimistically assuming __pa() is ok, the following patch (which replaces
> Patch 5/6 again) should boot (passed compile testing here). If it doesn't,
> can you send the console log again please?
Almost all of "region 7" (0xE000000000000000-0xFFFFFFFFFFFFFFFF) of the kernel
address space is defined to have a 1:1 mapping with physical memory (the exception
being the top 64K (0xFFFFFFFFFFFF0000-0xFFFFFFFFFFFFFFFF) which is mapped as
a per-cpu area). So __pa(x) is simply defined as ((x) - PAGE_OFFSET). Using
__pa(start) is effectively identical to (start - PAGE_OFFSET), but __pa() is
a bit cleaner and easier to read.
-Tony
^ permalink raw reply
* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Mel Gorman @ 2006-04-12 16:00 UTC (permalink / raw)
To: Luck, Tony; +Cc: linuxppc-dev, ak, Linux Kernel Mailing List, bob.picco, davej
In-Reply-To: <20060412154633.GA10589@agluck-lia64.sc.intel.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1387 bytes --]
On Wed, 12 Apr 2006, Luck, Tony wrote:
> On Wed, Apr 12, 2006 at 11:50:31AM +0100, Mel Gorman wrote:
>
> Patch got corrupted in transit and won't apply (looks like something stripped
> trailing spaces from empty lines). E.g.
>
*swears at his mailer*
Patch is attached as 105-ia64_use_init_nodes.patch until I beat sense into
my mail setup. I've added Bob Picco to the cc list as he will hit the same
issue with whitespace corruption.
Sorry for the inconvenience.
>> 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
>
--
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: 8437 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-12 11:27:55.000000000 +0100
@@ -647,6 +647,7 @@ static __init int count_node_pages(unsig
end >> PAGE_SHIFT);
mem_data[node].min_pfn = min(mem_data[node].min_pfn,
start >> PAGE_SHIFT);
+ add_active_range(node, start >> PAGE_SHIFT, end >> PAGE_SHIFT);
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-12 11:07:10.000000000 +0100
@@ -539,6 +539,18 @@ 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,
+ __pa(start) >> PAGE_SHIFT,
+ __pa(end) >> PAGE_SHIFT);
+ 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
^ permalink raw reply
* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Luck, Tony @ 2006-04-12 15:46 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, ak, Linux Kernel Mailing List, davej
In-Reply-To: <Pine.LNX.4.64.0604121001590.24819@skynet.skynet.ie>
On Wed, Apr 12, 2006 at 11:50:31AM +0100, Mel Gorman wrote:
Patch got corrupted in transit and won't apply (looks like something stripped
trailing spaces from empty lines). E.g.
> 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
^ permalink raw reply
* [PATCH] spufs: fix context-switch decrementer code
From: Arnd Bergmann @ 2006-04-12 15:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
From: Jordi Caubet <jordi_caubet@es.ibm.com>
We found that when the 'decrementer' is saved, the PPE saves the current
time 'csa->suspend_time'. When restoring the 'decrementer', (Step 34)
decrementer seems to be adjusted with the number of cycles th= at a spu
thread has not been running.
In that code it is missing a substract ('-') because 'delta_time' is
assigned a not substracted(see bellow).
Acked-by: Mark Nutter <mnutter@us.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
Index: linus-2.6/arch/powerpc/platforms/cell/spufs/switch.c
===================================================================
--- linus-2.6.orig/arch/powerpc/platforms/cell/spufs/switch.c
+++ linus-2.6/arch/powerpc/platforms/cell/spufs/switch.c
@@ -1299,7 +1299,7 @@ static inline void setup_decr(struct spu
cycles_t resume_time = get_cycles();
cycles_t delta_time = resume_time - csa->suspend_time;
- csa->lscsa->decr.slot[0] = delta_time;
+ csa->lscsa->decr.slot[0] -= delta_time;
}
}
^ permalink raw reply
* Re: root file system mounted via NFS - retry?
From: Randy Smith @ 2006-04-12 14:01 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <200604120750.31421.bcook@bpointsys.com>
Brent Cook wrote:
> On Wednesday 12 April 2006 07:35, Randy Smith wrote:
>
>> Hello,
>>
>> I have a general question regarding having a root file system mounted
>> via NFS. Our system consists of a linux PC that acts as the NFS server
>> and two embedded ppc boards running linux that mount their file systems
>> via NFS. The problem is that the embedded boards boot much faster than
>> the PC, and when they attempt to mount the root file system, the NFS
>> server is not up yet. The embedded boards hang and it takes quite a
>> long time before the watchdog timer reboots them. The next time round,
>> they come up just fine.
>> What I would like for them to do is keep trying until the NFS server
>> appears and then continue to boot.
>>
>>
>
> Sorry to try the obvious, but could you make the firmware's auto-boot timeout
> longer? I know that u-boot and several others support this.
>
We are using U-boot and yes, I can set the delay. This does work around
the problem, but I was hoping for a more 'elegant' solution.
> Also, you could try, instead of mounting root NFS directly from the kernel, an
> initrd or embedding an initramfs that does the mount using a script. They you
> could retry as much as you wanted without having to teach the kernel
> anything.
>
Another possibility. Thanks!
> Or, just hook up some GPIOs from your PC to the reset lines on those PPC's.
> Then reset them once your PC is up.
>
This is not possible with our current design, but it would solve the
problem.
> Or rather than running the PPC kernel from flash, tftp it to RAM from your
> PC - that way your PPCs can't even load the kernel until the PC is up
> (assuming your firmware knows how to do this and handles faults gracefully.)
>
The way our system was initially designed, it worked this way. We are
modifying the design to remove the dependency on NFS by embedding the
boot loader, kernel and root file system on the flash. We aren't quite
there yet so in the meantime we moved the kernel to the flash and now we
are seeing this problem.
And in fact, the problem may not be as I described. I have been running
some other tests and I am getting indications that the problem may be in
the hardware that our ppc boards are talking to. I stripped a ppc board
down to just the computer part and hooked up a serial line to it.
Cold-boot and the stripped down ppc reached the mount nfs part and
waited for a little while, and then continued on, so I am discounting
the theory that the NFS mount was failing due to timeout. The other ppc
board hung with the same behavior, but I cannot put a serial line on it.
The question remains though, does the NFS timeo and retrans parameters
on the nfsroot kernel command line apply to the 2.4.25 kernel supplied
by DENX' ELDK?
Thanks,
-Randy
> - Brent
>
>
^ permalink raw reply
* problem booting custom board
From: Joachim Denil @ 2006-04-12 13:25 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]
Dear list,
When booting linux (2.6.12) on a custom board with a ppc405gp processor i
run in to some problems. The board's got 64 mb SDRAM at 0x00000000. The
board is booted with a stripped version of ppc-boot (I added a
board_information structure with the right values and placed the address in
gpr3) witch is located in SRAM, and then jumps to 0x0000 where I placed my
raw binary image.
I made a platform file where I call: ppc4xx_intit, ppc4xx_setup_arch,
ppc4xx_map_io, and a function ppc405_map_irq, but with an empty table (no
PCI devices). I set the link/load address at 0x0 (where I placed my image)
and didn't touch the virtual address of the kernel base. As kernelargs I
gave console=ttyS0,9600, and my rootfs is a busybox in an initramfs.
Still I don't get anything on the UART (checked both in just in case) so
there is definitely something wrong. I only have 1 day in the week to work
on that and I have access to a BDI2000 to debug this Friday, so that should
give me some insights to where it all goes wrong.
But can someone tell me what I'm doing wrong? (or right just to give me some
hope after all ;) )
Thank you,
Joachim Denil
Student @ IWT-KDG Antwerpen Belgium
[-- Attachment #2: Type: text/html, Size: 6976 bytes --]
^ permalink raw reply
* Re: root file system mounted via NFS - retry?
From: Brent Cook @ 2006-04-12 12:50 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <443CF3F8.408@imagemap.com>
On Wednesday 12 April 2006 07:35, Randy Smith wrote:
> Hello,
>
> I have a general question regarding having a root file system mounted
> via NFS. Our system consists of a linux PC that acts as the NFS server
> and two embedded ppc boards running linux that mount their file systems
> via NFS. The problem is that the embedded boards boot much faster than
> the PC, and when they attempt to mount the root file system, the NFS
> server is not up yet. The embedded boards hang and it takes quite a
> long time before the watchdog timer reboots them. The next time round,
> they come up just fine.
> What I would like for them to do is keep trying until the NFS server
> appears and then continue to boot.
>
Sorry to try the obvious, but could you make the firmware's auto-boot timeout
longer? I know that u-boot and several others support this.
Also, you could try, instead of mounting root NFS directly from the kernel, an
initrd or embedding an initramfs that does the mount using a script. They you
could retry as much as you wanted without having to teach the kernel
anything.
Or, just hook up some GPIOs from your PC to the reset lines on those PPC's.
Then reset them once your PC is up.
Or rather than running the PPC kernel from flash, tftp it to RAM from your
PC - that way your PPCs can't even load the kernel until the PC is up
(assuming your firmware knows how to do this and handles faults gracefully.)
- Brent
^ permalink raw reply
* Re: root file system mounted via NFS - retry?
From: Jarno Manninen @ 2006-04-12 12:40 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <443CF3F8.408@imagemap.com>
On Wednesday 12 April 2006 15:35, Randy Smith wrote:
Hi,
If your system configuration is static why not just sleep in the bootloader
for a while? U-boot has sleep command.
- Jarno
> Hello,
>
> I have a general question regarding having a root file system mounted
> via NFS. Our system consists of a linux PC that acts as the NFS server
> and two embedded ppc boards running linux that mount their file systems
> via NFS. The problem is that the embedded boards boot much faster than
> the PC, and when they attempt to mount the root file system, the NFS
> server is not up yet. The embedded boards hang and it takes quite a
> long time before the watchdog timer reboots them. The next time round,
> they come up just fine.
> What I would like for them to do is keep trying until the NFS server
> appears and then continue to boot.
>
> We are running DENX's ELDK 2.4.25 kernel on the ppc boards and I know
> that for some linux releases, one may add values for timeo and retrans
> on the boot command line in the NFSROOT= command. Can anyone tell me if
> they are valid for this release of the kernel? Or if there is another
> way to accomplish this?
>
> Thanks,
>
> -Randy Smith
> Software Engineer
> ImageMap, Inc.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* root file system mounted via NFS - retry?
From: Randy Smith @ 2006-04-12 12:35 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I have a general question regarding having a root file system mounted
via NFS. Our system consists of a linux PC that acts as the NFS server
and two embedded ppc boards running linux that mount their file systems
via NFS. The problem is that the embedded boards boot much faster than
the PC, and when they attempt to mount the root file system, the NFS
server is not up yet. The embedded boards hang and it takes quite a
long time before the watchdog timer reboots them. The next time round,
they come up just fine.
What I would like for them to do is keep trying until the NFS server
appears and then continue to boot.
We are running DENX's ELDK 2.4.25 kernel on the ppc boards and I know
that for some linux releases, one may add values for timeo and retrans
on the boot command line in the NFSROOT= command. Can anyone tell me if
they are valid for this release of the kernel? Or if there is another
way to accomplish this?
Thanks,
-Randy Smith
Software Engineer
ImageMap, Inc.
^ permalink raw reply
* Re: BFD 2.16.1 assertion fail
From: jschopp @ 2006-04-12 11:28 UTC (permalink / raw)
To: Sai prasanna; +Cc: linuxppc-dev
In-Reply-To: <20060412073814.39382.qmail@web54313.mail.yahoo.com>
If you just want a working cross compiler these tend to be pretty good:
http://developer.osdl.org/dev/plm/cross_compile/
Or if you insist on doing your own crosstool is a very good idea:
http://www.kegel.com/crosstool/
-Joel
Sai prasanna wrote:
>
> 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
> <http://us.rd.yahoo.com/mail_us/taglines/postman9/*http://us.rd.yahoo.com/evt=39666/*http://beta.messenger.yahoo.com/>
> for just 2�/min with Yahoo! Messenger with Voice.
>
>
> ------------------------------------------------------------------------
> Yahoo! Messenger with Voice.
> <http://us.rd.yahoo.com/mail_us/taglines/postman3/*http://us.rd.yahoo.com/evt=39666/*http://beta.messenger.yahoo.com>
> PC-to-Phone calls for ridiculously low rates.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Mel Gorman @ 2006-04-12 10:59 UTC (permalink / raw)
To: Bob Picco; +Cc: linuxppc-dev, ak, Luck, Tony, Linux Kernel Mailing List, davej
In-Reply-To: <20060412013824.GF23742@localhost>
On Tue, 11 Apr 2006, Bob Picco wrote:
> 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.
It would have been ok if I spotted it was physical addresses being passed
into count_node_pages(). add_active_range() expects pfns so a >> PAGE_SHIFT
was missing there.
> BTW - I like want you are attempting to achieve.
Thanks
>> 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..
>
> <Patch Snipped>
>
> 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.
>
Thanks for trying it out so late in the evening. The accounting is off
because I was passing in physical addresses instead of pfns. The fact it
booted at all means we probably registered the memory near address 0 by
accident and it would eventually oops.
>
> Let me wrap my head around this code again. It's been some time.
This is the same patch I posted to Tony that hopefully fix the problems on
flatmem. The important changes for your discontig machine is;
o Registering in count_node_pages() as your patch fixed
o Converting the physical address passed to count_node_pages() to a PFN
Can you try it out when you're next looking at this? Thanks
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-12 11:27:55.000000000 +0100
@@ -647,6 +647,7 @@ static __init int count_node_pages(unsig
end >> PAGE_SHIFT);
mem_data[node].min_pfn = min(mem_data[node].min_pfn,
start >> PAGE_SHIFT);
+ add_active_range(node, start >> PAGE_SHIFT, end >> PAGE_SHIFT);
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-12 11:07:10.000000000 +0100
@@ -539,6 +539,18 @@ 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,
+ __pa(start) >> PAGE_SHIFT,
+ __pa(end) >> PAGE_SHIFT);
+ 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
^ permalink raw reply
* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Mel Gorman @ 2006-04-12 10:50 UTC (permalink / raw)
To: Luck, Tony; +Cc: linuxppc-dev, ak, Linux Kernel Mailing List, davej
In-Reply-To: <20060412000500.GA8532@agluck-lia64.sc.intel.com>
On Tue, 11 Apr 2006, Luck, Tony wrote:
> 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.
>
ok, based on your console log, I'm pretty sure it would have broken on
almost any IA64.
>> 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).
>
That's useful to know. It means I know what pfn ranges I expect to see
being passed to add_active_range().
>> 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:
>
> <snip snip>
> 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
> <snip snip>
Good man Mel! The callback register_active_ranges() callback is getting
*virtual addresses*, not PFNs (which is brutally obvious now!). For
discontig, there is a similar story. count_node_pages() is getting a
*physical address*, not a pfn (also called start which is a bit confusing
but a different problem).
So some thinking out loud to see if you spot problems;
o PAGE_OFFSET seems to be 16140901064495857664 from the header file
o Instead of using add_active_range(node, start, end), assume I had used
add_active_range(node,
(start - PAGE_OFFSET) >> PAGE_SHIFT,
(end - PAGE_OFFSET) >> PAGE_SHIFT);
That would have made the console log look something like;
add_active_range(0, 4096, 522752): New
add_active_range(0, 523936, 524080): New
add_active_range(0, 1572864, 2096656): New
add_active_range(0, 2096768, 2097076): New
That seems to register memory about the 0-2G mark and 6-8G with some small
holes here and there. Sounds like what you expected to happen. In case the
1:1 virt->phys mapping is not always true on IA64, I decided to use __pa()
instead of PAGE_OFFSET like;
add_active_range(node, __pa(start) >> PAGE_SHIFT, __pa(end) >> PAGE_SHIFT);
Is this the correct thing to do or is "start - PAGE_OFFSET" safer?
Optimistically assuming __pa() is ok, the following patch (which replaces
Patch 5/6 again) should boot (passed compile testing here). If it doesn't,
can you send the console log again please?
Thanks again.
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-12 11:27:55.000000000 +0100
@@ -647,6 +647,7 @@ static __init int count_node_pages(unsig
end >> PAGE_SHIFT);
mem_data[node].min_pfn = min(mem_data[node].min_pfn,
start >> PAGE_SHIFT);
+ add_active_range(node, start >> PAGE_SHIFT, end >> PAGE_SHIFT);
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-12 11:07:10.000000000 +0100
@@ -539,6 +539,18 @@ 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,
+ __pa(start) >> PAGE_SHIFT,
+ __pa(end) >> PAGE_SHIFT);
+ 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
^ permalink raw reply
* Re: Watchdog on MPC82xx
From: Bastos Fernandez Alexandre @ 2006-04-12 11:44 UTC (permalink / raw)
To: linuxppc-embedded list
In-Reply-To: <1144835330.443ccd021b40a@webmail.televes.com:443>
> 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
>
Though Freescales doc for MPC83xx says:
• Functional and programming compatibility with MPC8260 watchdog timer
further reading shows that there is a "little" difference. MPC83xx can
come out of reset with WDT disabled, while MPC82xx can't. So the approach
for MPC83xx is not possible on those other systems.
So, any other idea? Is the WDT on MPC8248 usable at all?
Thanks,
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
* 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
* 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
* 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
* 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
* 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
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