Hi Folks;
Tried a kernel built with akpm's 2.6.9-rc4-mm1 patch today (using
a default sn2 .config file.) It crashes on boot with:
....
SGI SAL version 3.40
Virtual mem_map starts at 0xa0007ffe85938000
Unable to handle kernel paging request at virtual address a0007ffeaf970000
swapper[0]: Oops 8813272891392 [1]
Modules linked in:
Pid: 0, CPU 0, comm: swapper
psr : 00001010084a2010 ifs : 8000000000000004 ip : [<a0000001008236c0>]
Not tainted
ip is at memmap_init_zone+0x80/0x140
unat: 0000000000000000 pfs : 000000000000030a rsc : 0000000000000003
rnat: 0000000000000000 bsps: 0000000000000000 pr : 80000000ff5655a5
ldrs: 0000000000000000 ccv : 000000000000001f fpsr: 0009804c8a70433f
csd : 0000000000000000 ssd : 0000000000000000
b0 : a00000010005d920 b6 : a00000010005d740 b7 : a0000001004b2640
f6 : 1003e000000000001e000 f7 : 1003e6db6db6db6db6db7
f8 : 1003e0000000005407000 f9 : 1003e0000000000000000
f10 : 1003e0000000000000000 f11 : 1003e2492492492492493
r1 : a000000100c53830 r2 : 00000000000f0000 r3 : a000000100a69880
r8 : a000000100a69880 r9 : 0000000006008000 r10 : 0000000000000000
r11 : 0000000000000000 r12 : a000000100863d80 r13 : a00000010085c000
r14 : a0007ffe85938000 r15 : a0007ffeb0000000 r16 : 00000000000d2000
r17 : a0007ffeaf970000 r18 : 0000000000000800 r19 : a0007ffeb0000000
r20 : ffffffffffffffff r21 : 000fffffffffffff r22 : 0000000000000000
r23 : 0000000000000000 r24 : a0007ffeb0000000 r25 : 0000000000000000
r26 : a0007ffeb0003fff r27 : ffffffffffffc000 r28 : a0007ffeb0000000
r29 : a0007ffeaf938000 r30 : 0000000005407000 r31 : 00000000054d9000
POD entered via OS requested halt, using Cac mode
0 000: POD SysCt Cac> POD entered via INIT, using Cac mode
I traced this down to a recent patch (see
http://marc.theaimsgroup.com/?l=linux-mm&m=109723728329408&w=2)
which contains:
diff -puN arch/ia64/mm/init.c~ia64_fix arch/ia64/mm/init.c
--- test-kernel/arch/ia64/mm/init.c~ia64_fix 2004-10-08
18:29:20.510992392 +0900
+++ test-kernel-kamezawa/arch/ia64/mm/init.c 2004-10-08
18:29:20.515991632 +0900
@@ -410,7 +410,8 @@ virtual_memmap_init (u64 start, u64 end,
struct page *map_start, *map_end;
args = (struct memmap_init_callback_data *) arg;
-
+ start = GRANULEROUNDDOWN(start);
+ end = GRANULEROUNDUP(end);
map_start = vmem_map + (__pa(start) >> PAGE_SHIFT);
map_end = vmem_map + (__pa(end) >> PAGE_SHIFT);
Merely commenting out the new lines containting GRANULEROUNDDOWN, and
GRANULEROUNDUP allowed the system to boot and me to finish the testing
I needed to do.
Looks like the above patch needs to be revised. I could test it if
necessary. Please email me directly as I'm not subscribed to lkml
or linux-ia64.
--
Arthur
Hi,
[email protected] wrote:
> Hi Folks;
>
> Tried a kernel built with akpm's 2.6.9-rc4-mm1 patch today (using
> a default sn2 .config file.) It crashes on boot with:
>
> ....
> SGI SAL version 3.40
> Virtual mem_map starts at 0xa0007ffe85938000
> Unable to handle kernel paging request at virtual address a0007ffeaf970000
> swapper[0]: Oops 8813272891392 [1]
> Modules linked in:
<snip>
> I traced this down to a recent patch (see
> http://marc.theaimsgroup.com/?l=linux-mm&m=109723728329408&w=2)
> which contains:
>
> diff -puN arch/ia64/mm/init.c~ia64_fix arch/ia64/mm/init.c
> --- test-kernel/arch/ia64/mm/init.c~ia64_fix 2004-10-08
> 18:29:20.510992392 +0900
> +++ test-kernel-kamezawa/arch/ia64/mm/init.c 2004-10-08
> 18:29:20.515991632 +0900
> @@ -410,7 +410,8 @@ virtual_memmap_init (u64 start, u64 end,
> struct page *map_start, *map_end;
>
> args = (struct memmap_init_callback_data *) arg;
> -
> + start = GRANULEROUNDDOWN(start);
> + end = GRANULEROUNDUP(end);
> map_start = vmem_map + (__pa(start) >> PAGE_SHIFT);
> map_end = vmem_map + (__pa(end) >> PAGE_SHIFT);
>
>
> Merely commenting out the new lines containting GRANULEROUNDDOWN, and
> GRANULEROUNDUP allowed the system to boot and me to finish the testing
> I needed to do.
>
> Looks like the above patch needs to be revised. I could test it if
> necessary. Please email me directly as I'm not subscribed to lkml
> or linux-ia64.
>
Hmm.. I added above 2 lines for making vmemmap to be aligned with ia64's GRANULE.
But it looks troublesome here, revising it will be needed currently.
I'd like to check my codes again and fix it.
Kame <[email protected]>
Can you try with this patch ?
It's maybe because page table is not created correctly.
Kame <[email protected]>
=============== cut from here ==================
--- arch/ia64/mm/init.c.org 2004-10-13 10:32:09.969725576 +0900
+++ arch/ia64/mm/init.c 2004-10-13 10:33:25.636222520 +0900
@@ -371,7 +371,8 @@ create_mem_map_page_table (u64 start, u6
pgd_t *pgd;
pmd_t *pmd;
pte_t *pte;
-
+ start = GRANULEROUNDDOWN(start);
+ end = GRANULEROUNDUP(end);
map_start = vmem_map + (__pa(start) >> PAGE_SHIFT);
map_end = vmem_map + (__pa(end) >> PAGE_SHIFT);
Hiroyuki KAMEZAWA wrote:
> Hi,
>
> [email protected] wrote:
>
>> Hi Folks;
>> Tried a kernel built with akpm's 2.6.9-rc4-mm1 patch today (using a
>> default sn2 .config file.) It crashes on boot with:
>>
>> ....
>> SGI SAL version 3.40
>> Virtual mem_map starts at 0xa0007ffe85938000
>> Unable to handle kernel paging request at virtual address
>> a0007ffeaf970000
>> swapper[0]: Oops 8813272891392 [1]
>> Modules linked in:
>
> <snip>
>
>> I traced this down to a recent patch (see
>> http://marc.theaimsgroup.com/?l=linux-mm&m=109723728329408&w=2) which
>> contains:
>>
>> diff -puN arch/ia64/mm/init.c~ia64_fix arch/ia64/mm/init.c
>> --- test-kernel/arch/ia64/mm/init.c~ia64_fix 2004-10-08
>> 18:29:20.510992392 +0900
>> +++ test-kernel-kamezawa/arch/ia64/mm/init.c 2004-10-08
>> 18:29:20.515991632 +0900
>> @@ -410,7 +410,8 @@ virtual_memmap_init (u64 start, u64 end,
>> struct page *map_start, *map_end;
>>
>> args = (struct memmap_init_callback_data *) arg;
>> -
>> + start = GRANULEROUNDDOWN(start);
>> + end = GRANULEROUNDUP(end);
>> map_start = vmem_map + (__pa(start) >> PAGE_SHIFT);
>> map_end = vmem_map + (__pa(end) >> PAGE_SHIFT);
>>
>>
>> Merely commenting out the new lines containting GRANULEROUNDDOWN, and
>> GRANULEROUNDUP allowed the system to boot and me to finish the testing
>> I needed to do.
>> Looks like the above patch needs to be revised. I could test it if
>> necessary. Please email me directly as I'm not subscribed to lkml or
>> linux-ia64.
>>
> Hmm.. I added above 2 lines for making vmemmap to be aligned with ia64's
> GRANULE.
> But it looks troublesome here, revising it will be needed currently.
> I'd like to check my codes again and fix it.
>
>
> Kame <[email protected]>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
--the clue is these footmarks leading to the door.--
KAMEZAWA Hiroyuki <[email protected]>
>>>>> On Tue, 12 Oct 2004 17:21:41 -0700 (PDT), <[email protected]> said:
>> Hi Folks;
>> Tried a kernel built with akpm's 2.6.9-rc4-mm1 patch today (using
>> a default sn2 .config file.) It crashes on boot with:
>> .... SGI SAL version 3.40 Virtual mem_map starts at
>> 0xa0007ffe85938000 Unable to handle kernel paging request at
>> virtual address a0007ffeaf970000 swapper[0]: Oops 8813272891392
>> [1] Modules linked in:
>> I traced this down to a recent patch (see
>> http://marc.theaimsgroup.com/?l=linux-mm&m=109723728329408&w=2)
>> which contains:
Why was this patch even accepted? It seemed rather dubious to me and
I don't recall much discussion on its merits or safety.
--david
David Mosberger wrote:
> Why was this patch even accepted? It seemed rather dubious to me and
> I don't recall much discussion on its merits or safety.
>
> --david
At first, that patch it is not essential to no-bitmap-buddy patch, and removing
it is okay. It seems that test and discussion are not enough now.
Since I heared that all of the pages in a granule on ia64 are guaranteed to exist,
I included that in no-bitmap-buddy-patch.
(when pagesize=16k/granule=16M,I think this has no effect.)
My purpose was to reduce # of page fault when ia64_pfn_valid() is called.
It is called heavily in bad_range() (in mm/page_alloc.c) now.
Kame <[email protected]>
>>>>> On Wed, 13 Oct 2004 17:44:10 +0900, Hiroyuki KAMEZAWA <[email protected]> said:
Hiroyuki> My purpose was to reduce # of page fault when
Hiroyuki> ia64_pfn_valid() is called. It is called heavily in
Hiroyuki> bad_range() (in mm/page_alloc.c) now.
At the expense of ignoring perfectly good memory? Or did I miss something?
--david
David Mosberger wrote:
>>>>>>On Wed, 13 Oct 2004 17:44:10 +0900, Hiroyuki KAMEZAWA <[email protected]> said:
>
>
> Hiroyuki> My purpose was to reduce # of page fault when
> Hiroyuki> ia64_pfn_valid() is called. It is called heavily in
> Hiroyuki> bad_range() (in mm/page_alloc.c) now.
>
> At the expense of ignoring perfectly good memory? Or did I miss something?
>
> --david
Am I ignoring some good memory ?
I think GRANULEROUNDDOWN(start)/GRANULEROUNDUP(end) only expand valid pfn range,
do I misunderstanding something ?
-- Kame
Hi Andrew
this patch removes problematic GRANULEROUNDDOWN/GRANULEROUNDUP lines
from 2.6.9-rc4-mm1, arch/ia64m/mm/init.c.
I think aligning memmap patch should be removed now,
and be discussed when it really looks necessary.
Thanks.
Kame <[email protected]>
---
linux-2.6.9-rc4-mm1-kamezawa/arch/ia64/mm/init.c | 2 --
1 files changed, 2 deletions(-)
diff -puN arch/ia64/mm/init.c~ia64_bugfix arch/ia64/mm/init.c
--- linux-2.6.9-rc4-mm1/arch/ia64/mm/init.c~ia64_bugfix 2004-10-14 07:26:04.283256397 +0900
+++ linux-2.6.9-rc4-mm1-kamezawa/arch/ia64/mm/init.c 2004-10-14 07:26:23.644584285 +0900
@@ -410,8 +410,6 @@ virtual_memmap_init (u64 start, u64 end,
struct page *map_start, *map_end;
args = (struct memmap_init_callback_data *) arg;
- start = GRANULEROUNDDOWN(start);
- end = GRANULEROUNDUP(end);
map_start = vmem_map + (__pa(start) >> PAGE_SHIFT);
map_end = vmem_map + (__pa(end) >> PAGE_SHIFT);
_