All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 1/2] ARM: mmu: Add debug_ll_io_init() mappings to early mappings
@ 2013-06-14 20:32 ` Stephen Boyd
  0 siblings, 0 replies; 6+ messages in thread
From: Stephen Boyd @ 2013-06-14 20:32 UTC (permalink / raw)
  To: Russell King
  Cc: linux-kernel, linux-arm-msm, linux-arm-kernel, Rob Herring,
	Stephen Warren

Failure to add the mapping created in debug_ll_io_init() can lead
to the BUG_ON() triggering in lib/ioremap.c:27 if the static
virtual address decided for the debug_ll mapping overlaps with
another mapping that is created later. This happens because the
generic ioremap code has no idea there is a mapping there and it
tries to place a mapping in the same location and blows up when
it sees that there is a pte already present.

kernel BUG at lib/ioremap.c:27!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc2-00042-g2af0c67-dirty #316
task: ef088000 ti: ef082000 task.ti: ef082000
PC is at ioremap_page_range+0x16c/0x198
LR is at ioremap_page_range+0xf0/0x198
pc : [<c04cb874>]    lr : [<c04cb7f8>]    psr: 20000113
sp : ef083e78  ip : af140000  fp : ef083ebc
r10: ef7fc100  r9 : ef7fc104  r8 : 000af174
r7 : 00000647  r6 : beffffff  r5 : f004c000  r4 : f0040000
r3 : af173417  r2 : 16440653  r1 : af173e07  r0 : ef7fc8fc
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5787d  Table: 8020406a  DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xef082238)
Stack: (0xef083e78 to 0xef084000)
3e60:                                                       00040000 ef083eec
3e80: bf134000 f004bfff c0207c00 f004c000 c02fc120 f000c000 c15e7800 00040000
3ea0: ef083eec 00000647 c098ba9c c0953544 ef083edc ef083ec0 c021b82c c04cb714
3ec0: c09cdc50 00000040 ef0f1e00 ef1003c0 ef083f14 ef083ee0 c09535bc c021b7bc
3ee0: c0953544 c04d0c6c c094e2cc c1600be4 c07440c4 c09a6888 00000002 c0a15f00
3f00: ef082000 00000000 ef083f54 ef083f18 c0208728 c0953550 00000002 c1600bfc
3f20: c08e3fac c0839918 ef083f54 c1600b80 c09a6888 c0a15f00 0000008b c094e2cc
3f40: c098ba9c c098bab8 ef083f94 ef083f58 c094ea0c c020865c 00000002 00000002
3f60: c094e2cc 00000000 c025b674 00000000 c06ff860 00000000 00000000 00000000
3f80: 00000000 00000000 ef083fac ef083f98 c06ff878 c094e910 00000000 00000000
3fa0: 00000000 ef083fb0 c020efe8 c06ff86c 00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 c0595108
[<c04cb874>] (ioremap_page_range+0x16c/0x198) from [<c021b82c>] (__alloc_remap_buffer.isra.18+0x7c/0xc4)
[<c021b82c>] (__alloc_remap_buffer.isra.18+0x7c/0xc4) from [<c09535bc>] (atomic_pool_init+0x78/0x128)
[<c09535bc>] (atomic_pool_init+0x78/0x128) from [<c0208728>] (do_one_initcall+0xd8/0x198)
[<c0208728>] (do_one_initcall+0xd8/0x198) from [<c094ea0c>] (kernel_init_freeable+0x108/0x1d0)
[<c094ea0c>] (kernel_init_freeable+0x108/0x1d0) from [<c06ff878>] (kernel_init+0x18/0xf4)
[<c06ff878>] (kernel_init+0x18/0xf4) from [<c020efe8>] (ret_from_fork+0x14/0x20)
Code: e50b0040 ebf54b2f e51b0040 eaffffee (e7f001f2)

Fix it by telling generic layers about the static mapping via
iotable_init().  This also has the nice side effect of letting
you see the mapping in procfs' vmallocinfo file.

Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---

Changes since v1:
 * Use iotable_init() instead of open coding it

 arch/arm/mm/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e0d8565..18b8aeb 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -947,7 +947,7 @@ void __init debug_ll_io_init(void)
 	map.virtual &= PAGE_MASK;
 	map.length = PAGE_SIZE;
 	map.type = MT_DEVICE;
-	create_mapping(&map);
+	iotable_init(&map, 1);
 }
 #endif
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [PATCH v2 1/2] ARM: mmu: Add debug_ll_io_init() mappings to early mappings
@ 2013-06-14 20:32 ` Stephen Boyd
  0 siblings, 0 replies; 6+ messages in thread
