* [PATCH] ARM: Fix virtual kernel memory printing for sparsemem @ 2010-03-25 14:53 Catalin Marinas 2010-03-25 15:10 ` Russell King - ARM Linux 2010-05-04 16:02 ` Marek Vasut 0 siblings, 2 replies; 12+ messages in thread From: Catalin Marinas @ 2010-03-25 14:53 UTC (permalink / raw) To: linux-arm-kernel Commit db9ef1a introduced information printing for the virtual kernel memory map but page/end calculation using the pfn goes wrong and page_count() generates a data abort or alignment fault (possibly because it gets to an uninitialised page structure that looks like a compound page). This patch adds page/end calculation using pfn_to_page(). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <Will.Deacon@arm.com> Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com> --- arch/arm/mm/init.c | 7 ++----- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index b69ac3a..8a48634 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -600,9 +600,6 @@ void __init mem_init(void) reserved_pages = free_pages = 0; for_each_online_node(node) { - pg_data_t *n = NODE_DATA(node); - struct page *map = pgdat_page_nr(n, 0) - n->node_start_pfn; - for_each_nodebank(i, &meminfo, node) { struct membank *bank = &meminfo.bank[i]; unsigned int pfn1, pfn2; @@ -611,8 +608,8 @@ void __init mem_init(void) pfn1 = bank_pfn_start(bank); pfn2 = bank_pfn_end(bank); - page = map + pfn1; - end = map + pfn2; + page = pfn_to_page(pfn1); + end = pfn_to_page(pfn2 - 1) + 1; do { if (PageReserved(page)) ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH] ARM: Fix virtual kernel memory printing for sparsemem 2010-03-25 14:53 [PATCH] ARM: Fix virtual kernel memory printing for sparsemem Catalin Marinas @ 2010-03-25 15:10 ` Russell King - ARM Linux 2010-03-25 15:24 ` Catalin Marinas 2010-05-04 16:02 ` Marek Vasut 1 sibling, 1 reply; 12+ messages in thread From: Russell King - ARM Linux @ 2010-03-25 15:10 UTC (permalink / raw) To: linux-arm-kernel On Thu, Mar 25, 2010 at 02:53:24PM +0000, Catalin Marinas wrote: > Commit db9ef1a introduced information printing for the virtual kernel > memory map but page/end calculation using the pfn goes wrong and > page_count() generates a data abort or alignment fault (possibly because > it gets to an uninitialised page structure that looks like a compound > page). While this looks fine, I'd like to see a lot of Tested-by's against this before it's merged - we've had similar code in show_mem() which has proven to be quite problematical to get right for all the various different combinations we have. However, we also have the same method in show_mem() which we know works fine, so I'd also like to see the problem with using it in mem_init() fully analysed - rather than a "possibly because". ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: Fix virtual kernel memory printing for sparsemem 2010-03-25 15:10 ` Russell King - ARM Linux @ 2010-03-25 15:24 ` Catalin Marinas 2010-03-25 15:30 ` Russell King - ARM Linux 0 siblings, 1 reply; 12+ messages in thread From: Catalin Marinas @ 2010-03-25 15:24 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote: > On Thu, Mar 25, 2010 at 02:53:24PM +0000, Catalin Marinas wrote: > > Commit db9ef1a introduced information printing for the virtual kernel > > memory map but page/end calculation using the pfn goes wrong and > > page_count() generates a data abort or alignment fault (possibly because > > it gets to an uninitialised page structure that looks like a compound > > page). > > While this looks fine, I'd like to see a lot of Tested-by's against > this before it's merged - we've had similar code in show_mem() > which has proven to be quite problematical to get right for all the > various different combinations we have. > > However, we also have the same method in show_mem() which we know > works fine, so I'd also like to see the problem with using it in > mem_init() fully analysed - rather than a "possibly because". I can remove the "possibly" part :). The page_count() is given a page with some random flags and it thinks it's a compound page. It than tries to access page->first which isn't set, hence the error. The original code assumes that for a given node the map is contiguous and it calculates the page as (map + pfn). This is only true for flatmem. With sparsemem the page calculation is a bit more complicated but handled by pfn_to_page(). -- Catalin ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: Fix virtual kernel memory printing for sparsemem 2010-03-25 15:24 ` Catalin Marinas @ 2010-03-25 15:30 ` Russell King - ARM Linux 2010-03-25 15:37 ` Will Deacon 2010-03-25 16:01 ` Catalin Marinas 0 siblings, 2 replies; 12+ messages in thread From: Russell King - ARM Linux @ 2010-03-25 15:30 UTC (permalink / raw) To: linux-arm-kernel On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote: > On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote: > > While this looks fine, I'd like to see a lot of Tested-by's against > > this before it's merged - we've had similar code in show_mem() > > which has proven to be quite problematical to get right for all the > > various different combinations we have. > > > > However, we also have the same method in show_mem() which we know > > works fine, so I'd also like to see the problem with using it in > > mem_init() fully analysed - rather than a "possibly because". > > I can remove the "possibly" part :). The page_count() is given a page > with some random flags and it thinks it's a compound page. It than tries > to access page->first which isn't set, hence the error. > > The original code assumes that for a given node the map is contiguous > and it calculates the page as (map + pfn). This is only true for > flatmem. With sparsemem the page calculation is a bit more complicated > but handled by pfn_to_page(). And show_mem() ? It seems to suffer from the same problem. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: Fix virtual kernel memory printing for sparsemem 2010-03-25 15:30 ` Russell King - ARM Linux @ 2010-03-25 15:37 ` Will Deacon 2010-03-25 16:01 ` Catalin Marinas 1 sibling, 0 replies; 12+ messages in thread From: Will Deacon @ 2010-03-25 15:37 UTC (permalink / raw) To: linux-arm-kernel Hi Russell, * Russell King wrote: > On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote: > > On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote: > > > While this looks fine, I'd like to see a lot of Tested-by's against > > > this before it's merged - we've had similar code in show_mem() > > > which has proven to be quite problematical to get right for all the > > > various different combinations we have. > > > > > > However, we also have the same method in show_mem() which we know > > > works fine, so I'd also like to see the problem with using it in > > > mem_init() fully analysed - rather than a "possibly because". > > > > I can remove the "possibly" part :). The page_count() is given a page > > with some random flags and it thinks it's a compound page. It than tries > > to access page->first which isn't set, hence the error. > > > > The original code assumes that for a given node the map is contiguous > > and it calculates the page as (map + pfn). This is only true for > > flatmem. With sparsemem the page calculation is a bit more complicated > > but handled by pfn_to_page(). > > And show_mem() ? It seems to suffer from the same problem. Well if the page flags are being set randomly, there's a good chance that show_mem() won't get as far as calling page_count(). Even then, if the _count field that ends up being read happens to be aligned, it won't fail. If this is what is happening, I'd expect show_mem to give incorrect results on platforms with SPARSEMEM enabled. Has this been observed by anybody? Will ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: Fix virtual kernel memory printing for sparsemem 2010-03-25 15:30 ` Russell King - ARM Linux 2010-03-25 15:37 ` Will Deacon @ 2010-03-25 16:01 ` Catalin Marinas 2010-03-25 17:46 ` Will Deacon 2010-05-04 16:13 ` Marek Vasut 1 sibling, 2 replies; 12+ messages in thread From: Catalin Marinas @ 2010-03-25 16:01 UTC (permalink / raw) To: linux-arm-kernel On Thu, 2010-03-25 at 15:30 +0000, Russell King - ARM Linux wrote: > On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote: > > On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote: > > > While this looks fine, I'd like to see a lot of Tested-by's against > > > this before it's merged - we've had similar code in show_mem() > > > which has proven to be quite problematical to get right for all the > > > various different combinations we have. > > > > > > However, we also have the same method in show_mem() which we know > > > works fine, so I'd also like to see the problem with using it in > > > mem_init() fully analysed - rather than a "possibly because". > > > > I can remove the "possibly" part :). The page_count() is given a page > > with some random flags and it thinks it's a compound page. It than tries > > to access page->first which isn't set, hence the error. > > > > The original code assumes that for a given node the map is contiguous > > and it calculates the page as (map + pfn). This is only true for > > flatmem. With sparsemem the page calculation is a bit more complicated > > but handled by pfn_to_page(). > > And show_mem() ? It seems to suffer from the same problem. And that's a patch which fixes both (but as you said, it would be good if more people test it on various platforms). ARM: Fix kernel memory printing for sparsemem From: Catalin Marinas <catalin.marinas@arm.com> The show_mem() and mem_init() function are assuming that the page map is contiguous and calculates the start and end page of a bank using (map + pfn). This fails with SPARSEMEM where pfn_to_page() must be used. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <Will.Deacon@arm.com> Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com> --- arch/arm/mm/init.c | 14 ++++---------- 1 files changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index b69ac3a..4ee740a 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -83,9 +83,6 @@ void show_mem(void) printk("Mem-info:\n"); show_free_areas(); for_each_online_node(node) { - pg_data_t *n = NODE_DATA(node); - struct page *map = pgdat_page_nr(n, 0) - n->node_start_pfn; - for_each_nodebank (i,mi,node) { struct membank *bank = &mi->bank[i]; unsigned int pfn1, pfn2; @@ -94,8 +91,8 @@ void show_mem(void) pfn1 = bank_pfn_start(bank); pfn2 = bank_pfn_end(bank); - page = map + pfn1; - end = map + pfn2; + page = pfn_to_page(pfn1); + end = pfn_to_page(pfn2 - 1) + 1; do { total++; @@ -600,9 +597,6 @@ void __init mem_init(void) reserved_pages = free_pages = 0; for_each_online_node(node) { - pg_data_t *n = NODE_DATA(node); - struct page *map = pgdat_page_nr(n, 0) - n->node_start_pfn; - for_each_nodebank(i, &meminfo, node) { struct membank *bank = &meminfo.bank[i]; unsigned int pfn1, pfn2; @@ -611,8 +605,8 @@ void __init mem_init(void) pfn1 = bank_pfn_start(bank); pfn2 = bank_pfn_end(bank); - page = map + pfn1; - end = map + pfn2; + page = pfn_to_page(pfn1); + end = pfn_to_page(pfn2 - 1) + 1; do { if (PageReserved(page)) -- Catalin ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH] ARM: Fix virtual kernel memory printing for sparsemem 2010-03-25 16:01 ` Catalin Marinas @ 2010-03-25 17:46 ` Will Deacon 2010-05-04 16:13 ` Marek Vasut 1 sibling, 0 replies; 12+ messages in thread From: Will Deacon @ 2010-03-25 17:46 UTC (permalink / raw) To: linux-arm-kernel > > And show_mem() ? It seems to suffer from the same problem. > > And that's a patch which fixes both (but as you said, it would be good > if more people test it on various platforms). > > > ARM: Fix kernel memory printing for sparsemem > > From: Catalin Marinas <catalin.marinas@arm.com> > > The show_mem() and mem_init() function are assuming that the page map is > contiguous and calculates the start and end page of a bank using (map + > pfn). This fails with SPARSEMEM where pfn_to_page() must be used. > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > Cc: Will Deacon <Will.Deacon@arm.com> > Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com> Right - I tried calling show_mem() after the Kernel has booted up [I hacked c_show() so that it calls show_mem() at the end then I executed cat /proc/cpuinfo]. This causes a page fault from an unaligned address [see bottom of email]. This was on a dual core Realview PBX-A9 with SPARSEMEM enabled. Catalin's patch for mem_init() and show_mem() fixed the problem for me. Tested-by: Will Deacon <will.deacon@arm.com> Will dhcp-dualA9:~# cat /proc/cpuinfo [ 118.928349] Mem-info: [ 118.935545] DMA per-cpu: [ 118.943316] CPU 0: hi: 90, btch: 15 usd: 85 [ 118.957840] CPU 1: hi: 90, btch: 15 usd: 0 [ 118.972374] Normal per-cpu: [ 118.980895] CPU 0: hi: 186, btch: 31 usd: 82 [ 118.995414] CPU 1: hi: 186, btch: 31 usd: 62 [ 119.010071] active_anon:494 inactive_anon:0 isolated_anon:0 [ 119.010132] active_file:930 inactive_file:1205 isolated_file:0 [ 119.010191] unevictable:0 dirty:21 writeback:0 unstable:0 [ 119.010245] free:254401 slab_reclaimable:111 slab_unreclaimable:323 [ 119.010304] mapped:646 shmem:0 pagetables:47 bounce:0 [ 119.095992] DMA free:256512kB min:1024kB low:1280kB high:1536kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:260096kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 119.205958] lowmem_reserve[]: 0 752 752 [ 119.217943] Normal free:761092kB min:3028kB low:3784kB high:4540kB active_anon:1976kB inactive_anon:0kB active_file:3720kB inactive_file:4820kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:770048kB mlocked:0kB dirty:84kB writeback:0kB mapped:2584kB shmem:0kB slab_reclaimable:444kB slab_unreclaimable:1292kB kernel_stack:400kB pagetables:188kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 119.334480] lowmem_reserve[]: 0 0 0 [ 119.345253] DMA: 2*4kB 1*8kB 1*16kB 3*32kB 2*64kB 2*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 62*4096kB = 256512kB [ 119.376667] Normal: 1*4kB 1*8kB 1*16kB 1*32kB 1*64kB 1*128kB 2*256kB 1*512kB 2*1024kB 2*2048kB 184*4096kB = 761084kB [ 119.409122] 2136 total pagecache pages [ 119.592380] Unable to handle kernel paging request at virtual address dc6e6be9 [ 119.614377] pgd = bf484000 [ 119.622723] [dc6e6be9] *pgd=00000000 [ 119.633705] Internal error: Oops: 5 [#1] SMP [ 119.646557] last sysfs file: [ 119.655487] Modules linked in: [ 119.664736] CPU: 0 Not tainted (2.6.34-rc2 #4) [ 119.679291] PC is at show_mem+0xc0/0x174 [ 119.691106] LR is at 0x24000 [ 119.699825] pc : [<80031fe0>] lr : [<00024000>] psr: 60000013 [ 119.699888] sp : bf491ec0 ip : 90002000 fp : 00000001 [ 119.734386] r10: 00000003 r9 : 91202000 r8 : dc6e6be5 [ 119.750127] r7 : 0002eefd r6 : 000003b2 r5 : 0000010f r4 : 00000149 [ 119.769785] r3 : 91002160 r2 : 00000002 r1 : 0003000c r0 : 803aed64 [ 119.789457] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 119.810950] Control: 10c53c7d Table: 8f48404a DAC: 00000015 [ 119.828256] Process cat (pid: 790, stack limit = 0xbf4902f8) [ 119.845303] Stack: (0xbf491ec0 to 0xbf492000) [ 119.858487] 1ec0: bff2a060 803aeae0 802b1340 000aa000 0000008b 00000001 bffd9c80 8002b680 [ 119.883152] 1ee0: 803aeaf0 00000001 bff2a060 00015000 00000400 bf491f80 00000000 800c55ec [ 119.907816] 1f00: 00014030 bff2a088 2abf5034 800284d4 00000000 00000000 f000010e bfc1f4e0 [ 119.932480] 1f20: bffd9c80 bf491f80 00000400 00015000 bf490000 bfc1f528 00000000 800e7e98 [ 119.957146] 1f40: bf491f80 00000400 bffd9c80 00015000 bf491f80 00000400 00000000 800accc0 [ 119.981806] 1f60: bffd9c80 00015000 bffd9c80 00015000 00000000 00000000 00000400 800ace14 [ 120.006464] 1f80: 00000000 00000000 00000400 00000000 00000400 00015000 00015000 00000003 [ 120.031129] 1fa0: 800292a8 80029100 00000400 00015000 00000003 00015000 00000400 00015000 [ 120.055788] 1fc0: 00000400 00015000 00015000 00000003 7fffe000 00000000 2aad0000 00000000 [ 120.080457] 1fe0: 00000003 7e8e8ba8 0000ad20 2ab84c0c 60000010 00000003 e7911103 e1a00008 [ 120.105197] [<80031fe0>] (show_mem+0xc0/0x174) from [<8002b680>] (c_show+0x1cc/0x22c) [ 120.128879] [<8002b680>] (c_show+0x1cc/0x22c) from [<800c55ec>] (seq_read+0x1bc/0x428) [ 120.152869] [<800c55ec>] (seq_read+0x1bc/0x428) from [<800e7e98>] (proc_reg_read+0x94/0xa8) [ 120.178112] [<800e7e98>] (proc_reg_read+0x94/0xa8) from [<800accc0>] (vfs_read+0xa8/0x150) [ 120.203052] [<800accc0>] (vfs_read+0xa8/0x150) from [<800ace14>] (sys_read+0x3c/0x68) [ 120.226772] [<800ace14>] (sys_read+0x3c/0x68) from [<80029100>] (ret_fast_syscall+0x0/0x30) [ 120.251964] Code: e20ee909 e35e0909 0593800c 11a08003 (e5988004) [ 120.270706] ---[ end trace 8e8702d3596a05ac ]--- ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: Fix virtual kernel memory printing for sparsemem 2010-03-25 16:01 ` Catalin Marinas 2010-03-25 17:46 ` Will Deacon @ 2010-05-04 16:13 ` Marek Vasut 2010-05-04 16:18 ` Russell King - ARM Linux 1 sibling, 1 reply; 12+ messages in thread From: Marek Vasut @ 2010-05-04 16:13 UTC (permalink / raw) To: linux-arm-kernel Dne ?t 25. b?ezna 2010 17:01:26 Catalin Marinas napsal(a): > On Thu, 2010-03-25 at 15:30 +0000, Russell King - ARM Linux wrote: > > On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote: > > > On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote: > > > > While this looks fine, I'd like to see a lot of Tested-by's against > > > > this before it's merged - we've had similar code in show_mem() > > > > which has proven to be quite problematical to get right for all the > > > > various different combinations we have. > > > > > > > > However, we also have the same method in show_mem() which we know > > > > works fine, so I'd also like to see the problem with using it in > > > > mem_init() fully analysed - rather than a "possibly because". > > > > > > I can remove the "possibly" part :). The page_count() is given a page > > > with some random flags and it thinks it's a compound page. It than > > > tries to access page->first which isn't set, hence the error. > > > > > > The original code assumes that for a given node the map is contiguous > > > and it calculates the page as (map + pfn). This is only true for > > > flatmem. With sparsemem the page calculation is a bit more complicated > > > but handled by pfn_to_page(). > > > > And show_mem() ? It seems to suffer from the same problem. > > And that's a patch which fixes both (but as you said, it would be good > if more people test it on various platforms). > > > ARM: Fix kernel memory printing for sparsemem > > From: Catalin Marinas <catalin.marinas@arm.com> > > The show_mem() and mem_init() function are assuming that the page map is > contiguous and calculates the start and end page of a bank using (map + > pfn). This fails with SPARSEMEM where pfn_to_page() must be used. > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > Cc: Will Deacon <Will.Deacon@arm.com> > Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com> Works perfectly on my machine. I have a PXA270 based device where I have to use sparsemem. Thanks, you can add my: Tested-by: Marek Vasut <marek.vasut@gmail.com> Russell, the patch looks fine, please apply, the stuff is really broken. Linux version 2.6.34-rc5 (root at rin) (gcc version 4.4.2 (GCC) ) #98 PREEMPT Tue May 4 18:09:29 CEST 2010 CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f CPU: VIVT data cache, VIVT instruction cache Machine: Voipac PXA270 Ignoring unrecognised tag 0x54410008 Memory policy: ECC disabled, Data cache writeback Run Mode clock: 208.00MHz (*16) Turbo Mode clock: 312.00MHz (*1.5, inactive) Memory clock: 104.00MHz (/2) System bus clock: 104.00MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64256 Kernel command line: console=tty0 console=ttyS0,115200 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 128MB 128MB = 256MB total Memory: 256472k/256472k available, 5672k reserved, 0K highmem Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) DMA : 0xffc00000 - 0xffe00000 ( 2 MB) vmalloc : 0xc8800000 - 0xe8000000 ( 504 MB) lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) modules : 0xbf000000 - 0xc0000000 ( 16 MB) .init : 0xc0008000 - 0xc00b4000 ( 688 kB) .text : 0xc00b4000 - 0xc020e000 (1384 kB) .data : 0xc0218000 - 0xc022ba80 ( 79 kB) Hierarchical RCU implementation. NR_IRQS:288 Console: colour dummy device 80x30 console [tty0] enabled Calibrating delay loop... 207.66 BogoMIPS (lpj=1038336) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok bio: create slab <bio-0> at 0 Switching to clocksource oscr0 NetWinder Floating Point Emulator V0.97 (double precision) msgmni has been set to 500 io scheduler noop registered (default) pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 22) is a FFUART console [ttyS0] enabled pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 21) is a BTUART pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 20) is a STUART mice: PS/2 mouse device common for all mice XScale iWMMXt coprocessor detected. Freeing init memory: 688K ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: Fix virtual kernel memory printing for sparsemem 2010-05-04 16:13 ` Marek Vasut @ 2010-05-04 16:18 ` Russell King - ARM Linux 2010-05-04 16:28 ` Catalin Marinas 0 siblings, 1 reply; 12+ messages in thread From: Russell King - ARM Linux @ 2010-05-04 16:18 UTC (permalink / raw) To: linux-arm-kernel On Tue, May 04, 2010 at 06:13:28PM +0200, Marek Vasut wrote: > Dne ?t 25. b?ezna 2010 17:01:26 Catalin Marinas napsal(a): > > On Thu, 2010-03-25 at 15:30 +0000, Russell King - ARM Linux wrote: > > > On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote: > > > > On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote: > > > > > While this looks fine, I'd like to see a lot of Tested-by's against > > > > > this before it's merged - we've had similar code in show_mem() > > > > > which has proven to be quite problematical to get right for all the > > > > > various different combinations we have. > > > > > > > > > > However, we also have the same method in show_mem() which we know > > > > > works fine, so I'd also like to see the problem with using it in > > > > > mem_init() fully analysed - rather than a "possibly because". > > > > > > > > I can remove the "possibly" part :). The page_count() is given a page > > > > with some random flags and it thinks it's a compound page. It than > > > > tries to access page->first which isn't set, hence the error. > > > > > > > > The original code assumes that for a given node the map is contiguous > > > > and it calculates the page as (map + pfn). This is only true for > > > > flatmem. With sparsemem the page calculation is a bit more complicated > > > > but handled by pfn_to_page(). > > > > > > And show_mem() ? It seems to suffer from the same problem. > > > > And that's a patch which fixes both (but as you said, it would be good > > if more people test it on various platforms). > > > > > > ARM: Fix kernel memory printing for sparsemem > > > > From: Catalin Marinas <catalin.marinas@arm.com> > > > > The show_mem() and mem_init() function are assuming that the page map is > > contiguous and calculates the start and end page of a bank using (map + > > pfn). This fails with SPARSEMEM where pfn_to_page() must be used. > > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > > Cc: Will Deacon <Will.Deacon@arm.com> > > Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com> > > Works perfectly on my machine. I have a PXA270 based device where I have to use > sparsemem. Thanks, you can add my: > > Tested-by: Marek Vasut <marek.vasut@gmail.com> > > Russell, the patch looks fine, please apply, the stuff is really broken. It's great to see patches getting tested by others ;) Catalin - mind submitting this with Marek's tested-by please? ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: Fix virtual kernel memory printing for sparsemem 2010-05-04 16:18 ` Russell King - ARM Linux @ 2010-05-04 16:28 ` Catalin Marinas 2010-05-04 17:00 ` Marek Vasut 0 siblings, 1 reply; 12+ messages in thread From: Catalin Marinas @ 2010-05-04 16:28 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2010-05-04 at 17:18 +0100, Russell King - ARM Linux wrote: > On Tue, May 04, 2010 at 06:13:28PM +0200, Marek Vasut wrote: > > Dne ?t 25. b?ezna 2010 17:01:26 Catalin Marinas napsal(a): > > > On Thu, 2010-03-25 at 15:30 +0000, Russell King - ARM Linux wrote: > > > > On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote: > > > > > On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote: > > > > > > While this looks fine, I'd like to see a lot of Tested-by's against > > > > > > this before it's merged - we've had similar code in show_mem() > > > > > > which has proven to be quite problematical to get right for all the > > > > > > various different combinations we have. > > > > > > > > > > > > However, we also have the same method in show_mem() which we know > > > > > > works fine, so I'd also like to see the problem with using it in > > > > > > mem_init() fully analysed - rather than a "possibly because". > > > > > > > > > > I can remove the "possibly" part :). The page_count() is given a page > > > > > with some random flags and it thinks it's a compound page. It than > > > > > tries to access page->first which isn't set, hence the error. > > > > > > > > > > The original code assumes that for a given node the map is contiguous > > > > > and it calculates the page as (map + pfn). This is only true for > > > > > flatmem. With sparsemem the page calculation is a bit more complicated > > > > > but handled by pfn_to_page(). > > > > > > > > And show_mem() ? It seems to suffer from the same problem. > > > > > > And that's a patch which fixes both (but as you said, it would be good > > > if more people test it on various platforms). > > > > > > > > > ARM: Fix kernel memory printing for sparsemem > > > > > > From: Catalin Marinas <catalin.marinas@arm.com> > > > > > > The show_mem() and mem_init() function are assuming that the page map is > > > contiguous and calculates the start and end page of a bank using (map + > > > pfn). This fails with SPARSEMEM where pfn_to_page() must be used. > > > > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > > > Cc: Will Deacon <Will.Deacon@arm.com> > > > Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com> > > > > Works perfectly on my machine. I have a PXA270 based device where I have to use > > sparsemem. Thanks, you can add my: > > > > Tested-by: Marek Vasut <marek.vasut@gmail.com> > > > > Russell, the patch looks fine, please apply, the stuff is really broken. > > It's great to see patches getting tested by others ;) > > Catalin - mind submitting this with Marek's tested-by please? Done (patch 6093/1). -- Catalin ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: Fix virtual kernel memory printing for sparsemem 2010-05-04 16:28 ` Catalin Marinas @ 2010-05-04 17:00 ` Marek Vasut 0 siblings, 0 replies; 12+ messages in thread From: Marek Vasut @ 2010-05-04 17:00 UTC (permalink / raw) To: linux-arm-kernel Dne ?t 4. kv?tna 2010 18:28:56 Catalin Marinas napsal(a): > On Tue, 2010-05-04 at 17:18 +0100, Russell King - ARM Linux wrote: > > On Tue, May 04, 2010 at 06:13:28PM +0200, Marek Vasut wrote: > > > Dne ?t 25. b?ezna 2010 17:01:26 Catalin Marinas napsal(a): > > > > On Thu, 2010-03-25 at 15:30 +0000, Russell King - ARM Linux wrote: > > > > > On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote: > > > > > > On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote: > > > > > > > While this looks fine, I'd like to see a lot of Tested-by's > > > > > > > against this before it's merged - we've had similar code in > > > > > > > show_mem() which has proven to be quite problematical to get > > > > > > > right for all the various different combinations we have. > > > > > > > > > > > > > > However, we also have the same method in show_mem() which we > > > > > > > know works fine, so I'd also like to see the problem with > > > > > > > using it in mem_init() fully analysed - rather than a > > > > > > > "possibly because". > > > > > > > > > > > > I can remove the "possibly" part :). The page_count() is given a > > > > > > page with some random flags and it thinks it's a compound page. > > > > > > It than tries to access page->first which isn't set, hence the > > > > > > error. > > > > > > > > > > > > The original code assumes that for a given node the map is > > > > > > contiguous and it calculates the page as (map + pfn). This is > > > > > > only true for flatmem. With sparsemem the page calculation is a > > > > > > bit more complicated but handled by pfn_to_page(). > > > > > > > > > > And show_mem() ? It seems to suffer from the same problem. > > > > > > > > And that's a patch which fixes both (but as you said, it would be > > > > good if more people test it on various platforms). > > > > > > > > > > > > ARM: Fix kernel memory printing for sparsemem > > > > > > > > From: Catalin Marinas <catalin.marinas@arm.com> > > > > > > > > The show_mem() and mem_init() function are assuming that the page map > > > > is contiguous and calculates the start and end page of a bank using > > > > (map + pfn). This fails with SPARSEMEM where pfn_to_page() must be > > > > used. > > > > > > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > > > > Cc: Will Deacon <Will.Deacon@arm.com> > > > > Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com> > > > > > > Works perfectly on my machine. I have a PXA270 based device where I > > > have to use sparsemem. Thanks, you can add my: > > > > > > Tested-by: Marek Vasut <marek.vasut@gmail.com> > > > > > > Russell, the patch looks fine, please apply, the stuff is really > > > broken. > > > > It's great to see patches getting tested by others ;) > > > > Catalin - mind submitting this with Marek's tested-by please? > > Done (patch 6093/1). Thanks for the fast response. Catalin, thanks for the patch. Cheers ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] ARM: Fix virtual kernel memory printing for sparsemem 2010-03-25 14:53 [PATCH] ARM: Fix virtual kernel memory printing for sparsemem Catalin Marinas 2010-03-25 15:10 ` Russell King - ARM Linux @ 2010-05-04 16:02 ` Marek Vasut 1 sibling, 0 replies; 12+ messages in thread From: Marek Vasut @ 2010-05-04 16:02 UTC (permalink / raw) To: linux-arm-kernel Dne ?t 25. b?ezna 2010 15:53:24 Catalin Marinas napsal(a): > Commit db9ef1a introduced information printing for the virtual kernel > memory map but page/end calculation using the pfn goes wrong and > page_count() generates a data abort or alignment fault (possibly because > it gets to an uninitialised page structure that looks like a compound > page). > > This patch adds page/end calculation using pfn_to_page(). > I observed this as well. Came to similar conclusion. I wish I just saw this a little earlier, it'd save me two nights without sleep. Ok, I'll test it right away. > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > Cc: Will Deacon <Will.Deacon@arm.com> > Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com> > --- > arch/arm/mm/init.c | 7 ++----- > 1 files changed, 2 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c > index b69ac3a..8a48634 100644 > --- a/arch/arm/mm/init.c > +++ b/arch/arm/mm/init.c > @@ -600,9 +600,6 @@ void __init mem_init(void) > reserved_pages = free_pages = 0; > > for_each_online_node(node) { > - pg_data_t *n = NODE_DATA(node); > - struct page *map = pgdat_page_nr(n, 0) - n->node_start_pfn; > - > for_each_nodebank(i, &meminfo, node) { > struct membank *bank = &meminfo.bank[i]; > unsigned int pfn1, pfn2; > @@ -611,8 +608,8 @@ void __init mem_init(void) > pfn1 = bank_pfn_start(bank); > pfn2 = bank_pfn_end(bank); > > - page = map + pfn1; > - end = map + pfn2; > + page = pfn_to_page(pfn1); > + end = pfn_to_page(pfn2 - 1) + 1; > > do { > if (PageReserved(page)) > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-05-04 17:00 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-03-25 14:53 [PATCH] ARM: Fix virtual kernel memory printing for sparsemem Catalin Marinas 2010-03-25 15:10 ` Russell King - ARM Linux 2010-03-25 15:24 ` Catalin Marinas 2010-03-25 15:30 ` Russell King - ARM Linux 2010-03-25 15:37 ` Will Deacon 2010-03-25 16:01 ` Catalin Marinas 2010-03-25 17:46 ` Will Deacon 2010-05-04 16:13 ` Marek Vasut 2010-05-04 16:18 ` Russell King - ARM Linux 2010-05-04 16:28 ` Catalin Marinas 2010-05-04 17:00 ` Marek Vasut 2010-05-04 16:02 ` Marek Vasut
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).