From: Stephen Boyd @ 2013-06-14 20:32 UTC (permalink / raw)
  To: linux-arm-kernel

Failure to add the mapping created in debug_ll_io_init() can lead
to the BUG_ON() triggering in lib/ioremap.c:27 if the static
virtual address decided for the debug_ll mapping overlaps with
another mapping that is created later. This happens because the
generic ioremap code has no idea there is a mapping there and it
tries to place a mapping in the same location and blows up when
it sees that there is a pte already present.

kernel BUG at lib/ioremap.c:27!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc2-00042-g2af0c67-dirty #316
task: ef088000 ti: ef082000 task.ti: ef082000
PC is at ioremap_page_range+0x16c/0x198
LR is at ioremap_page_range+0xf0/0x198
pc : [<c04cb874>]    lr : [<c04cb7f8>]    psr: 20000113
sp : ef083e78  ip : af140000  fp : ef083ebc
r10: ef7fc100  r9 : ef7fc104  r8 : 000af174
r7 : 00000647  r6 : beffffff  r5 : f004c000  r4 : f0040000
r3 : af173417  r2 : 16440653  r1 : af173e07  r0 : ef7fc8fc
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5787d  Table: 8020406a  DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xef082238)
Stack: (0xef083e78 to 0xef084000)
3e60:                                                       00040000 ef083eec
3e80: bf134000 f004bfff c0207c00 f004c000 c02fc120 f000c000 c15e7800 00040000
3ea0: ef083eec 00000647 c098ba9c c0953544 ef083edc ef083ec0 c021b82c c04cb714
3ec0: c09cdc50 00000040 ef0f1e00 ef1003c0 ef083f14 ef083ee0 c09535bc c021b7bc
3ee0: c0953544 c04d0c6c c094e2cc c1600be4 c07440c4 c09a6888 00000002 c0a15f00
3f00: ef082000 00000000 ef083f54 ef083f18 c0208728 c0953550 00000002 c1600bfc
3f20: c08e3fac c0839918 ef083f54 c1600b80 c09a6888 c0a15f00 0000008b c094e2cc
3f40: c098ba9c c098bab8 ef083f94 ef083f58 c094ea0c c020865c 00000002 00000002
3f60: c094e2cc 00000000 c025b674 00000000 c06ff860 00000000 00000000 00000000
3f80: 00000000 00000000 ef083fac ef083f98 c06ff878 c094e910 00000000 00000000
3fa0: 00000000 ef083fb0 c020efe8 c06ff86c 00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 c0595108
[<c04cb874>] (ioremap_page_range+0x16c/0x198) from [<c021b82c>] (__alloc_remap_buffer.isra.18+0x7c/0xc4)
[<c021b82c>] (__alloc_remap_buffer.isra.18+0x7c/0xc4) from [<c09535bc>] (atomic_pool_init+0x78/0x128)
[<c09535bc>] (atomic_pool_init+0x78/0x128) from [<c0208728>] (do_one_initcall+0xd8/0x198)
[<c0208728>] (do_one_initcall+0xd8/0x198) from [<c094ea0c>] (kernel_init_freeable+0x108/0x1d0)
[<c094ea0c>] (kernel_init_freeable+0x108/0x1d0) from [<c06ff878>] (kernel_init+0x18/0xf4)
[<c06ff878>] (kernel_init+0x18/0xf4) from [<c020efe8>] (ret_from_fork+0x14/0x20)
Code: e50b0040 ebf54b2f e51b0040 eaffffee (e7f001f2)

Fix it by telling generic layers about the static mapping via
iotable_init().  This also has the nice side effect of letting
you see the mapping in procfs' vmallocinfo file.

Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---

Changes since v1:
 * Use iotable_init() instead of open coding it

 arch/arm/mm/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e0d8565..18b8aeb 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -947,7 +947,7 @@ void __init debug_ll_io_init(void)
 	map.virtual &= PAGE_MASK;
 	map.length = PAGE_SIZE;
 	map.type = MT_DEVICE;
-	create_mapping(&map);
+	iotable_init(&map, 1);
 }
 #endif
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [PATCH v2 2/2] ARM: mmu: Introduce iotable_init_caller()
  2013-06-14 20:32 ` Stephen Boyd
@ 2013-06-14 20:32   ` Stephen Boyd
  -1 siblings, 0 replies; 6+ messages in thread
From: Stephen Boyd @ 2013-06-14 20:32 UTC (permalink / raw)
  To: Russell King; +Cc: linux-kernel, linux-arm-msm, linux-arm-kernel, Rob Herring

Now that debug_ll_io_init() maps memory via iotable_init() we
don't get much information in vmallocinfo about what the mapping
corresponds to. Introduce iotable_init_caller() that does the
same thing as iotable_init() except that it allows us to specify
the function that should appear in vmallocinfo. This allows us to
differentiate the debug_ll mapping from the other iotable_init()
mappings.

Cc: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---

I'm ok without this patch. Using __builtin_return_address(0) seems
to do alright on framepointer builds but fails on unwind table
builds so I went with this approach.

 arch/arm/mm/mmu.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 18b8aeb..0699bee 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -811,10 +811,8 @@ static void __init create_mapping(struct map_desc *md)
 	} while (pgd++, addr != end);
 }
 
-/*
- * Create the architecture specific mappings
- */
-void __init iotable_init(struct map_desc *io_desc, int nr)
+static void __init
+iotable_init_caller(struct map_desc *io_desc, int nr, void *caller)
 {
 	struct map_desc *md;
 	struct vm_struct *vm;
@@ -834,11 +832,19 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
 		vm->phys_addr = __pfn_to_phys(md->pfn);
 		vm->flags = VM_IOREMAP | VM_ARM_STATIC_MAPPING;
 		vm->flags |= VM_ARM_MTYPE(md->type);
-		vm->caller = iotable_init;
+		vm->caller = caller;
 		add_static_vm_early(svm++);
 	}
 }
 
+/*
+ * Create the architecture specific mappings
+ */
+void __init iotable_init(struct map_desc *io_desc, int nr)
+{
+	iotable_init_caller(io_desc, nr, iotable_init);
+}
+
 void __init vm_reserve_area_early(unsigned long addr, unsigned long size,
 				  void *caller)
 {
@@ -947,7 +953,7 @@ void __init debug_ll_io_init(void)
 	map.virtual &= PAGE_MASK;
 	map.length = PAGE_SIZE;
 	map.type = MT_DEVICE;
-	iotable_init(&map, 1);
+	iotable_init_caller(&map, 1, debug_ll_io_init);
 }
 #endif
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [PATCH v2 2/2] ARM: mmu: Introduce iotable_init_caller()
@ 2013-06-14 20:32   ` Stephen Boyd
  0 siblings, 0 replies; 6+ messages in thread
From: Stephen Boyd @ 2013-06-14 20:32 UTC (permalink / raw)
  To: linux-arm-kernel

Now that debug_ll_io_init() maps memory via iotable_init() we
don't get much information in vmallocinfo about what the mapping
corresponds to. Introduce iotable_init_caller() that does the
same thing as iotable_init() except that it allows us to specify
the function that should appear in vmallocinfo. This allows us to
differentiate the debug_ll mapping from the other iotable_init()
mappings.

Cc: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---

I'm ok without this patch. Using __builtin_return_address(0) seems
to do alright on framepointer builds but fails on unwind table
builds so I went with this approach.

 arch/arm/mm/mmu.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 18b8aeb..0699bee 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -811,10 +811,8 @@ static void __init create_mapping(struct map_desc *md)
 	} while (pgd++, addr != end);
 }
 
-/*
- * Create the architecture specific mappings
- */
-void __init iotable_init(struct map_desc *io_desc, int nr)
+static void __init
+iotable_init_caller(struct map_desc *io_desc, int nr, void *caller)
 {
 	struct map_desc *md;
 	struct vm_struct *vm;
@@ -834,11 +832,19 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
 		vm->phys_addr = __pfn_to_phys(md->pfn);
 		vm->flags = VM_IOREMAP | VM_ARM_STATIC_MAPPING;
 		vm->flags |= VM_ARM_MTYPE(md->type);
-		vm->caller = iotable_init;
+		vm->caller = caller;
 		add_static_vm_early(svm++);
 	}
 }
 
+/*
+ * Create the architecture specific mappings
+ */
+void __init iotable_init(struct map_desc *io_desc, int nr)
+{
+	iotable_init_caller(io_desc, nr, iotable_init);
+}
+
 void __init vm_reserve_area_early(unsigned long addr, unsigned long size,
 				  void *caller)
 {
@@ -947,7 +953,7 @@ void __init debug_ll_io_init(void)
 	map.virtual &= PAGE_MASK;
 	map.length = PAGE_SIZE;
 	map.type = MT_DEVICE;
-	iotable_init(&map, 1);
+	iotable_init_caller(&map, 1, debug_ll_io_init);
 }
 #endif
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH v2 1/2] ARM: mmu: Add debug_ll_io_init() mappings to early mappings
  2013-06-14 20:32 ` Stephen Boyd
@ 2013-06-26 17:02   ` Stephen Boyd
  -1 siblings, 0 replies; 6+ messages in thread
From: Stephen Boyd @ 2013-06-26 17:02 UTC (permalink / raw)
  To: Russell King
  Cc: linux-kernel, linux-arm-msm, linux-arm-kernel, Rob Herring,
	Stephen Warren

Russell,

Shall I put these two patches in the patch tracker for 3.11?

On 06/14/13 13:32, Stephen Boyd wrote:
> Failure to add the mapping created in debug_ll_io_init() can lead
> to the BUG_ON() triggering in lib/ioremap.c:27 if the static
> virtual address decided for the debug_ll mapping overlaps with
> another mapping that is created later. This happens because the
> generic ioremap code has no idea there is a mapping there and it
> tries to place a mapping in the same location and blows up when
> it sees that there is a pte already present.
>
> kernel BUG at lib/ioremap.c:27!
> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc2-00042-g2af0c67-dirty #316
> task: ef088000 ti: ef082000 task.ti: ef082000
> PC is at ioremap_page_range+0x16c/0x198
> LR is at ioremap_page_range+0xf0/0x198
> pc : [<c04cb874>]    lr : [<c04cb7f8>]    psr: 20000113
> sp : ef083e78  ip : af140000  fp : ef083ebc
> r10: ef7fc100  r9 : ef7fc104  r8 : 000af174
> r7 : 00000647  r6 : beffffff  r5 : f004c000  r4 : f0040000
> r3 : af173417  r2 : 16440653  r1 : af173e07  r0 : ef7fc8fc
> Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c5787d  Table: 8020406a  DAC: 00000015
> Process swapper/0 (pid: 1, stack limit = 0xef082238)
> Stack: (0xef083e78 to 0xef084000)
> 3e60:                                                       00040000 ef083eec
> 3e80: bf134000 f004bfff c0207c00 f004c000 c02fc120 f000c000 c15e7800 00040000
> 3ea0: ef083eec 00000647 c098ba9c c0953544 ef083edc ef083ec0 c021b82c c04cb714
> 3ec0: c09cdc50 00000040 ef0f1e00 ef1003c0 ef083f14 ef083ee0 c09535bc c021b7bc
> 3ee0: c0953544 c04d0c6c c094e2cc c1600be4 c07440c4 c09a6888 00000002 c0a15f00
> 3f00: ef082000 00000000 ef083f54 ef083f18 c0208728 c0953550 00000002 c1600bfc
> 3f20: c08e3fac c0839918 ef083f54 c1600b80 c09a6888 c0a15f00 0000008b c094e2cc
> 3f40: c098ba9c c098bab8 ef083f94 ef083f58 c094ea0c c020865c 00000002 00000002
> 3f60: c094e2cc 00000000 c025b674 00000000 c06ff860 00000000 00000000 00000000
> 3f80: 00000000 00000000 ef083fac ef083f98 c06ff878 c094e910 00000000 00000000
> 3fa0: 00000000 ef083fb0 c020efe8 c06ff86c 00000000 00000000 00000000 00000000
> 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 c0595108
> [<c04cb874>] (ioremap_page_range+0x16c/0x198) from [<c021b82c>] (__alloc_remap_buffer.isra.18+0x7c/0xc4)
> [<c021b82c>] (__alloc_remap_buffer.isra.18+0x7c/0xc4) from [<c09535bc>] (atomic_pool_init+0x78/0x128)
> [<c09535bc>] (atomic_pool_init+0x78/0x128) from [<c0208728>] (do_one_initcall+0xd8/0x198)
> [<c0208728>] (do_one_initcall+0xd8/0x198) from [<c094ea0c>] (kernel_init_freeable+0x108/0x1d0)
> [<c094ea0c>] (kernel_init_freeable+0x108/0x1d0) from [<c06ff878>] (kernel_init+0x18/0xf4)
> [<c06ff878>] (kernel_init+0x18/0xf4) from [<c020efe8>] (ret_from_fork+0x14/0x20)
> Code: e50b0040 ebf54b2f e51b0040 eaffffee (e7f001f2)
>
> Fix it by telling generic layers about the static mapping via
> iotable_init().  This also has the nice side effect of letting
> you see the mapping in procfs' vmallocinfo file.
>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Stephen Warren <swarren@nvidia.com>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> Changes since v1:
>  * Use iotable_init() instead of open coding it
>
>  arch/arm/mm/mmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index e0d8565..18b8aeb 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -947,7 +947,7 @@ void __init debug_ll_io_init(void)
>  	map.virtual &= PAGE_MASK;
>  	map.length = PAGE_SIZE;
>  	map.type = MT_DEVICE;
> -	create_mapping(&map);
> +	iotable_init(&map, 1);
>  }
>  #endif
>  


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH v2 1/2] ARM: mmu: Add debug_ll_io_init() mappings to early mappings
@ 2013-06-26 17:02   ` Stephen Boyd
  0 siblings, 0 replies; 6+ messages in thread
From: Stephen Boyd @ 2013-06-26 17:02 UTC (permalink / raw)
  To: linux-arm-kernel

Russell,

Shall I put these two patches in the patch tracker for 3.11?

On 06/14/13 13:32, Stephen Boyd wrote:
> Failure to add the mapping created in debug_ll_io_init() can lead
> to the BUG_ON() triggering in lib/ioremap.c:27 if the static
> virtual address decided for the debug_ll mapping overlaps with
> another mapping that is created later. This happens because the
> generic ioremap code has no idea there is a mapping there and it
> tries to place a mapping in the same location and blows up when
> it sees that there is a pte already present.
>
> kernel BUG at lib/ioremap.c:27!
> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc2-00042-g2af0c67-dirty #316
> task: ef088000 ti: ef082000 task.ti: ef082000
> PC is at ioremap_page_range+0x16c/0x198
> LR is at ioremap_page_range+0xf0/0x198
> pc : [<c04cb874>]    lr : [<c04cb7f8>]    psr: 20000113
> sp : ef083e78  ip : af140000  fp : ef083ebc
> r10: ef7fc100  r9 : ef7fc104  r8 : 000af174
> r7 : 00000647  r6 : beffffff  r5 : f004c000  r4 : f0040000
> r3 : af173417  r2 : 16440653  r1 : af173e07  r0 : ef7fc8fc
> Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c5787d  Table: 8020406a  DAC: 00000015
> Process swapper/0 (pid: 1, stack limit = 0xef082238)
> Stack: (0xef083e78 to 0xef084000)
> 3e60:                                                       00040000 ef083eec
> 3e80: bf134000 f004bfff c0207c00 f004c000 c02fc120 f000c000 c15e7800 00040000
> 3ea0: ef083eec 00000647 c098ba9c c0953544 ef083edc ef083ec0 c021b82c c04cb714
> 3ec0: c09cdc50 00000040 ef0f1e00 ef1003c0 ef083f14 ef083ee0 c09535bc c021b7bc
> 3ee0: c0953544 c04d0c6c c094e2cc c1600be4 c07440c4 c09a6888 00000002 c0a15f00
> 3f00: ef082000 00000000 ef083f54 ef083f18 c0208728 c0953550 00000002 c1600bfc
> 3f20: c08e3fac c0839918 ef083f54 c1600b80 c09a6888 c0a15f00 0000008b c094e2cc
> 3f40: c098ba9c c098bab8 ef083f94 ef083f58 c094ea0c c020865c 00000002 00000002
> 3f60: c094e2cc 00000000 c025b674 00000000 c06ff860 00000000 00000000 00000000
> 3f80: 00000000 00000000 ef083fac ef083f98 c06ff878 c094e910 00000000 00000000
> 3fa0: 00000000 ef083fb0 c020efe8 c06ff86c 00000000 00000000 00000000 00000000
> 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 c0595108
> [<c04cb874>] (ioremap_page_range+0x16c/0x198) from [<c021b82c>] (__alloc_remap_buffer.isra.18+0x7c/0xc4)
> [<c021b82c>] (__alloc_remap_buffer.isra.18+0x7c/0xc4) from [<c09535bc>] (atomic_pool_init+0x78/0x128)
> [<c09535bc>] (atomic_pool_init+0x78/0x128) from [<c0208728>] (do_one_initcall+0xd8/0x198)
> [<c0208728>] (do_one_initcall+0xd8/0x198) from [<c094ea0c>] (kernel_init_freeable+0x108/0x1d0)
> [<c094ea0c>] (kernel_init_freeable+0x108/0x1d0) from [<c06ff878>] (kernel_init+0x18/0xf4)
> [<c06ff878>] (kernel_init+0x18/0xf4) from [<c020efe8>] (ret_from_fork+0x14/0x20)
> Code: e50b0040 ebf54b2f e51b0040 eaffffee (e7f001f2)
>
> Fix it by telling generic layers about the static mapping via
> iotable_init().  This also has the nice side effect of letting
> you see the mapping in procfs' vmallocinfo file.
>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Stephen Warren <swarren@nvidia.com>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> Changes since v1:
>  * Use iotable_init() instead of open coding it
>
>  arch/arm/mm/mmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index e0d8565..18b8aeb 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -947,7 +947,7 @@ void __init debug_ll_io_init(void)
>  	map.virtual &= PAGE_MASK;
>  	map.length = PAGE_SIZE;
>  	map.type = MT_DEVICE;
> -	create_mapping(&map);
> +	iotable_init(&map, 1);
>  }
>  #endif
>  


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-06-26 17:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-14 20:32 [PATCH v2 1/2] ARM: mmu: Add debug_ll_io_init() mappings to early mappings Stephen Boyd
2013-06-14 20:32 ` Stephen Boyd
2013-06-14 20:32 ` [PATCH v2 2/2] ARM: mmu: Introduce iotable_init_caller() Stephen Boyd
2013-06-14 20:32   ` Stephen Boyd
2013-06-26 17:02 ` [PATCH v2 1/2] ARM: mmu: Add debug_ll_io_init() mappings to early mappings Stephen Boyd
2013-06-26 17:02   ` Stephen Boyd

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.